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:
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
It was returning const std::string& which was leading to
unnecessary copies all over the place, and preventing people
from doing things like Dict->GetValueForKeyAsString("foo", ref);
llvm-svn: 302875
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error". Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around. Hopefully nothing too
serious.
llvm-svn: 302872
This patch makes adjustments to header file includes in
lldbUtility based on recommendations by the iwyu tool
(include-what-you-use). The goal here is to make sure that
all files include the exact set of headers which are needed
for that file only, to eliminate cases of dead includes (e.g.
someone deleted some code but forgot to delete the header
includes that that code necessitated), and to eliminate the
case where header includes are picked up transitively.
llvm-svn: 299676
Summary:
Add basic OpenBSD support. This is enough to be able to analyze core dumps for OpenBSD/amd64, OpenBSD/arm, OpenBSD/arm64 and OpenBSD/i386.
Note that part of the changes to source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp fix a bug that probably affects other platforms as well. The GetProgramHeaderByIndex() interface use 1-based indices, but in some case when looping over the headers the, the loop starts at 0 and misses the last header. This caused problems on OpenBSD since OpenBSD core dumps have the PT_NOTE segment as the last program header.
Reviewers: joerg, labath, krytarowski
Reviewed By: krytarowski
Subscribers: aemerson, emaste, rengolin, srhines, krytarowski, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D31131
llvm-svn: 298810
There are only two users of NativeRegisterContextRegisterInfo,
and both are in process plugins. Moving this code from Host
to Plugins/Process/Utility thus makes sense, and as it is the
only dependency from Host -> PluginProcessUtility, it also
breaks this cycle, reducing LLDB's overall cycle count from
45 to 44.
llvm-svn: 298466
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
Summary:
These two register contexts were identical, so this shouldn't cause any
regressions, but I'd appreciate it if you can check that this at least compiles.
Reviewers: emaste, sas
Subscribers: aemerson, rengolin, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27126
llvm-svn: 296335
Summary:
NetBSD 7.99.62 introduced Debug Registers interface similar to the FreeBSD one.
This interface will land NetBSD-8.0.
Introduce support for this interface in Register Context NetBSD x86_64 unconditionally as older versions of NetBSD will not be supported.
This change allows to reduce diff with other ports and remove local copy of the RegisterInfos_x86_64.h content.
NetBSD Register Context for 32-bit x86 support will be added later.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30287
llvm-svn: 296071
With this patch, the only dependency left is from Utility
to Host. After this is broken, Utility will finally be
standalone.
Differential Revision: https://reviews.llvm.org/D29909
llvm-svn: 295088
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
Summary:
Real-Time Signals are available in NetBSD-current and will land NetBSD 8.0.
Older stable versions of NetBSD will not be supported.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, clayborg, emaste
Reviewed By: labath, clayborg, emaste
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29091
llvm-svn: 293391
Also found/fixed one bug identified by this warning in
RenderScriptx86ABIFixups.cpp where a string literal was being used in an
effort to provide a name for an instruction/register, but was instead
being passed as the bool 'isVolatile' parameter.
llvm-svn: 291198
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
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
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
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
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
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
This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
This patch also marks the const char* versions as =delete to prevent
their use. This has the potential to cause build breakages on some
platforms which I can't compile. I have tested on Windows, Linux,
and OSX. Best practices for fixing broken callsites are outlined in
Args.h in a comment above the deleted function declarations.
Eventually we can remove these =delete declarations, but for now they
are important to make sure that all implicit conversions from
const char * are manually audited to make sure that they do not invoke a
conversion from nullptr.
llvm-svn: 281919
Summary:
This patch uses the instruction CPUID to verify that FXSAVE, XSAVE, AVX
and MPX are supported by the target hardware. In case the HW supports XSAVE,
and at least one of the extended register sets, it further checks if the
target software has the kernel support for such features, by verifying that
their XSAVE part is correctly managed.
Differential Revision: https://reviews.llvm.org/D24559
llvm-svn: 281507
Most of these issues arose as a result of header re-ordering, but
it turned up a real bug, which is that MSVC doesn't support
__attribute__((packed)) or __attribute__((aligned)). This was
working before because there's a Windows header that #defines
__attribute__(x) to nothing. We should fix this by removing
that #define entirely, and dealing with the fallout separately
which may turn up even more bugs.
I fixed this by replacing them with the corresponding LLVM
macros which understand how to do these operations on all the
different compilers.
llvm-svn: 280757
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
This reverts commit rL280668 because the register tests fail on i386
Linux.
I investigated a little bit what causes the failure - there are missing
registers when running 'register read -a'.
This is the output I got at the bottom:
"""
...
Memory Protection Extensions:
bnd0 = {0x0000000000000000 0x0000000000000000}
bnd1 = {0x0000000000000000 0x0000000000000000}
bnd2 = {0x0000000000000000 0x0000000000000000}
bnd3 = {0x0000000000000000 0x0000000000000000}
unknown:
2 registers were unavailable.
"""
Also looking at the packets exchanged between the client and server:
"""
...
history[308] tid=0x7338 < 19> send packet: $qRegisterInfo4a#d7
history[309] tid=0x7338 < 130> read packet:
$name:bnd0;bitsize:128;offset:1032;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:101;dwarf:101;#48
history[310] tid=0x7338 < 19> send packet: $qRegisterInfo4b#d8
history[311] tid=0x7338 < 130> read packet:
$name:bnd1;bitsize:128;offset:1048;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:102;dwarf:102;#52
history[312] tid=0x7338 < 19> send packet: $qRegisterInfo4c#d9
history[313] tid=0x7338 < 130> read packet:
$name:bnd2;bitsize:128;offset:1064;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:103;dwarf:103;#53
history[314] tid=0x7338 < 19> send packet: $qRegisterInfo4d#da
history[315] tid=0x7338 < 130> read packet:
$name:bnd3;bitsize:128;offset:1080;encoding:vector;format:vector-uint64;set:Memory
Protection Extensions;ehframe:104;dwarf:104;#54
history[316] tid=0x7338 < 19> send packet: $qRegisterInfo4e#db
history[317] tid=0x7338 < 76> read packet:
$name:bndcfgu;bitsize:64;offset:1096;encoding:vector;format:vector-uint8;#99
history[318] tid=0x7338 < 19> send packet: $qRegisterInfo4f#dc
history[319] tid=0x7338 < 78> read packet:
$name:bndstatus;bitsize:64;offset:1104;encoding:vector;format:vector-uint8;#8e
...
"""
The bndcfgu and bndstatus registers don't have the 'Memory Protections
Extension' set. I looked at the code and it seems that that is set
correctly.
So I'm not sure what's the problem or where does it come from.
Also there is a second failure related to something like this in the
tests:
"""
registerSet.GetName().lower()
"""
For some reason the registerSet.GetName() returns None.
llvm-svn: 280703
Summary:
The Intel(R) Memory Protection Extensions (Intel(R) MPX) associates pointers
to bounds, against which the software can check memory references to
prevent out of bound memory access.
This patch allows accessing the MPX registers:
* bnd0-3: 128-bit registers to hold the bound values,
* bndcfgu, bndstatus: 64-bit configuration registers,
This patch also adds read/write tests for the MPX registers in the register
command tests and adds a new subdirectory for MPX specific tests.
Signed-off-by: Valentina Giusti <valentina.giusti@intel.com>
Reviewers: labath, granata.enrico, lldb-commits, clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24187
llvm-svn: 280668
Jason Molenda