Summary:
This replaces all the uses of the __ANDROID_NDK__ define with __ANDROID__. This
is a preparatory step to remove our custom android toolchain file and rely on
the standard android NDK one instead, which does not provide this define.
Instead I rely, on __ANDROID__, which is set by the compiler.
I haven't yet removed the cmake variable with the same name, as we will need to
do something completely different there -- NDK toolchain defines
CMAKE_SYSTEM_NAME to Android, while our current one pretends it's linux.
Reviewers: tberghammer, zturner
Subscribers: danalbert, srhines, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D27305
llvm-svn: 288494
Summary:
Communication classes use the Timeout<> class to specify the timeout. Listener
class was converted to chrono some time ago, but it used a different meaning for
a timeout of zero (Listener: infinite wait, Communication: no wait). Instead,
Listener provided separate functions which performed a non-blocking event read.
This converts the Listener class to the new Timeout class, to improve
consistency. It also allows us to get merge the different GetNextEvent*** and
WaitForEvent*** functions into one. No functional change intended.
Reviewers: jingham, clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D27136
llvm-svn: 288238
We were referencing a the process class from a register context, which seems
intuitively wrong. Also, the comment above that code is now definitely incorrect,
as ProcessElfCore now does support floating point registers. Also, the code
wasn't really doing anything, as it was just skipping a zero-initialization of a
field that was most likely zero-initialized anyway. Linux elf core FPR test still
passes after this.
llvm-svn: 288237
Summary:
While adding FPR support to x86 elf core files (D26300), we ended up adding a
very x86-specific function to the general RegisterInfoInterface class, which I
didn't catch in review. This removes that function. The only reason we needed
it was to find the offset of the FXSAVE area. This is the same as the offset of
the first register within that area, so we might as well use that.
Reviewers: clayborg, dvlahovski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D27222
llvm-svn: 288236
Switch various bits of platform-specific code to chrono that I did not notice
when doing a linux build. This exposed a bug that ConnectionGenericFileWindows
did not handle the magic UINT32_MAX timeout value (instead it waited for about an
hour, which is close enough I guess). Fix that as well.
llvm-svn: 287927
This replaces the raw integer timeout parameters in the class with their
chrono-based equivalents. To achieve this, I have moved the Timeout class to a
more generic place and added a quick unit test for it.
llvm-svn: 287920
Summary:
This is a test-the-water change about possibilities of reducing duplication in
the register context definitions.
I've named the new class RegisterInfoPOSIX, as RegisterContextPOSIX was already
taken :(. The two files were identical except for a fix by Tamas in D12636,
which was applied to the Linux version only, which fixed a discrepancy between
the definitions of fpsr and fpcr on one hand, and all other floating point
register definitions on the other.
Linux test suite still passes after this change. For freebsd, make the floating
point register behavior consistent, but I don't know whether it will be
consistently fixed, or consistently broken. By eyeballing the code, I have a
feeling that a similar fix to D12636 will be required in
RegisterContextPOSIXProcessMonitor_arm64::ReadRegister, but I can't be sure as I
have no way to test it (the assert in that function should fire upon accessing
the registers if it is wrong though).
Reviewers: emaste, clayborg
Subscribers: aemerson, rengolin, beanz, mgorny, modocache, dmikulin, lldb-commits
Differential Revision: https://reviews.llvm.org/D25947
llvm-svn: 287916
the chrono library there uses long long as the underlying chrono type, but
defines int64_t as long (or the other way around, I am not sure). In any case,
this caused the implicit conversion to not trigger. This should address that.
Also fix up the relevant unit test.
llvm-svn: 287867
Summary:
This replaces the usage of raw integers with duration classes in the gdb-remote
packet management functions. The values are still converted back to integers once
they go into the generic Communication class -- that I am leaving to a separate
change.
The changes are mostly straight-forward (*), the only tricky part was
representation of infinite timeouts.
Currently, we use UINT32_MAX to denote infinite timeout. This is not well suited
for duration classes, as they tend to do arithmetic on the values, and the
identity of the MAX value can easily get lost (e.g.
microseconds(seconds(UINT32_MAX)).count() != UINT32_MAX). We cannot use zero to
represent infinity (as Listener classes do) because we already use it to do
non-blocking polling reads. For this reason, I chose to have an explicit value
for infinity.
The way I achieved that is via llvm::Optional, and I think it reads quite
natural. Passing llvm::None as "timeout" means "no timeout", while passing zero
means "poll". The only tricky part is this breaks implicit conversions (seconds
are implicitly convertible to microseconds, but Optional<seconds> cannot be
easily converted into Optional<microseconds>). For this reason I added a special
class Timeout, inheriting from Optional, and enabling the necessary conversions
one would normally expect.
(*) The other tricky part was GDBRemoteCommunication::PopPacketFromQueue, which
was needlessly complicated. I've simplified it, but that one is only used in
non-stop mode, and so is untested.
Reviewers: clayborg, zturner, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D26971
llvm-svn: 287864
Summary:
This patch changes the way ProcessElfCore.cpp handles signal information.
The patch changes ProcessElfCore.cpp to use the signal from si_signo in SIGINFO notes in preference to the value of cursig in PRSTATUS notes. The value from SIGINFO seems to be more thread specific. The value from PRSTATUS is usually the same for all threads even if only one thread received a signal.
If it cannot find any SIGINFO blocks it reverts to the old behaviour and uses the value from cursig in PRSTATUS. If after that no thread appears to have been stopped it forces the status of the first thread to be SIGSTOP to prevent lldb hanging waiting for any thread from the core file to change state.
The order is:
- If one or more threads have a non-zero si_signo in SIGINFO that will be used.
- If no threads had a SIGINFO block with a non-zero si_signo set all threads signals to the value in cursig in their PRSTATUS notes.
- If no thread has a signal set to a non-zero value set the signal for only the first thread to SIGSTOP.
This resolves two issues. The first was identified in bug 26322, the second became apparent while investigating this problem and looking at the signal values reported for each thread via “thread list”.
Firstly lldb is able to load core dumps generated by gcore where each thread has a SIGINFO note containing a signal number but cursig in the PRSTATUS block for each thread is 0.
Secondly if a SIGINFO note was found the “thread list” command will no longer show the same signal number for all threads. At the moment if a process crashes, for example with SIGILL, all threads will show “stop reason = signal SIGILL”. With this patch only the thread that executed the illegal instruction shows that stop reason. The other threads show “stop reason = signal 0”.
Reviewers: jingham, clayborg
Subscribers: sas, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D26676
llvm-svn: 287858
The Windows process plugin was broken up into multiple pieces a while back in
order to share code between debugging live processes and minidumps
(postmortem) debugging. The minidump portion was replaced by a cross-platform
solution. This left the plugin split into a formerly "common" base classes and
the derived classes for live debugging. This extra layer made the code harder
to understand and work with.
This patch simplifies these class hierarchies by rolling the live debugging
concrete classes up to the base classes. Last week I posted my intent to make
this change to lldb-dev, and I didn't hear any objections.
This involved moving code and changing references to classes like
ProcessWindowsLive to ProcessWindows. It still builds for both 32- and 64-bit,
and the tests still pass on 32-bit. (Tests on 64-bit weren't passing before
this refactor for unrelated reasons.)
llvm-svn: 287770
Summary:
The floating-point and SSE registers could be present in the elf-core
file in the note NT_FPREGSET for 64 bit ones, and in the note
NT_PRXFPREG for 32 bit ones.
The entire note is a binary blob matching the layout of the x87 save
area that gets generated by the FXSAVE instruction (see Intel developers
manual for more information).
This CL mainly modifies the RegisterRead function in
RegisterContextPOSIXCore_x86_64 for it to return the correct data both
for GPR and FPR/SSE registers, and return false (meaning "this register
is not available") for other registers.
I added a test to TestElfCore.py that tests reading FPR/SSE registers
both from a 32 and 64 bit elf-core file and I have inluded the source
which I used to generate the core files.
I tried to also add support for the AVX registers, because this info could
also be present in the elf-core file (note NT_X86_XSTATE - that is the result of
the newer XSAVE instruction). Parsing the contents from the file is
easy. The problem is that the ymm registers are split into two halves
and they are in different places in the note. For making this work one
would either make a "hacky" approach, because there won't be
any other way with the current state of the register contexts - they
assume that "this register is of size N and at offset M" and
don't have the notion of discontinuos registers.
Reviewers: labath
Subscribers: emaste, lldb-commits
Differential Revision: https://reviews.llvm.org/D26300
llvm-svn: 287506
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.
Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.
Differential Revision: https://reviews.llvm.org/D26698
llvm-svn: 287152
With the cross-platform minidump plugin working, the Windows-specific one is no longer needed. This eliminates the unnecessary code.
This does not eliminate the Windows-specific tests, as they hit a few cases the general tests don't. (The Windows-specific tests are currently passing.) I'll look into a separate patch to make sure we're not doing too much duplicate testing.
After that I might do a little re-org in the Windows plugin, as there was some factoring there (Common & Live) that probably isn't necessary anymore.
Differential Revision: https://reviews.llvm.org/D26697
llvm-svn: 287113
My script updated lldb::Errors, and I failed to fix it entirely
before pushing. This restore everything in lldb as it was before
r286561.
llvm-svn: 286565
This is forcing to use Error::success(), which is in a wide majority
of cases a lot more readable.
Differential Revision: https://reviews.llvm.org/D26481
llvm-svn: 286561
Summary:
This commit disables the windows-only minidump plugin and enables the new
cross-platform plugin for windows minidump files. Test decorators are adjusted to
reflect that: windows minidump tests can now run on all platforms. The exception
is the tests that create minidump files, as that functionality is not available
yet. I've checked that this works on windows and linux.
Reviewers: amccarth, zturner
Subscribers: dvlahovski, lldb-commits
Differential Revision: https://reviews.llvm.org/D26393
llvm-svn: 286352
The mock server was listening for only one packet (I forgot to put a loop around
it), which caused the client to stall in debug builds, as the timeout there is
1000 seconds. In case of a release builds the test would just silently succeed as
the tested function does not check or report errors (which should be fixed).
This fixes the test by adding the server loop. Since the test was taking quite a
long time now (8s), I have added a parameter to control the amount of data sent
(default 4MB), and call it with a smaller value in the test, to make the test run
faster.
llvm-svn: 285992
Summary:
One of the tests was flaky, because similarly to
https://reviews.llvm.org/D18697 (rL265391) - if there is a process running
which is with the same PID as in the core file, the minidump
core file debugging will fail, because we get some information from the
running process.
The fix is routing the ProcessInfo requests through the Process class
and overriding it in ProcessMinidump to return correct data.
Reviewers: labath
Subscribers: lldb-commits, beanz
Differential Revision: https://reviews.llvm.org/D26193
llvm-svn: 285698
Summary:
Most of the changes are very straight-forward, the only tricky part was the
"packet speed-test" function, which is very time-heavy. As the function was
completely untested, I added a quick unit smoke test for it.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D25391
llvm-svn: 285602
Summary:
This plugin resembles the already existing Windows-only Minidump plugin.
The WinMinidumpPlugin uses the Windows API for parsing Minidumps
while this plugin is cross-platform because it includes a Minidump
parser (which is already commited)
It is able to produce a backtrace, to read the general puprose regiters,
inspect local variables, show image list, do memory reads, etc.
For now the only arches that this supports are x86_32 and x86_64.
This is because I have only written register contexts for those.
Others will come in next CLs.
I copied the WinMinidump tests and adapted them a little bit for them to
work with the new plugin (and they pass)
I will add more tests, aiming for better code coverage.
There is still functionality to be added, see TODOs in code.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, modocache, lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D25905
llvm-svn: 285587
Summary:
This, like the x86_64 case, reads the register values from the minidump
file, and emits a binary buffer that is ordered using the offsets from
the RegisterInfoInterface argument. That way we can reuse an existing
register context.
Added unit tests.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, modocache, amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D25832
llvm-svn: 285584
Summary:
Check whether the setting the breakpoint failed during instruction emulation. If
it did, the next pc is likely in unmapped memory, and the inferior will crash
anyway after the next instruction. Do not return an error in this case, but just
continue stepping.
Reenabled the crash during step test for android/linux.
Reviewers: labath
Subscribers: aemerson, rengolin, tberghammer, danalbert, srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D25926
Author: Jason Majors <jmajors@google.com>
llvm-svn: 285187
The "value regs" field was filled incorrectly. It is supposed to list the
registers that *this* register is a sub-register of, not the other way around.
This manifested itself in "register read" showing only the smaller sub-registers
(and a bunch of tests not passing). I am not sure if the "invalidates" field is
correct either, but it's usage seems to be inconsistent, so I'll leave that as-is
for now.
llvm-svn: 284981
It's quite sad that we have to edit so many files just to add a register. I am
going to investigate how to merge these definitions somehow, but for now this
should at least get arm64 linux working again.
llvm-svn: 284970
Summary:
I misunderstood the format of the register context layout.
I thought it was a dynamically changing structure, and that it's size
depended on context_flags.
It turned out that it always has the same fixed layout and size,
and the context_flags says which fields of the
struct have valid values.
This required a minor redesign of the register context class.
The layout inconsistency, however, was not a "problem" before (e.g. the plugin was working)
because there also was a bug with checking context_flags - the code was
parsing the entire struct regardless of context_flags.
This bug is also fixed in this commit.
Reviewers: labath, zturner
Subscribers: lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D25677
llvm-svn: 284741
This patch fixes ARM/AArch64 watchpoint bug which was taking inferior out of control while stepping over watchpoints.
Also adds a test case that tests above problem.
Differential revision: https://reviews.llvm.org/D25057
llvm-svn: 284706
RegisterInfos_arm64.h. These register definitions include the
offset into the register context, which will vary depending on the
endianness of the arm64 target system (e.g. s8 is at offset 0 in
v8 on little-endian, it is at offset 12 on big-endian) and I've
only added the little-endian definitions to the table. If we want
to add a big-endian arm64 target, we'll need a separate table which
uses the big-endian offsets for these registers. I changed the
name of the register table from g_register_infos_arm64 to
g_register_infos_arm64_le to make it explicit that this is the
little-endian version of that table, and updated users of the table
to use the new name.
I added support for the "w", "s", and "d" registers to
RegisterContextDarwin_arm64 but it was more an example than anything
useful -- this plugin is only used when working with core files and
darwin core files do not (today) include the floating point register
context, so it only added the support for the "w" pseudo registers.
When we're connected to a real arm64 device, we use the ProcessGDBRemote
code.
llvm-svn: 284666
Summary:
Now the Minidump parser can parse the:
1) MemoryInfoList - containing region info about memory ranges (readable,
writable, executable)
2) Memory64List - this is the stuct used when the Minidump is a
full-memory one.
3) Adding filtering of the module list (shared libraries list) - there
can be mutliple records in the module list under the same name but with
different load address (e.g. when the binary has non contigious
sections). FilterModuleList eliminates the duplicated modules, leaving
the one with the lowest load addr.
Added unit tests for everything.
Reviewers: labath, zturner
Subscribers: beanz, mgorny, modocache, lldb-commits, amccarth
Differential Revision: https://reviews.llvm.org/D25569
llvm-svn: 284593
Summary:
This patch adds support for handling the SIGSEGV signal with 'si_code ==
SEGV_BNDERR', which is thrown when a bound violation is caught by the
Intel(R) MPX technology.
Differential Revision: https://reviews.llvm.org/D25329
llvm-svn: 283474
Pavel Labath