I'm not able to reproduce the reproducer flakiness we're seeing on
GreenDragon. I want to add this assert to find out if the GDB remote
packets are somehow getting out of sync when this happens.
llvm-svn: 364852
Summary:
Instead of falling back to ObjCLanguageRuntime, we should be falling
back to every loaded language runtime. This makes ValueObject more
language agnostic.
Reviewers: labath, compnerd, JDevlieghere, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D63240
llvm-svn: 364845
Set global enable bits (i.e. bits 1, 3, 5, 7) to enable watchpoints
on NetBSD rather than the local enable bits (0, 2, 4, 6). The former
are necessary for watchpoints to be correctly recognized by the NetBSD
kernel. The latter cause them to be reported as trace points.
Differential Revision: https://reviews.llvm.org/D63792
llvm-svn: 364781
Fix the watchpoint/breakpoint code to search for matching thread entry
in m_threads explicitly rather than assuming that it will be present
at specified index. The previous code segfault since it wrongly assumed
that the index will match LWP ID which was incorrect even for a single
thread (where index was 0 and LWP ID was 1).
While fixing that off-by-one error would help for this specific task,
I believe it is better to be explicit in what we are searching for.
Differential Revision: https://reviews.llvm.org/D63791
llvm-svn: 364780
Provide a (conditional) support for the new PT_GETXSTATE
and PT_SETXSTATE ptrace() requests, and use them to implement getting
and setting YMM registers. The functions used for splitting
and recombining YMM register data are based on matching functions
in FreeBSD plugin, with some simplification and updates to match NetBSD
structures.
Differential Revision: https://reviews.llvm.org/D63545
llvm-svn: 364779
A bunch of places were checking that DataBufferHeap::GetBytes returns a
non-null pointer right after constructing it. The only time when
GetBytes returns a null pointer is if it is empty (and I'm not sure that
even this is a good idea), but that is clearly not the case here, as the
buffer was constructed with a non-zero size just a couple of lines back.
llvm-svn: 364754
D62502, together with D62503 have broken the builds which have XML
support enabled. Reverting D62503 (r364355) fixed that, but has broken
has left some of the tests introduced by D62502 broken more or less
nondeternimistically (it depended on whether the system happens to place
the library list near unreadable pages of memory). I attempted to make a
partial fix for this in r364748, but Jan Kratochvil pointed out that
this reintroduces the problem which reverting D62503 was trying to
solve.
So instead, I back out the whole thing so we can get back to a clean
slate that works for everyone. We can figure out a way forward from
there.
This reverts r364748, r363772 and r363707.
llvm-svn: 364751
D62502 had a bug (visible only with D62503 reverted), where it would
error out if attempting to read a string from memory and the memory page
after the string happened to be unmapped.
This fixes the problem by checking for whether ReadMemory read *any*
bytes, instead of checking whether it returned an error. A greater
question is whether ReadMemory should even return an error if it read at
least one byte, but I'm leaving that for a separate patch.
llvm-svn: 364748
operator new doesn't return a null pointer, even if one turns off
exceptions (it calls std::terminate instead). Therefore, all of this is
dead code.
llvm-svn: 364744
The arbitrary timeout when flushing GDB remote packets caused
non-determinism and flakiness between test runs. I suspect it is what's
causing the flakiness of the reproducer tests on GreenDragon, and want
to see if removing it causes that to go away.
This change was originally introduced in r197579 to discard a
`$T02thread:01;#4` that QEMU was sending. If anybody knows how to test
that this continues working after removing this code, I'd love to hear
it.
llvm-svn: 364669
on a thread. When talking to some older gdb-remote stubs, We were getting
a stop reason from the stop reply packet and setting it on the relevant
thread before we updated the full stop list. That would get discarded when
the full list was updated.
Also, if you already have a thread list when you go to see if there is an
Operating System plugin, and you do indeed load a new OS plugin, you have to
re-fetch the thread list or it will only show the raw threads.
Differential Revision: https://reviews.llvm.org/D62887
llvm-svn: 364666
Reenable SysV x86_64 ABI usage on NetBSD that was accidentally removed
in r364216. This fixes numerous test failures with messages similar
to the following:
error: Can't run the expression locally: Interpreter doesn't handle
one of the expression's opcodes
llvm-svn: 364503
This fixes two replay issues that caused the tests to behave
erratically:
1. It fixes an off-by-one error, where all replies where shifted by 1
because of a `+` packet that should've been ignored.
2. It fixes another off-by-one-error, where an asynchronous ^C was
offsetting all subsequent packets. The reason is that we
'synchronize' requests and replies. In reality, a stop reply is only
sent when the process halt. During replay however, we instantly
report the stop, as the reply to packets like continue (vCont).
Both packets should be ignored, and indeed, checking the gdb-remote log,
no unexpected packets are received anymore.
Additionally, be more pedantic when it comes to unexpected packets and
return an failure form the replay server. This way we should be able to
catch these things faster in the future.
llvm-svn: 364494
The qemu x86_64 target returns a target.xml register definition file which
includes other xml files and they include others, etc. Also, the registers
are not put in register groups like lldb wants to see.
This patch (1) puts registers that aren't in a register group in a "general"
register group, (2) change ProcessGDBRemote::GetGDBServerRegisterInfo to
be a method that starts the parsing, asking a recurisve function to fetch
and parse target.xml, (3) adds
ProcessGDBRemote::GetGDBServerRegisterInfoXMLAndProcess which can recusively
call itself to read and parse included xml files, (4) in addition to expecting
the top-level <target> element (which only happens in the top level xml file),
also an xml file that consists of a <feature> node - read the register
defintions and includes from that <feature> element.
<rdar://problem/49537922>
Differential revision: https://reviews.llvm.org/D63802
llvm-svn: 364484
Copy over access and modification time for the files included in the
reproducer. This is needed to pass tests that check the integrity of
object files based on their time stamp.
llvm-svn: 364457
Unfortunately I had to work backwards from a crash log,
so I don't have a good testcase at this point in time.
rdar://problem/51874647
llvm-svn: 364344
Make sure the prompt has been flushed before reading commands. Buffering
is different in Python 3, which led to the prompt not being displayed in
the Xcode console.
llvm-svn: 364335
Relying on the value of optind for detecting missing arguments is
unreliable because its value after a failed parse is an implementation
detail. A more correct way to achieve this is to pass ':' at the
beginning of option string, which tells getopt to return ':' for missing
arguments.
For this to work, I also had to add a nullptr at the end of the argv
vector, as some getopt implementations did not work without that. This
is also an implementation detail, as getopt should normally be called
with argc+argc "as to main function" (i.e. null-terminated).
Thanks to Michał Górny for testing this patch out on NetBSD.
llvm-svn: 364317
Summary:
If target.preload-symbols is false, waiting for the process to "stop"
can take an arbitrarily long amount of time, because it will cause all
the debug info to be parsed (to compute the stop message showing the
function, its arguments, etc).
We were previously waiting for 10 seconds for the stop even to arrive,
which is a pretty long time, but it's not that hard to overcome with
huge debug info.
Since any arbitrary limit can be theoretically overcome with huge
debug_info and/or slow machine, and the stop even was sent 3 lines above
the wait, if we ever do not receive the stop even means we've got a bug
in lldb. Therefore, I remove the timeout on this wait completely.
No test because I don't know how to reproduce this without a
multi-gigabyte symbol file.
Reviewers: jingham, clayborg
Subscribers: aprantl, lldb-commits
Differential Revision: https://reviews.llvm.org/D63730
llvm-svn: 364276
Summary:
With the last round of refactors, supporting type units in dwo files
becomes almost trivial. This patch contains a couple of small fixes,
which taken as a whole make type units work in the split dwarf scenario
(both DWARF4 and DWARF5):
- DWARFContext: make sure we actually read the debug_types.dwo section
- DWARFUnit: set string offsets base on all units in the dwo file, not
just the main CU
- ManualDWARFIndex: index all units in the file
- SymbolFileDWARFDwo: Search for the single compile unit in the file, as
we can no longer assume it will be the first one
The last part makes it obvious that there is still some work to be done
here, namely that we do not support dwo files with multiple compile
units. That is something that should be easier after the DIERef
refactors, but it still requires more work.
Tests are added for the type units+split dwarf + dwarf4/5 scenarios, as
well as a test that checks we behave reasonably in the presence of dwo
files with multiple CUs.
Reviewers: clayborg, JDevlieghere, aprantl
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63643
llvm-svn: 364274
+ dlsym the two functions we need from there at runtime.
I'm not maintaining a negative cache if DebugSymbols is absent, so
we'll try to dlopen() it on every call to
LocateMacOSXFilesUsingDebugSymbols but this file is only built on
mac and iOS type systems, so there's a slight perf impact running
lldb on an iOS type system.
I store the function pointer results in two global variables without
any locking; two threads calling into LocateMacOSXFilesUsingDebugSymbols
for the first time will both try to set these fptrs, but they'll be
setting them to the same value, so I'm not too worried.
I didn't see where in the cmake build configurations we link against
DebugSymbols, but I removed the dependency from the xcode project
file.
<rdar://problem/49458356>
llvm-svn: 364243
Summary:
It's possible that each LanguageRuntime could have its own DeclVendor,
so let's hoist that out of ObjCLanguageRuntime into LanguageRuntime.
Additionally, this gives the opportunity to remove SBTarget's dependency
on ObjCLanguageRuntime.
Reviewers: JDevlieghere, labath, compnerd, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D63622
llvm-svn: 364229
Summary:
Implement the ABI for WIndows-x86_64 including register info and calling convention.
Handled nested struct returned in register (SysV doesn't have it supported)
Reviewers: xiaobai, compnerd
Reviewed By: compnerd
Subscribers: labath, jasonmolenda, fedor.sergeev, mgorny, teemperor, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62213
llvm-svn: 364216
Summary:
This change extracts functionalities from processwindows into a
introduced processdebugger that can be reused in native process
debugging.
The main reason is that the native process debugging
can't directly be based on processwindows or be implemented
as a pass-through to this plugin since the plugin has ties to
Target and Process classes that are needed in host debugging but
not necessary in native debugging.
Reviewers: labath, Hui, jfb, clayborg, amccarth
Reviewed By: labath
Subscribers: amccarth, dexonsmith, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D63166
llvm-svn: 364210
Summary:
ObjCLanguageRuntime was being pulled into LanguageRuntime because of
Breakpoint Preconditions. If we move BreakpointPrecondition out of Breakpoint,
we can extend the LanguageRuntime plugin interface so that LanguageRuntimes
can give us a BreakpointPrecondition for exceptions.
Differential Revision: https://reviews.llvm.org/D63181
llvm-svn: 364098
Introduce two common helpers to take care of splitting and recombining
YMM registers to/from XSAVE-like data. Since FreeBSD, Linux and NetBSD
all use XSAVE-like data structures but with potentially different field
layouts, the function takes two pointers -- to XMM register and to YMM
high bits, and copies the data from/to YMMReg type.
While at it, remove support for big endian. To mine and Pavel Labath's
combined knowledge, there is no such thing on x86. Furthermore,
assuming that the YMM register data would be swapped for big endian
seems to be a weird assumption.
Differential Revision: https://reviews.llvm.org/D63610
llvm-svn: 364042
Summary:
When dwo support was introduced, it used a trick where debug info
entries were referenced by the offset of the compile unit in the main
file, but the die offset was relative to the dwo file. Although there
was some elegance to it, this representation was starting to reach its
breaking point:
- the fact that the skeleton compile unit owned the DWO file meant that
it was impossible (or at least hard and unintuitive) to support DWO
files containing more than one compile unit. These kinds of files are
produced by LTO for example.
- it made it impossible to reference any DIEs in the skeleton compile
unit (although the skeleton units are generally empty, clang still
puts some info into them with -fsplit-dwarf-inlining).
- (current motivation) it made it very hard to support type units placed
in DWO files, as type units don't have any skeleton units which could
be referenced in the main file
This patch addresses this problem by introducing an new
"dwo_num" field to the DIERef class, whose purpose is to identify the
dwo file. It's kind of similar to the dwo_id field in DWARF5 unit
headers, but while this is a 64bit hash whose main purpose is to catch
file mismatches, this is just a smaller integer used to indentify a
loaded dwo file. Currently, this is based on the index of the skeleton
compile unit which owns the dwo file, but it is intended to be
eventually independent of that (to support the LTO use case).
Simultaneously the cu_offset is dropped to conserve space, as it is no
longer necessary. This means we can remove the "BaseObjectOffset" field
from the DWARFUnit class. It also means we can remove some of the
workarounds put in place to support the skeleton-unit+dwo-die combo.
More work is needed to remove all of them, which is out of scope of this
patch.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: mehdi_amini, dexonsmith, arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63428
llvm-svn: 364009
Remove most of the abstraction over ptrace() register operations,
as it has little value and introduces more code than it saves.
Instead, leave a single ptrace() wrapper method and call it directly
from ReadRegisterSet() and WriteRegisterSet() with correct PT_* request
and buffer.
Remove the remaining direct ReadGPR() and WriteGPR() invocations
with ReadRegisterSet() and WriteRegisterSet().
Cleanup suggested by Pavel Labath in D63545.
Differential Revision: https://reviews.llvm.org/D63594
llvm-svn: 363923
That commit changed DIERef from a struct to a class, but did not update
the forward-declarations. This fixes one forward-declaration, and
removes other (unused) decls.
llvm-svn: 363915
Summary:
Instead of accessing the fields directly, use accessor functions to
provide access to the DIERef components. This allows us to decouple the
external interface, from the internal representation. The external
interface can use llvm::Optional and similar goodies, while the data can
still be stored internally in a more compact representation.
I also document the purpose of the existing DIERef fields.
The main motivation for this change is a need to introduce an additional
field to the DIERef class, but I believe the change has its own merit.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63400
llvm-svn: 363910
Summary:
These fields are unused and have been since their inception, from what
I can tell.
Reviewers: compnerd, JDevlieghere, davide, labath
Subscribers: kubamracek, lldb-commits
Differential Revision: https://reviews.llvm.org/D63357
llvm-svn: 363881
Remove the checks for FPU presence, FXSAVE support and usage from
the code for x86_64. Those are always true for this architecture,
and in fact are hardcoded to true inside NetBSD kernel.
Differential Revision: https://reviews.llvm.org/D63554
llvm-svn: 363823
Summary:
This patch makes the DIERef class always valid by default constructor
and operator bool. This allows one to express the validity of a DIERef
in the type system. Places which are working with potentially-invalid
DIERefs have been updated to use Optional<DIERef> instead.
The constructor taking a DWARFFormValue was not needed, as all places
which were constructing a DIERef this way were immediately converting it
into a DWARFDIE or a user_id. This can be done without constructing an
intermediate DIERef.
Reviewers: JDevlieghere, clayborg, aprantl
Subscribers: arphaman, lldb-commits
Differential Revision: https://reviews.llvm.org/D63399
llvm-svn: 363767
Summary:
This is the fifth patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499
Reading strings with ReadMemory is really slow when reading the path of the shared library. This is because we don't know the length of the path so use PATH_MAX (4096) and these strings are actually super close to the boundary of an unreadable page. So even though we use process_vm_readv it will usually fail because the read size spans to the unreadable page and we then default to read the string word by word with ptrace.
This new function is very similar to another ReadCStringFromMemory that already exists in lldb that makes sure it never reads cross page boundaries and checks if we already read the entire string by finding '\0'.
I was able to reduce the GetLoadedSharedLibraries call from 30ms to 4ms (or something of that order).
Reviewers: clayborg, xiaobai, labath
Reviewed By: labath
Subscribers: emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62503
llvm-svn: 363750
Summary:
This is the fourth patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499
Implement the `xfer:libraries-svr4` packet by adding a new function that generates the list and then in Handle_xfer I generate the XML for it. The XML is really simple so I'm just using string concatenation because I believe it's more readable than having to deal with a DOM api.
Reviewers: clayborg, xiaobai, labath
Reviewed By: labath
Subscribers: emaste, mgorny, srhines, krytarowski, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62502
llvm-svn: 363707
Before this patch, reproducers weren't relocatable. The reproducer
contained hard coded paths in the VFS mapping, as well in the yaml file
listing the different input files for the command interpreter. This
patch changes that:
- Use relative paths for the DataCollector.
- Use an overlay prefix for the FileCollector.
Differential revision: https://reviews.llvm.org/D63467
llvm-svn: 363697
Now that we correctly ignore ASCII escape sequences when colors are
disabled (r362240), I'd like to change the default frame and thread
format to include color in their output, in line with the syntax
highlighting that Raphael added a while ago.
This patch adds highlighting for the stop reason, the file, line and
column number. With colors disabled, this of course is a no-op.
Differential revision: https://reviews.llvm.org/D62743
llvm-svn: 363608
Jonas Devlieghere