PE/COFF can use either MSVC or GNU (MinGW) ABI for C++ code, however
LLDB had defaulted to MSVC implicitly with no way to override it. This
causes issues when debugging modules built with the GNU ABI, sometimes
even crashes.
This changes the PE/COFF plugin to set the module triple according to
the default target triple used to build LLDB. If the default target
triple is Windows and a valid environment is specified, then this
environment will be used for the module spec. This not only works for
MSVC and GNU, but also other environments.
A new setting, `plugin.object-file.pe-coff.abi`, has been added to
allow overriding this default ABI.
* Fixes https://github.com/llvm/llvm-project/issues/50775
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/226
* Fixes https://github.com/mstorsjo/llvm-mingw/issues/282
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D127048
The specification of gnu-debuglink can be found at:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
The file CRC or the CRC value from the .gnu_debuglink section is now
used to calculate the module UUID as a fallback, to allow verifying that
the debug object does match the executable. Note that if a CodeView
build id exists, it still takes precedence. This works even for MinGW
builds because LLD writes a synthetic CodeView build id which does not
get stripped from the debug object.
The `Minidump/Windows/find-module` test also needs a fix by adding a
CodeView record to the exe to match the one in the minidump, otherwise
it fails due to the new UUID calculated from the file CRC.
Fixes https://github.com/llvm/llvm-project/issues/54344
Reviewed By: DavidSpickett
Differential Revision: https://reviews.llvm.org/D126367
1. If array element type is a tag decl, complete it.
2. Fix few places where `asTag` should be used instead of `asClass()`.
3. Handle the case that `PdbAstBuilder::CreateFunctionDecl` return nullptr mainly due to an existing workaround (`m_cxx_record_map`).
4. `FindMembersSize` should never return error as this would cause early exiting in `CVTypeVisitor::visitFieldListMemberStream` and then cause assertion failure.
5. In some pdbs from C++ runtime libraries have S_LPROC32 followed directly by S_LOCAL and the local variable location is a S_DEFRANGE_FRAMEPOINTER_REL. There is no information about base frame register in this case, ignoring it by returning RegisterId::NONE.
6. Add a TODO when S_DEFRANGE_SUBFIELD_REGISTER describes the variable location of a pointer type. For now, just ignoring it if the variable is pointer.
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
On macOS, a process will be launched with /usr/lib/dyld (the
dynamic linker) and the main binary by the kernel. The
first thing the standalone dyld will do is call into the dyld
in the shared cache image. This patch tracks the transition
between the dyld's at the very beginning of process startup.
In DynamicLoaderMacOS::NotifyBreakpointHit() there are two new
cases handled:
`dyld_image_dyld_moved` which is the launch /usr/lib/dyld indicating
that it is about call into the shared cache dyld ane evict itself.
lldb will remove the notification breakpoint it set, clear the binary
image list entirely, get the notification function pointer value out
of the dyld_all_image_infos struct (which is the notification fptr
in the to-be-run shared-cache dyld) and put an address breakpoint
there.
`dyld_notify_adding` is then called by shared-cache dyld, and we
detect this case by noticing that we have an empty binary image list,
normally impossibe, and treating this as if we'd just started a
process attach/launch.
Differential Revision: https://reviews.llvm.org/D127247
rdar://84222158
There are 3 places where we were using WASM_SEC_TAG as the "last" known
section type, which requires updating (or leaves a bug) when a new known
section type is added. Instead add a "last type" to the enum for this
purpose.
Differential Revision: https://reviews.llvm.org/D127164
Do not send SIGSTOP when requested to halt a process that's already
stopped. This results in the signal being queued for delivery once
the process is resumed, and unexpectedly stopping it again.
This is necessary for non-stop protocol patches to land.
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.llvm.org/D126770
This patch renames DW_ACCESS_to_AccessType function and move it to the abstract
DWARFASTParser, since there is no clang-specific code there. This is useful for
plugins other than Clang.
Reviewed By: shafik, bulbazord
Differential Revision: https://reviews.llvm.org/D114719
This patch moves ParseChildArrayInfo out of DWARFASTParserClang in order
to decouple Clang-specific logic from DWARFASTParser.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D114668
Signed-off-by: Luís Ferreira <contact@lsferreira.net>
When reading source path remappings out of a dSYM, lldb currently
does tilde expansion -- expanding the tilde-username and checking
that the destination pathname exists, for each dSYM with the path
remappings. This cost happens during lldb's initial process launch
/ load, an especially perf-sensitive time. Inside Apple, we have
dSYMs with source path remappings pointing to NFS directories where
these extra stats for every dSYM can be very expensive if the network
is slow.
This patch instead keeps the source path mapping in the original
tilde-username terms and does the tilde expansion when we need
to read a specific source file from one of the modules. We'll
be stat'ing all of those inodes to load the source file anyway,
so the fact that we do the tilde expansion on every source file
we load, it doesn't cost us significantly.
Differential Revision: https://reviews.llvm.org/D126435
rdar://77091379
(cherry picked from commit c274b6e5830ea88d3f55d6dc1d2b99e38cf6595e)
When reading source path remappings out of a dSYM, lldb currently
does tilde expansion -- expanding the tilde-username and checking
that the destination pathname exists, for each dSYM with the path
remappings. This cost happens during lldb's initial process launch
/ load, an especially perf-sensitive time. Inside Apple, we have
dSYMs with source path remappings pointing to NFS directories where
these extra stats for every dSYM can be very expensive if the network
is slow.
This patch instead keeps the source path mapping in the original
tilde-username terms and does the tilde expansion when we need
to read a specific source file from one of the modules. We'll
be stat'ing all of those inodes to load the source file anyway,
so the fact that we do the tilde expansion on every source file
we load, it doesn't cost us significantly.
Differential Revision: https://reviews.llvm.org/D126435
rdar://77091379
NativePDB often assumes that all debug info are available.
This is one step to make it more pervasive.
Differential Revision: https://reviews.llvm.org/D125844
On Ubuntu 18.04 with GCC 7.5 Intel trace code fails to build due to
failure to convert from
lldb_private::process_linux::IntelPTPerThreadProcessTraceUP to
Expected<lldb_private::process_linux::IntelPTPerThreadProcessTraceUP>.
This commit explicitely marks those unique_ptr values as being moved
which fixes the conversion error.
Reviewed By: wallace
Differential Revision: https://reviews.llvm.org/D126402
Ensure there's a space between "utility" and "function", and also makes
it easier to grep/search for "utility function".
While making this change, I also re-formatted the other dlopen error messages
(with clang-format). This fix other instances of spaces missing between words,
and makes each of these strings fit a single line, making them greppable.
Differential Revision: https://reviews.llvm.org/D126078
should not receive as exceptions (some will get converted to BSD
signals instead). This is really the only stable way to ensure that
a Mach exception gets converted to it's equivalent BSD signal. For
programs that rely on BSD signal handlers, this has to happen or you
can't even get the program to invoke the signal handler when under
the debugger.
This builds on a previous solution to this problem which required you
start debugserver with the -U flag. This was not very discoverable
and required lldb be the one to launch debugserver, which is not always
the case.
Differential Revision: https://reviews.llvm.org/D125434
Previously if you read a code/data mask before there was a valid thread
you would get the top byte mask. This meant the value was "valid" as in,
don't read it again.
When using a corefile we ask for the data mask very early on and this
meant that later once you did have a thread it wouldn't read the
register to get the rest of the mask.
This fixes that and adds a corefile test generated from the same program
as in my previous change on this theme.
Depends on D118794
Reviewed By: omjavaid
Differential Revision: https://reviews.llvm.org/D122411
IntelPTCollector is very big and has 3 classes in it. It's actually cleaner if each one has its own file. This also gives more visibility to the developer about the different kinds of "tracers" that we have.
Besides that, I'm now restricting the creation of the BinaryData chunks to GetState() instead of having it in different places, which is not very clean, because the gdb-remote protocol should be as restricted as possible.
Differential Revision: https://reviews.llvm.org/D125047
When tracing on per-core mode, we are tracing all processes, which means
that after hitting a breakpoint, our process will stop running (thus
producing no more tracing data) but other processes will continue
writing to our trace buffers. This causes a big data loss for our trace.
As a way to remediate this, I'm adding some logic to pause and unpause
tracing based on the target's state. The earlier we do it the better,
however, I'm not adding the trigger at the earliest possible point for
simplicity of this diff. Later we can improve that part.
Differential Revision: https://reviews.llvm.org/D124962
This diffs implements per-core tracing on lldb-server. It also includes tests that ensure that tracing can be initiated from the client and that the jLLDBGetState ppacket returns the list of trace buffers per core.
This doesn't include any decoder changes.
Finally, this makes some little changes here and there improving the existing code.
A specific piece of code that can't reliably be tested is when tracing
per core fails due to permissions. In this case we add a
troubleshooting message and this is the manual test:
```
/proc/sys/kernel/perf_event_paranoid set to 1
(lldb) process trace start --per-core-tracing error: perf event syscall failed: Permission denied
You might need that /proc/sys/kernel/perf_event_paranoid has a value of 0 or -1.
``
Differential Revision: https://reviews.llvm.org/D124858
llvm's json parser supports uint64_t, so let's better use it for the
packets being sent between lldb and lldb-server instead of using int64_t
as an intermediate type, which might be error-prone.
string points to unaccessible memory.
The formatter tries to get the data field of the std::string, and to
check whether that fails it just checks that the ValueObjectSP
returned is not empty. But we never return empty ValueObjectSP's to
indicate failure, since doing so would lose the Error object that
tells you why fetching the ValueObject failed.
This patch adds a check for ValueObject::GetError().Success().
I also added a test case for this failure, and reworked the test case
a bit (to use run_to_source_breakpoint). I also renamed a couple of
single letter locals which don't follow the lldb coding conventions.
Differential Revision: https://reviews.llvm.org/D108228
This patch addresses two perf issues when we find a dSYM on macOS
after calling into the DebugSymbols framework. First, when we have
a local (probably stripped) binaary, we find the dSYM and we may
be told about the location of the symbol rich binary (probably
unstripped) which may be on a remote filesystem. We don't need the
unstripped binary, use the local binary we already have.
Second, after we've found the path to the dSYM, save that in the Module
so we don't call into DebugSymbols a second time later on to
rediscover it. If the user has a DBGShellCommands set, we need to
exec that process twice, serially, which can add up.
Differential Revision: https://reviews.llvm.org/D125616
rdar://84576917
Currently, LLVM's LineEditor and LLDB both use libedit, but find them in different (inconsistent) ways.
This causes issues e.g. when you are using a locally installed version of libedit, which will not be used
by clang-query, but by lldb if picked up by FindLibEdit.cmake
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D124673
symbol name matches. Instead, we extract the incoming path's base
name, look up all the symbols with that base name, and then compare
the rest of the context that the user provided to make sure it
matches. However, we do this comparison using just a strstr. So for
instance:
break set -n foo::bar
will match not only "a::foo::bar" but "notherfoo::bar". The former is
pretty clearly the user's intent, but I don't think the latter is, and
results in breakpoints picking up too many matches.
This change adds a Language::DemangledNameContainsPath API which can
do a language aware match against the path provided. If the language
doesn't provide this we fall back to the strstr (though that's changed
to StringRef::contains in the patch).
Differential Revision: https://reviews.llvm.org/D124579
llvm's json parser supports uint64_t, so let's better use it for the
packets being sent between lldb and lldb-server instead of using int64_t
as an intermediate type, which might be error-prone.
A previous commit enabled LLDB to be able to debug a program launched via ld: https://reviews.llvm.org/D108061.
This commit adds the ability to debug a program launched via ld when it happens during an exec into the dynamic loader. There was an issue where after the exec we would locate the rendezvous structure right away but it didn't contain any valid values and we would try to set the dyanamic loader breakpoint at address zero. This patch fixes that and adds a test.
Differential Revision: https://reviews.llvm.org/D125253
I'm refactoring IntelPTThreadTrace into IntelPTSingleBufferTrace so that it can
both single threads or single cores. In this diff I'm basically renaming the
class, moving it to its own file, and removing all the pieces that are not used
along with some basic cleanup.
Differential Revision: https://reviews.llvm.org/D124648
This updates the documentation of the gdb-remote protocol, as well as the help messages, to include the new --per-core-tracing option.
Differential Revision: https://reviews.llvm.org/D124640
See [[ https://github.com/llvm/llvm-project/issues/55040 | issue 55040 ]] where static members of classes declared in the anonymous namespace are incorrectly returned as member fields from lldb::SBType::GetFieldAtIndex(). It appears that attrs.member_byte_offset contains a sentinel value for members that don't have a DW_AT_data_member_location.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D124409
IIUC, the purpose of CopyUniqueClassMethodTypes is to link together
class definitions in two compile units so that we only have a single
definition of a class. It does this by adding entries to the die_to_type
and die_to_decl_ctx maps.
However, the direction of the linking seems to be reversed. It is taking
entries from the class that has not yet been parsed, and copying them to
the class which has been parsed already -- i.e., it is a very
complicated no-op.
Changing the linking order allows us to revert the changes in D13224
(while keeping the associated test case passing), and is sufficient to
fix PR54761, which was caused by an undesired interaction with that
patch.
Differential Revision: https://reviews.llvm.org/D124370
Currently, ppc64le and ppc64 (defaulting to big endian) have the same
descriptor, thus the linear scan always return ppc64le. Handle that through
subtype.
This is a recommit of f114f009486816ed4b3bf984f0fbbb8fc80914f6 with a new test
setup that doesn't involves (unsupported) corefiles.
Differential Revision: https://reviews.llvm.org/D124760
In UnwindAssemblyInstEmulation we correctly recognize when a LDP
restores the fp & lr in an epilogue, and mark them as having the
caller's contents now, but we don't update the CFA register rule
at that point to indicate that the CFA is now calculated in terms
of $sp. This doesn't impact the backtrace because the register
contents are all <same> now, but it can confuse the stepper when
the StackID changes mid-epilogue.
Differential Revision: https://reviews.llvm.org/D124492
rdar://92064415
As a preparation for parallelizing loading of symbols (D122975),
it is necessary to use just one thread pool to avoid using
a thread pool from inside a task of another thread pool.
Differential Revision: https://reviews.llvm.org/D123226
