The main change is to avoid setting the process state as running when
debugging core/minidumps (details in the bug). Also included a few small,
related fixes around how the errors propagate in this case.
Fixed the FreeBSD/Windows break: the intention was to keep
Process::WillResume() and Process::DoResume() "in-sync", but this had the
unfortunate consequence of breaking Process sub-classes which don't override
WillResume().
The safer approach is to keep Process::WillResume() untouched and only
override it in the minidump and core implementations.
patch by lemo
Bug: https://bugs.llvm.org/show_bug.cgi?id=34532
Differential Revision: https://reviews.llvm.org/D37651
llvm-svn: 313655
Summary:
This allows for the stack size to be configured, which isn't
possible with std::thread. Prevents overflowing the stack when
performing complex operations in the task pool on darwin,
where the default pthread stack size is only 512kb.
This also moves TaskPool from Utility to Host.
Reviewers: labath, tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D37930
llvm-svn: 313637
Summary:
This allows for the stack size to be configured, which isn't
possible with std::thread. Prevents overflowing the stack when
performing complex operations in the task pool on darwin,
where the default pthread stack size is only 512kb.
Reviewers: labath, tberghammer, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D37930
llvm-svn: 313537
On Linux lldb-server sends an OK response to qfThreadInfo if no process
is started yet. I don't know why would LLDB issue a qfThreadInfo packet
before starting a process but creating a fake thread ID in case of an
OK or Error respoinse sounds bad anyway so lets not do it.
llvm-svn: 313525
OpenOCD sends register classes as two separate <feature> nodes, fixed parser to process both of them.
OpenOCD returns "l" in response to "qfThreadInfo", so IsUnsupportedResponse() was false and we were ending up without any threads in the process. I think it's reasonable to assume that there's always at least one thread.
llvm-svn: 313442
When introduced, breakpoint names were just tags that you could
apply to breakpoints that would allow you to refer to a breakpoint
when you couldn't capture the ID, or to refer to a collection of
breakpoints.
This change makes the names independent holders of breakpoint options
that you can then apply to breakpoints when you add the name to the
breakpoint. It adds the "breakpoint name configure" command to set
up or reconfigure breakpoint names. There is also full support for
then in the SB API, including a new SBBreakpointName class.
The connection between the name and the breakpoints
sharing the name remains live, so if you reconfigure the name, all the
breakpoint options all change as well. This allows a quick way
to share complex breakpoint behavior among a bunch of breakpoints, and
a convenient way to iterate on the set.
You can also create a name from a breakpoint, allowing a quick way
to copy options from one breakpoint to another.
I also added the ability to make hidden and delete/disable protected
names. When applied to a breakpoint, you will only be able to list,
delete or disable that breakpoint if you refer to it explicitly by ID.
This feature will allow GUI's that need to use breakpoints for their
own purposes to keep their breakpoints from getting accidentally
disabled or deleted.
<rdar://problem/22094452>
llvm-svn: 313292
The main change is to avoid setting the process state as running when
debugging core/minidumps (details in the bug).
Also included a few small, related fixes around how the errors propagate in
this case.
patch by lemo
Bug: https://bugs.llvm.org/show_bug.cgi?id=34532
Differential Revision: https://reviews.llvm.org/D37651
llvm-svn: 313210
When LLDB loads "external" modules it looks at the
presence of DW_AT_GNU_dwo_name.
However, when the already created module
(corresponding to .dwo itself) is being processed,
it will see the presence of DW_AT_GNU_dwo_name
(which contains the name of dwo file) and
will try to call ModuleList::GetSharedModule again.
In some cases (i.e. for empty files) Clang 4.0
generates a *.dwo file which has DW_AT_GNU_dwo_name,
but no DW_AT_comp_dir. In this case the method
ModuleList::GetSharedModule will fail and
the warning will be printed. To workaround this issue,
one can notice that in this case we don't actually need
to try to load the already loaded module (corresponding to .dwo).
Test plan: make check-all
Differential revision: https://reviews.llvm.org/D37295
llvm-svn: 313083
A clang change caused the inclusion of `llvm::Type` and
`lldb_private::Type` to be pulled into the global namespace due to the
`using namespace llvm;` and `using namespace lldb_private;`. Explicitly
qualify the `Type` to resolve the ambiguity. NFC
llvm-svn: 312841
Even though the content of the minidump does not change in a debugging session,
frames can't be indiscriminately be cached since modules and symbols can be
explicitly added after the minidump is loaded.
The fix is simple, just let the base Thread::ClearStackFrames() do its job.
submitted by amccarth on behalf of lemo
Bug: https://bugs.llvm.org/show_bug.cgi?id=34510
Differential Revision: https://reviews.llvm.org/D37527
llvm-svn: 312735
The goal of this patch is twofold:
First, it removes a wrong comment (at least, not correctly describing
what the function does).
Then, it rewrites the function to use a StringSwitch where the
registers are enumerated explicitly instead of being computed
programmatically. Other than being much shorter, it's much easier to
read (and given the ABI won't change anytime soon, I don't think
there's need to generalize).
While here, I added an assert that the register name is always empty,
as the previous implementation of the function assumed so.
Differential Revision: https://reviews.llvm.org/D37420
llvm-svn: 312501
attach by pid worked when running from the directory from which the
target was launched, but failed from a different directory. Use the
kern.proc.pathname sysctl to locate the target, falling back to the
original case of the target's argv[0] if that fails. Based on a patch
from Vignesh Balu.
Differential Revision: https://reviews.llvm.org/D32271
llvm-svn: 312430
The socket bind address should either be localhost or anyaddress. This bug in the listen behavior was preventing lldb-server from opening sockets for non-localhost connections.
The added test verifies that opening an anyaddress socket works and has a non-zero port assignment.
This should resolve PR34183.
llvm-svn: 312008
Summary:
The DWP (DWARF package) format is used to pack multiple dwo files
generated by split-dwarf into a single ELF file to make distributing
them easier. It is part of the DWARFv5 spec and can be generated by
dwp or llvm-dwp from a set of dwo files.
Caviats:
* Only the new version of the dwp format is supported (v2 in GNU
numbering schema and v5 in the DWARF spec). The old version (v1) is
already deprecated but binutils 2.24 still generates that one.
* Combining DWP files with module debugging is not yet supported.
Subscribers: emaste, mgorny, aprantl
Differential Revision: https://reviews.llvm.org/D36062
llvm-svn: 311775
in a dSYM, and it's a version 2 DBGSourcePathRemapping,
in addition to the build/source paths specified, add
build/source paths with the last two filename components
removed. This more generic remapping can sometimes
help lldb to find the correct source file in complex
projects.
<rdar://problem/33973545>
llvm-svn: 311622
The FXSAVE member `ftw` (FPU Tag Word) was given the wrong size (8-bit)
instead of the correct width (16-bit) as per the x87 Programmer's
Manual. Adjust this to ensure that we print out the complete value for
the register.
llvm-svn: 311579
Add explicit linkage to the necessary system libraries in the Host
library. Otherwise, the library fails to build with -Wl,--as-needed.
The system libraries ended up being listed on the linker command-line
before the static libraries needing them, resulting in --as-needed
stripping them.
Listing the dependent libraries explicitly is the canonical way of
declaring libraries in CMake. It guarantees that the system library
dependencies will be correctly propagated to reverse dependencies.
The code used to link libraries reuses existing EXTRA_LIBS variable,
copying code from other parts of LLDB. We might eventually remove
the direct use of system libraries in the programs; however, I would
prefer if we focused on fixing the build regressions in 5.0 branch
first, and went further after the release.
Differential Revision: https://reviews.llvm.org/D36885
llvm-svn: 311354
"Prevent negative chars from being sign-extended into isprint and isspace which take and int and crash if the int is negative"
https://reviews.llvm.org/D36620
llvm-svn: 311207
The Core library calls functions provided by the curses library. Add
an appropriate explicit LINK_LIBS to ${CURSES_LIBRARIES} to propagate
the dependency correctly within the build system.
It seems that so far the linkage was handled by some kind of implicit
magic LLDB_SYSTEM_LIBS variable. However, it stopped working for
unittests as the curses libraries are passed before the LLDBCore
library, resulting in `-Wl,--as-needed` stripping the yet-unused library
before it is required by LLDBCore, and effectively breaking the build.
I think it's better to focus on listing all the dependencies explicitly
and let CMake propagate them rather than trying to figure out why this
hack stopped working.
This is also more consistent with LLVM where the curses linkage
in LLVMSupport is expressed directly in the library rather than deferred
to the final programs.
Differential Revision: https://reviews.llvm.org/D36358
llvm-svn: 311122
* Enable i386 ABI creation for freebsd
* Added an extra argument in ABISysV_i386::PrepareTrivialCall for mmap
syscall
* Unlike linux, the last argument of mmap is actually 64-bit(off_t).
This requires us to push an additional word for the higher order bits.
* Prior to this change, ktrace dump will show mmap failures due to
invalid argument coming from the 6th mmap argument.
Patch by Karnajit Wangkhem
Differential Revision: https://reviews.llvm.org/D34776
llvm-svn: 311002
It was completly unused and broke the part of the encapsulation that
common code shouldn't depend on specific plugins or language specific
features.
llvm-svn: 311000
To detect the correct function name based on the list of available symbols instead of the SDK version
Reviewers: tberghammer, clayborg
Subscribers: jaydeep, bhushan, lldb-commits
Differential Revision: https://reviews.llvm.org/D36445
llvm-svn: 310856
This is the FreeBSD equivalent of r238549.
This serves 2 purposes:
* LLDB should handle inferior process signals SIGSEGV/SIGILL/SIGBUS/
SIGFPE the way it is suppose to be handled. Prior to this fix these
signals will neither create a coredump, nor exit from the debugger
or work for signal handling scenario.
* eInvalidCrashReason need not report "unknown crash reason" if we have
a valid si_signo
llvm.org/pr23699
Patch by Karnajit Wangkhem
Differential Revision: https://reviews.llvm.org/D35223
llvm-svn: 310591
Summary:
The available platform list was previously only accessible via the
`platform list` command, this patch makes it possible to access that
list via the SBDebugger API. The active platform list has likewise
been exposed via the SBDebugger API.
Differential Revision: https://reviews.llvm.org/D35760
llvm-svn: 310452
You can get a breakpoint to auto-continue by adding "continue"
as a command, but that has the disadvantage that if you hit two
breakpoints simultaneously, the continue will force the process
to continue, and maybe even forstalling the commands on the other.
The auto-continue flag means the breakpoints can negotiate about
whether to stop.
Writing tests, I wanted to supply some commands when I made the
breakpoints, so I also added that ability.
llvm-svn: 309969
When an option was set at on a location, I was just copying the whole option set
to the location, and letting it shadow the breakpoint options. That was wrong since
it meant changes to unrelated options on the breakpoint would no longer take on this
location. I added a mask of set options and use that for option propagation.
I also added a "location" property to breakpoints, and added SBBreakpointLocation.{G,S}etCommandLineCommands
since I wanted to use them to write some more test cases.
<rdar://problem/24397798>
llvm-svn: 309772
Summary:
Implement SBProcessInfo to wrap lldb_private::ProcessInstanceInfo,
and add SBProcess::GetProcessInfo() to retrieve info like parent ID,
group ID, user ID etc. from a live process.
Differential Revision: https://reviews.llvm.org/D35881
llvm-svn: 309664
Current LLDB (that is without DWZ support) crashes accessing Fedora debug info:
READ of size 8 at 0x60200000ffc8 thread T0
#0 in DWARFDebugInfoEntry::BuildAddressRangeTable(SymbolFileDWARF*, DWARFCompileUnit const*, DWARFDebugAranges*) const tools/lldb/source/Plugins/SymbolFile/DWARF/DWARFDebugInfoEntry.cpp:1336
Greg Clayton: We will need a warning to be emitted in
SymbolFileDWARF::CalculateAbilities() stating we won't parse the DWARF due to
"unsupported DW_FORM value of 0x1f20".
Patch has been mostly written by Greg Clayton.
Differential revision: https://reviews.llvm.org/D35622
llvm-svn: 309581
Summary:
Clang recently started to emit base address entries into the
.debug_ranges section to reduce the number of relocations needed. Lets
make sure LLDB can read them.
llvm-svn: 309554
This patch does the following:
* Gets the header copy step to re-run whenever header change
* Gets the header fix-up step to re-run whenever headers are copied
* Removes lldb-private*.h headers from the installed headers
llvm-svn: 309394
On iOS frameworks don't have versions or resources, they are flatter bundles. This updates the LLDB framework build to accommodate the flatter bundles.
llvm-svn: 309025
This adds an explicit step for processing the headers and restructures how the framework bundles are constructed. This should make the frameworks more reliably constructed.
llvm-svn: 309024
s_source_map in ClangExternalASTSourceCommon.cpp is unguarded
and therefore can break in multithreaded conditions. This can
cause crashes in particular if multiple targets are being set
up at once.
This patch wraps s_source_map in a function that ensures
exclusivity, and makes every user of it use that function
instead.
<rdar://problem/33429774> lldb crashes after "resume_off"
Differential Revision: https://reviews.llvm.org/D35083
llvm-svn: 308993
Now -shlib flag can be provided alongside with names of symbols files:
(lldb) target symbols add --shlib stripper-lib.so unstripper-lib.so
This is helpful when default matching mechanisms by name and UUID
can't find a module, and the user needs to explicitly specify
which module the given symbol file belongs to.
Differential Revision: https://reviews.llvm.org/D35607
llvm-svn: 308933
This reapplies https://reviews.llvm.org/D35740 with a tweak to find
the section by name rather than type. Section types don't distinguish
between regular sections and their DWO counterparts.
llvm-svn: 308905
The DWO handling code can get confused by clang modules which also use
skeleton CUs to point to the object file with the full debug
info. This patch detects whether an object is a "real" DWO or a clang
module and prevents LLDB from interpreting clang modules as DWO. This
fixes the regression in TestWithModuleDebugging.
http://llvm.org/bugs/show_bug.cgi?id=33875
Differential Revision: https://reviews.llvm.org/D35740
llvm-svn: 308850
This commit removes a very old deprecated API that was causing compile failures for LLDB on Darwin. Since the comment says we only needed to keep the old API around for a few Xcode builds, and the comment was written 6 years ago... I think this can safely go away.
Failure URL:
http://lab.llvm.org:8080/green/view/LLDB/job/lldb_build_test/29936/console
llvm-svn: 308509
Cast to `const uint8_t *` instead of `uint8_t *` to avoid the warning
from GCC.
EmulationStateARM.cpp:206:34: warning: cast from type 'const void*' to type 'uint8_t* {aka unsigned char*}' casts away qualifiers [-Wcast-qual]
Cast to `const uint32_t *` and the explicitly cast away the const-ness
of the value. This seems pretty sketchy as the `DataExtractor` holds a
const reference to the data. However, this is no worse than before.
ObjectFilePECOFF.cpp:540:78: warning: cast from type 'const uint8_t* {aka const unsigned char*}' to type 'uint32_t* {aka unsigned int*}' casts away qualifiers [-Wcast-qual]
llvm-svn: 308489
Summary:
SBBreakpointLocation exposed the ignore count, but didn't expose
the hit count. Both values were exposed by SBBreakpoint and
SBWatchpoint, so this makes things a bit more consistent.
Reviewers: lldb-commits
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31283
llvm-svn: 308480
Summary:
It defined a couple of types (condition_t) which we don't use anymore,
as we have c++11 goodies now. I remove these definitions.
Also it unnecessarily included a couple of headers which weren't
necessary for it's operation. I remove these, and place the includes in
the relevant files (usually .cpp, usually in Host code) which use them.
This allows us to reduce namespace pollution in most of the lldb files
which don't need the OS-specific definitions.
Reviewers: zturner, jingham
Subscribers: ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D35113
llvm-svn: 308304
Summary:
The usage of shared_from_this forces us to separate construction and
initialization phases, because shared_from_this() is not available in
the constructor (or destructor). The shared semantics are not necessary,
as we always have a clear owner of the native process class
(GDBRemoteCommunicationServerLLDB object). Even if we need shared
semantics in the future (which I think we should strongly avoid),
reverting this will not be necessary -- the owners can still easily
store the native process object in a shared pointer if they really want
to -- this just prevents the knowledge of that from leaking into the
class implementation.
After this a NativeThread object will hold a reference to the parent
process (instead of a weak_ptr) -- having a process instance always
available allows us to simplify some logic in this class (some of it was
already simplified because we were asserting that the process is
available, but this makes it obvious).
Reviewers: krytarowski, eugene, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D35123
llvm-svn: 308282
While adding IPv6 support to debugserver I broke handling wildcard addresses and fully qualified address filtering. This patch resolves that bug and adds a test for matching the address "*".
<rdar://problem/32947613>
llvm-svn: 307957
The interpreter gets invoked in the sigint handler to cancel
long-running Python operations. That requires the interpreter
lock, but that may be held by the Python operation that's getting
interrupted, so the mutex needs to be recursive.
<rdar://problem/33179086>
llvm-svn: 307942
Store file descriptors from loop.m_read_fds (if FORCE_PSELECT is
defined) and signals from loop.m_signals that need to be processed in
MainLoop::RunImpl::ProcessEvents() into a separate vector and then
iterate over this container to invoke the callbacks.
This prevents a problem where when the code iterated directly over
m_read_fds/m_signals, a callback invoked from within the loop could
modify these variables and invalidate the loop iterator. This would then
result in an assertion failure in llvm::DenseMapIterator::operator++().
Differential Revision: https://reviews.llvm.org/D35298
llvm-svn: 307782
Summary:
This patch adds support for sending strings along with
error codes in the reply packets. The implementation is
based on the feedback recieved in the lldb-dev mailing
list. The patch also adds an extra packet for the client
to query if the server has the capability to provide
strings along with error replys.
Reviewers: labath, jingham, sas, lldb-commits, clayborg
Reviewed By: labath, clayborg
Differential Revision: https://reviews.llvm.org/D34945
llvm-svn: 307768
Summary:
Testing the value of type_code against the closed enum TypeCodes
provides statically verifiable completeness of testing. However, one
branch assigns to type_code by casting directly from a masked integer
value. This is currently handled by adding a default: case after
checking each TypeCodes instance. This patch introduces a bool variable
containing the "default" state value, allowing the switch to be
exhaustive, protect against future instances not being handled in the
switch, and preserves the original logic.
This addresses the warning:
warning: default label in switch which covers all enumeration values
[-Wcovered-switch-default]
As an issue of maintainability, the bitmask on line 524 handles the
current values of TypeCodes enum, but this will be invalid if the enum
is extended. This patch does not address this, and a more closed
conversion from cfinfoa -> TypeCodes would help protect against this.
Reviewers: spyffe, lhames, sas
Reviewed By: sas
Subscribers: sas, lldb-commits
Differential Revision: https://reviews.llvm.org/D35036
llvm-svn: 307712
In NativeProcessLinux::MonitorSIGTRAP we were asserting that the si_code
value is one of the codes we know about. However, that list was very
incomplete -- for example, we were not handling SI_TKILL/SI_USER,
generated by raise(SIGTRAP). A cursory examination show there are at
least a dozen codes like these that an app can generate, and more can be
added at any point.
So, instead of trying to play catchup, I change the default behavior to
treat an unknown si_code like an ordinary signal. The only reason we
needed to inspect si_code in the first place is because
watchpoint/breakpoints are notified as SIGTRAP, but we already know
about those, and us starting to use a new debug event is far less likely
than somebody introducing a new non-debug event.
I add a test case to TestRaise to verify we are handling raise(SIGTRAP)
in an application properly.
llvm-svn: 307644
Summary:
On linux on ppc64le some of the enums in AuxVector have the same name
as macros defined in the system.
Reviewers: mikesart, labath
Reviewed By: labath
Subscribers: joerg, gut, krytarowski, lldb-commits
Differential Revision: https://reviews.llvm.org/D35065
Patch by Bruno Rosa <bruno.rosa@eldorado.org.br>
llvm-svn: 307632
blocks of memory, and if the final bytes of that block look like a long
x86 instruction, it can cause the llvm disassembler to read past the end
of the buffer. Use the maximum allowed instruction length that we pass
to the llvm disassembler as a way to limit this to the size of the buffer.
An example of how to trigger this is when lldb does a function call, it
puts a breakpoint on the beginning of main() and uses that as the return
address from the function call. When we stop at that location, lldb may
try to find the first frame up the stack. Because this is on the first
instruction of a function, it will get the word-size value at the stack
pointer and assume that this was the caller's pc value. But this is random
stack memory and could point to anything - an object in memory, something
in the data section, whatever. And if we have a symbol for that thing,
we'll try to disassemble it.
This was leading to infrequent crashes in customer scenarios; figured out
what was happening with address sanitizer.
<rdar://problem/30463256>
llvm-svn: 307454
Summary:
This replaces the static functions used for creating
NativeProcessProtocol instances with a factory pattern, and modernizes
the interface of the new class in the process -- I use llvm::Expected
instead of the Status+value combo. I also move some of the common code
(like the Delegate registration into the base class). The new
arrangement has multiple benefits:
- it removes the NativeProcess*** dependency from Process/gdb-remote
(which for example means that liblldb no longer pulls in this code).
- it enables unit testing of the GDBRemoteCommunicationServerLLGS class
(by providing a mock Native Process).
- serves as another example on how to use the llvm::Expected class (I
couldn't get rid of the Initialize-type functions completely here
because of the use of shared_from_this, but that's the next thing on
my list here)
Tests still pass on Linux and I've made sure NetBSD compiles after this.
Reviewers: zturner, eugene, krytarowski
Subscribers: srhines, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33778
llvm-svn: 307390
Summary:
On older android targets, we needed a dlopen rename workaround to get
"process load" working. Since API 26 this is not required as the targets
have a proper libdl so with the function names one would expect.
To make this work I've had to remove the const qualifier from the
GetLibdlFunctionDeclarations function (as now the declarations can
depend on the connected target). Since I was already modifying the
prototype (and the lower levels were already converted to StringRef) I
took the oportunity to convert this function as well.
llvm-svn: 307160
Summary:
The std::move was preventing copy ellision when compiled with
clang, the patch fixes the warning along with rearranging code
to remove unused variables warnings on Linux machines with
older perf_event interface.
Reviewers: labath, ted
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D34946
llvm-svn: 307030
NSSetM has two in-memory representations depending on what Foundation version is in use.
This patch separates the two.
rdar://33057292
Differential Revision: https://reviews.llvm.org/D34821
llvm-svn: 306773
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
Summary:
The instruction pattern:
and $-16, %esp
sub $imm, %esp
...
lea imm(%ebp), %esp
appears when the compiler is realigning the stack (for example in
main(), or almost everywhere with -mstackrealign switch). The "and"
instruction is very difficult to model, but that's not necessary, as
these frames are always %ebp-based (the compiler also needs a way to
restore the original %esp). Therefore the plans we were generating for
these function were almost correct already. The only place we were doing
it wrong were the last instructions of the epilogue (usually just
"ret"), where we had to revert to %esp-based unwinding, as the %ebp had
been popped already.
This was wrong because our "distance of esp from cfa" counter had picked
up the "sub" instruction (and incremented the counter) but it had not
seen that the register was reset by the "lea" instruction.
This patch fixes that shortcoming, and adds a test for handling
functions like this.
I have not been able to tickle the compiler into producing a 64-bit
function with this pattern, but I don't see a reason why it couldn't
produce it, if it chose to, so I add a x86_64 test as well.
Reviewers: jasonmolenda, tberghammer
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D34750
llvm-svn: 306666
some methods in the ABI need a Process to do their work.
Instead of passing it in as a one-off argument to those
methods, this patch puts it in the base class and the methods
can retrieve if it needed.
Note that ABI's are sometimes built without a Process
(e.g. SBTarget::GetStackRedZoneSize) so it's entirely
possible that the process weak pointer will not be
able to reconsistitue into a strong pointer.
<rdar://problem/32526754>
llvm-svn: 306633
Summary:
instead of using a boolean to differentiate between the two section
types, use an enum to make the intent clearer.
I also remove the RegisterKind argument from the constructor, as this
can be deduced from the Type argument.
Reviewers: clayborg, jasonmolenda
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D34681
llvm-svn: 306521
Summary:
This patch implements support for Intel(R) Processor Trace
in lldb server. The changes have support for
starting/stopping and reading the trace data. The code
is only available on Linux versions where the perf
attributes for aux buffers are available.
The patch also consists of Unit tests for testing the
core buffer reading function.
Reviewers: lldb-commits, labath, clayborg, zturner, tberghammer
Reviewed By: labath, clayborg
Subscribers: mgorny
Differential Revision: https://reviews.llvm.org/D33674
llvm-svn: 306516
Summary:
This is a beefed-up version of D33504, which adds support for dwarf 4
debug_frame section format.
The main difference here is that the decision whether to use eh_frame or
debug_frame is done on a per-function basis instead of per-object file.
This is necessary because one module can contain both sections (for
example, the start files added by the linker will typically pull in
eh_frame), but we want to be able to access both, for maximum
information.
I also add unit test for parsing various CFI formats (eh_frame,
debug_frame v3 and debug_frame v4).
Reviewers: jasonmolenda, clayborg
Subscribers: mgorny, aprantl, abidh, lldb-commits, tatyana-krasnukha
Differential Revision: https://reviews.llvm.org/D34613
llvm-svn: 306397
Summary:
It had a dependency on StringConvert and file reading code, which is not
in Utility. I've replaced that code by equivalent llvm operations.
I've added a unit test to demonstrate that parsing a file still works.
Reviewers: zturner, jingham
Subscribers: kubamracek, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34625
llvm-svn: 306394
Summary:
These interfaces have no dependencies, so it makes sense for them to be
in the lowest level modules, to make sure that other parts of the
codebase can use them without introducing loops.
The only exception here is the Connection::CreateDefaultConnection
method, which I've moved to Host, as it instantiates concrete
implementations, and that's where the implementations live.
Reviewers: jingham, zturner
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34400
llvm-svn: 306391
Summary:
The new UndefinedBehaviorSanitizer plugin was breaking file path length
limits, because it's (fairly long name) appears multiple times in the
path. Cmake ends up putting the object file at path
tools/lldb/source/Plugins/InstrumentationRuntime/UndefinedBehaviorSanitizer/CMakeFiles/lldbPluginInstrumentationRuntimeUndefinedBehaviorSanitizer.dir/UndefinedBehaviorSanitizerRuntime.cpp.obj
which is 191 characters long and very dangerously close to the 260
character path limit on windows systems (also, just the include line for
that file was breaking the 80 character line limit).
This renames the sanitizer plugins to use shorter names (asan, ubsan,
tsan). I think this will still be quite understandable to everyone as
those are the names everyone uses to refer to them anyway.
Reviewers: zturner, kubamracek, jingham
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D34553
llvm-svn: 306278
This was broken due to directly including windows.h, which
caused a problem when someone in LLVM called std::min in a header
file. LLDB has a windows.h include to work around this, but it
wasn't being used in these two files.
llvm-svn: 306186
Summary: Reported by coverity, I don't know how to provide a test.
Reviewers: zturner
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D34550
llvm-svn: 306134
Summary:
This is basically a revert of D16107 and parts of D10800, which were
trying to get vdso loading working. They did this by implementing a
generic load-an-elf-file from memory approach, which is not correct,
since we cannot assume that an elf file is loaded in memory in full (it
usually isn't, as there's no need to load section headers for example).
This meant that we would read garbage instead of section sizes, and if
that garbage happened to be a large number, we would crash while trying
to allocate a buffer to accomodate the hypothetical section.
Instead of this, I add a bit of custom code to load the vdso to
DynamicLoaderPOSIXDYLD (which already needed to handle the vdso
specially). I determine the size of the memory to read using
Process::GetMemoryRegionInfo, which is information coming from the OS,
and cannot be forged by a malicious/misbehaving application.
Reviewers: eugene, clayborg
Subscribers: lldb-commits, ravitheja, tberghammer, emaste
Differential Revision: https://reviews.llvm.org/D34352
llvm-svn: 305780
Summary:
Use c++11 thread_local variables instead. As far as I am aware, they are
supported by all compilers/targets we care about.
Reviewers: zturner, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D34274
llvm-svn: 305779
I was seeing some unlikely errno values here. I am not sure if this will
help, but it nontheless seems like a good idea to stash errno value
before issuing other syscalls.
llvm-svn: 305778
Summary:
A number of places were trying to decode the result of wait(). Add a simple
utility function that does that and a struct that encapsulates the
decoded result. Then also provide a pretty-printer for that class.
Reviewers: zturner, krytarowski, eugene
Subscribers: lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D33998
llvm-svn: 305689
Summary:
The motivation for this is to make sure the first row of the plan
compares equal to the first row of a generic debug_frame unwind plan.
Right now, the code in FuncUnwinders::GetUnwindPlanAtNonCallSite
considers them unequal because they specify the return address in a
different way (SetReturnAddressRegister(LR) vs. an explicit PC=LR rule).
This means that FuncUnwinders would always choose the debug_frame unwind
plan, which is not correct, as that one is usually not correct at all
locations.
Right now this is basically a noop because we don't have parse any
debug_frame plans, but it fixes some test failures when merging D33504
in.
I have to say I don't understand the full implications of the switch to
SetReturnAddressRegister() way of doing things, but given that all of
our other unwind plans (eh_frame, instruction profiling) do it this way,
it sounds like the right thing to do.
Reviewers: tberghammer, jasonmolenda, omjavaid
Subscribers: aemerson, javed.absar, kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D34199
llvm-svn: 305687
Summary:
ProcessLauncherPosix was using posix_spawn for launching the process,
but this function is not available on all platforms we support, and even
where it was avaialable, it did not support the full range of options we
require for launching (most importantly, launching in stop-on-entry
mode). For these reasons, the set of ifdefs around these functions has
grown untractably large, and we were forced to implement our own
launcher from more basic primitives anyway (ProcessLauncherPosixFork --
used on Linux, Android, and NetBSD).
Therefore, I remove this class, and move the relevant parts of the code
to the darwin-specific Host.mm file. This is the platform that code was
originally written for anyway, and it's the only platform where this
implementation makes sense (e.g. the lack of the "thread-specific
working directory" concept makes these functions racy on all other
platforms). This allows us to remove a lot of ifdefs and simplify the
code.
Effectively, the only change this introduces is that FreeBSD will now
use the fork-based launcher instead of posix_spawnp. That sholdn't be a
problem as this approach works at least on one other BSD-based system
already.
Reviewers: krytarowski, emaste, jingham
Subscribers: srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34236
llvm-svn: 305686
the FileSpec methods for adding/removing file path components instead
of using std::strings; feedback from Sean on the change I added in
r305441.
<rdar://problem/31825940>
llvm-svn: 305547
components to not depend on "." characters in the fileanme
(e.g. "Foundation.framework") but instead to just use path
separators. The names of the files themselves may have dots
in them ("com.apple.sbd") which would break the old scheme.
Also add a test case for this (macosx/find-dsym/bundle-with-dot-in-filename)
as well as a test case for r304520 (macosx/find-dsym/deep-bundle)
which needed a similar setup to test correctly on a single machine.
(both of these are really testing remote debug session situations
where the binary can't be found on the system where lldb is running,
complicating the test case a bit.)
<rdar://problem/31825940>
llvm-svn: 305441
This patch introduces a new thread backtrace command "unique".
The command is based off of "thread backtrace all" but will instead
find all threads which share matching call stacks and de-duplicate
their output, listing call stack and all the threads which share it.
This is especially useful for apps which use thread/task pools
sitting around waiting for work and cause excessive duplicate output.
I needed this behavior recently when debugging a core with 700+ threads.
Differential Revision: https://reviews.llvm.org/D33426
Reviewers: clayborg, jingham
Patch by Brian Gianforcaro <b.gianfo@gmail.com>
llvm-svn: 305197
Summary:
When a call instruction is the last instruction in a function, the
backtrace PC will point past the end of the function. We already had
special code to handle that, but we did not handle the case where the PC
ends up outside of the bounds of the module containing the function,
which is a situation that occured in TestNoreturnUnwind on android for
some arch/compiler combinations.
I fix this by adding an argument to Address resolution code which states
that we are ok with addresses pointing to the end of a module/section to
resolve to that module/section.
I create a reproducible test case for this situation by hand-crafting an
executable which has a noreturn function at the end of a module.
Reviewers: jasonmolenda, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D32022
llvm-svn: 304976
The function does not persist the callback, so using a lighter-weight
asbtraction seems appropriate.
Also tweak the signatures of the lambdas to match what the TaskMap
interface expects.
llvm-svn: 304924
This creates a new library called BinaryFormat that has all of
the headers from llvm/Support containing structure and layout
definitions for various types of binary formats like dwarf, coff,
elf, etc as well as the code for identifying a file from its
magic.
Differential Revision: https://reviews.llvm.org/D33843
llvm-svn: 304864
strerror is not thread-safe. llvm's StrError tries hard to retrieve the
string in a thread-safe way and falls back to strerror only if it does
not have another way.
llvm-svn: 304795
Summary:
Don't access `name[1] if the string is only of length 1. Avoids a
crash/assertion failure when parsing the string `-`.
Test Plan:
Debug a swift binary, set a breakpoint, watch lldb not crash
Original change by Paul Menage <menage@fb.com>
Reviewers: lldb-commits, clayborg
Differential Revision: https://reviews.llvm.org/D33853
llvm-svn: 304725
from PlatformRemoteDarwinDevice into PlatformDarwin, and have both
PlatformRemoteDarwinDevice and PlatformMacOSX call it there.
<rdar://problem/31825940>
llvm-svn: 304520
When parsing types originating in modules, it is possible to encounter AttributedTypes
(such as the type generated for NSString *_Nonnull). Some of LLDB's ClangASTContext
methods deal with them; others do not. In particular, one function that did not was
GetTypeInfo, causing TestObjCNewSyntax to fail.
This fixes that, treating AttributedType as essentially transparent and getting the
information for the modified type.
In addition, however, TestObjCNewSyntax is a monolithic test that verifies a bunch of
different things, all of which can break independently of one another. I broke it
apart into smaller tests so that we get more precise failures when something (like
this) breaks.
Differential Revision: https://reviews.llvm.org/D33812
llvm-svn: 304510
Eugene Zemtsov