LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.
Change call sites to use `std::size` instead.
Differential Revision: https://reviews.llvm.org/D133501
When setting a breakpoint upon throwing exceptions, LLDB only
searches for the libc++abi code inside dylibs named:
1. libc++abi.dylib
2. libSystem.B.dylib
However, this fails to account for libs with a version number. For
example, when building the libcxx and libcxxabi runtimes, the following
dylibs are generated:
build/lib/libc++abi.1.0.dylib
build/lib/libc++abi.1.dylib -> libc++abi.1.0.dylib
build/lib/libc++abi.dylib -> libc++abi.1.dylib
If we are debugging a program linked against any of the "versioned"
libs, the breakpoint doesn't work. This commit adds these names to the
search list.
Differential Revision: https://reviews.llvm.org/D132598
Resubmission of https://reviews.llvm.org/D130309 with the 2 patches that fixed the linux buildbot, and new windows fixes.
The FileSpec APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossible to control all of the times the FileSpec object is modified so we can clear cached member variables like m_resolved and with an upcoming patch caching if the file is relative or absolute. This patch modifies the APIs of FileSpec so no one can modify the directory or filename instance variables directly by adding set accessors and by removing the get accessors that are non const.
Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;
This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.
The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.
Differential Revision: https://reviews.llvm.org/D130549
The FileSpect APIs allow users to modify instance variables directly by getting a non const reference to the directory and filename instance variables. This makes it impossibly to control all of the times the FileSpec object is modified so we can clear the cache. This patch modifies the APIs of FileSpec so no one can modify the directory or filename directly by adding set accessors and by removing the get accessors that are non const.
Many clients were using FileSpec::GetCString(...) which returned a unique C string from a ConstString'ified version of the result of GetPath() which returned a std::string. This caused many locations to use this convenient function incorrectly and could cause many strings to be added to the constant string pool that didn't need to. Most clients were converted to using FileSpec::GetPath().c_str() when possible. Other clients were modified to use the newly renamed version of this function which returns an actualy ConstString:
ConstString FileSpec::GetPathAsConstString(bool denormalize = true) const;
This avoids the issue where people were getting an already uniqued "const char *" that came from a ConstString only to put the "const char *" back into a "ConstString" object. By returning the ConstString instead of a "const char *" clients can be more efficient with the result.
The patch:
- Removes the non const GetDirectory() and GetFilename() get accessors
- Adds set accessors to replace the above functions: SetDirectory() and SetFilename().
- Adds ClearDirectory() and ClearFilename() to replace usage of the FileSpec::GetDirectory().Clear()/FileSpec::GetFilename().Clear() call sites
- Fixed all incorrect usage of FileSpec::GetCString() to use FileSpec::GetPath().c_str() where appropriate, and updated other call sites that wanted a ConstString to use the newly returned ConstString appropriately and efficiently.
Differential Revision: https://reviews.llvm.org/D130309
This is currently being done in an ad hoc way, and so for some
commands it isn't being checked. We have the info to make this check,
since commands are supposed to add their arguments to the m_arguments
field of the CommandObject. This change uses that info to check whether
the command received arguments in error.
A handful of commands weren't defining their argument types, I also had
to fix them. And a bunch of commands were checking for arguments by
hand, so I removed those checks in favor of the CommandObject one. That
also meant I had to change some tests that were checking for the ad hoc
error outputs.
Differential Revision: https://reviews.llvm.org/D128453
Fix an off-by-one error in the utility function used to extract the
dynamic class info. This resulted in a buffer overflow in the inferior
which interrupted our utility function.
Differential revision: https://reviews.llvm.org/D128377
A copy/paste error in GetClassInfoUtilityFunction resulted in the wrong
utility function being returned: copyRealizedClassList instead of
getRealizedClassList_trylock.
Differential revision: https://reviews.llvm.org/D128378
Add a setting to configure how LLDB parses dynamic Objective-C class
metadata. By default LLDB will choose the most appropriate method for
the target OS.
Differential revision: https://reviews.llvm.org/D128312
Recent revisions of the Objective-C runtime changed
objc_debug_class_getNameRaw() in a way that no longer triggers lazy
names to be instantiated. This has the unintended side-effect of making
generic bridged Swift classes, such as _SwiftDeferredNSDictionary<U,V>
to become invisible to the Objective-C runtime.
This patch detects this situation and forces the names to be
instantiated by calling class_getName() and discarding the result before
calling objc_debug_class_getNameRaw() again.
Many thanks to Mike Ash for outlining the solution and Adrian for
authoring the downstream patch.
rdar://95245318
Differential revision: https://reviews.llvm.org/D128306
In order to avoid stranding the Objective-C runtime lock, we switched
from objc_copyRealizedClassList to its non locking variant
objc_copyRealizedClassList_nolock. Not taking the lock was relatively
safe because we run this expression on one thread only, but it was still
possible that someone was in the middle of modifying this list while we
were trying to read it. Worst case that would result in a crash in the
inferior without side-effects and we'd unwind and try again later.
With the introduction of macOS Ventura, we can use
objc_getRealizedClassList_trylock instead. It has semantics similar to
objc_copyRealizedClassList_nolock, but instead of not locking at all,
the function returns if the lock is already taken, which avoids the
aforementioned crash without stranding the Objective-C runtime lock.
Because LLDB gets to allocate the underlying memory we also avoid
stranding the malloc lock.
rdar://89373233
Differential revision: https://reviews.llvm.org/D127252
Clang is adding a feature to ObjC code generation, where instead of calling
objc_msgSend directly with an object & selector, it generates a stub that
gets passed only the object and the stub figures out the selector.
This patch adds support for following that dispatch method into the implementation
function.
Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.
Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.
This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.
rdar://74890607
Differential revision: https://reviews.llvm.org/D122856
In https://reviews.llvm.org/D118972 I increased this buffer to be
big enough to import 261,144 classes but this is a lot more than
we currently have, an allocating a too-large buffer can add memory
pressure even if it's only for a short time. Reduce the size of
this memory buffer to big enough to import 163,840 classes. I'll
probably move to a scheme where we read the objc classes in chunks,
with a smaller buffer and multiple inferior function calls.
rdar://91275493
Fix undefined behavior in AppleObjCRuntimeV2 where we were left shifting
a signed value. This also removes redundant casts of unobfuscated to
uint64_t which it already is.
rdar://91242879
Differential revision: https://reviews.llvm.org/D123098
Report warnings and errors through events instead of printing directly
the to the debugger's error stream. By using events, IDEs such as Xcode
can report these issues in the UI instead of having them show up in the
debugger console.
The new diagnostic events are handled by the default event loop. If a
diagnostic is reported while nobody is listening for the new event
types, it is printed directly to the debugger's error stream.
Differential revision: https://reviews.llvm.org/D121511
The log channel was changed from Types to Commands in
a007a6d84471bb956abe10974cac3066799f583f:
- Log *log(GetLogIfAllCategoriesSet(LIBLLDB_LOG_PROCESS | LIBLLDB_LOG_TYPES));
+ Log *log = GetLog(LLDBLog::Process | LLDBLog::Commands);
Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.
Differential Revision: https://reviews.llvm.org/D121481
Most notably, Pass.h is no longer included by TargetMachine.h
before: 1063570306
after: 1063332844
Differential Revision: https://reviews.llvm.org/D121168
Identifiers with __ anywhere are reserved. I picked this up via the
bugprone-reserved-identifier clang-tidy check but -Wreserved-identifier will
also flag these uses as well.
Differential Revision: https://reviews.llvm.org/D119915
iOS systems are getting near this limit; double itfrom a 150kb
buffer to a 300kb buffer, which is freed after processing the
list of classes.
rdar://88454594
Differential Revision: https://reviews.llvm.org/D118972
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.
After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
This reverts commit ef82063207.
- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat
Use libobjc.A.dylib as a sentinel to detect situations where we're
reading libraries from process memory instead of the shared cache.
Differential revision: https://reviews.llvm.org/D117623
Don't try to get a class descriptor for a pointer that doesn't look like
a tagged pointer. Also print addresses as fixed-width hex and update the
test.
- Use formatv to print the addresses.
- Add check for 0x0 which is treated as an invalid address.
- Use a an address that's less likely to be interpreted as a real
tagged pointer.
Improve error handling for the lang objc tagged-pointer info. Rather
than failing silently, report an error if we couldn't convert an
argument to an address or resolve the class descriptor.
(lldb) lang objc tagged-pointer info 0xbb6404c47a587764
error: could not get class descriptor for 0xbb6404c47a587764
(lldb) lang objc tagged-pointer info n1
error: could not convert 'n1' to a valid address
Differential revision: https://reviews.llvm.org/D112945
Fix a potential nullptr dereference in AppleObjCRuntimeV2 by checking
the result of GetClassInfoUtilityFunction and returning a failure if
it's null.
The DynamicClassInfoExtractor was already doign the right thing, but the
SharedCacheClassInfoExtractor was missing this check.
There is no reason why this function should be returning a ConstString.
While modifying these files, I also fixed several instances where
GetPluginName and GetPluginNameStatic were returning different strings.
I am not changing the return type of GetPluginNameStatic in this patch, as that
would necessitate additional changes, and this patch is big enough as it is.
Differential Revision: https://reviews.llvm.org/D111877
Joe Loser