| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 280755
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
*** 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
|
|
|
|
| |
llvm-svn: 280721
|
|
|
|
|
|
|
|
|
| |
MSVC emits an error when one uses a const variable in a lambda without
capturing it.
gcc and clang don't emit an error in this scenario.
llvm-svn: 280707
|
|
|
|
|
|
|
| |
Android targets don't have std::to_string and std::stoul. Use llvm::to_string and strtoul
instead.
llvm-svn: 280704
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
The commit introduced an array of const objects, which libstdc++ does not like. Make the object
non-const.
Also fix a compiler warning while I'm in there.
llvm-svn: 280697
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is one). From the user's perspective it is
often unclear what the reason for the crash is in a symbolic sense.
To address this, I have added new fuctionality to StackFrame to parse the
disassembly and reconstruct the sequence of dereferneces and offsets that were
applied to a known variable (or fuction retrn value) to obtain the invalid
pointer.
This makes use of enhancements in the disassembler, as well as new information
provided by the DWARF expression infrastructure, and is exposed through a
"frame diagnose" command. It is also used to provide symbolic information, when
available, in the event of a crash.
The algorithm is very rudimentary, and it needs a bunch of work, including
- better parsing for assembly, preferably with help from LLVM
- support for non-Apple platforms
- cleanup of the algorithm core, preferably to make it all work in terms of
Operands instead of register/offset pairs
- improvement of the GetExpressioPath() logic to make prettier expression
paths, and
- better handling of vtables.
I welcome all suggestios, improvements, and testcases.
llvm-svn: 280692
|
|
|
|
|
|
|
|
|
|
|
|
| |
As Pavel pointed out in a comment on llvm.org/pr30271, the VPATH I was
using here to eliminate duplication of a .cpp file had a side effect of
attempting to pull in a .o/.obj file from that same parent dir, where
other tests can be running in parallel. This is no good.
For now, I have removed the VPATH, which should address
llvm.org/pr30271. I have also removed the XFAIL.
llvm-svn: 280675
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Replace uses of the local MIUtilParse::CRegexParser class with the LLVM support class llvm::Regex. This reduces duplication of code, and makes it possible to remove the MIUtilParse::CRegexParser class that requires LLVM internal implementation headers.
Bug: https://llvm.org/bugs/show_bug.cgi?id=29138
Reviewers: dawn, abidh, ki.stfu
Subscribers: labath, ki.stfu, lldb-commits
Differential Revision: https://reviews.llvm.org/D23882
Author: Michał Górny <mgorny@gentoo.org>
llvm-svn: 280662
|
|
|
|
|
|
| |
android targets use this key, so the test should recognize it.
llvm-svn: 280652
|
|
|
|
|
|
|
| |
Tracked by:
llvm.org/pr30271
llvm-svn: 280606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code represents the Week of Code work I did on bringing up
lldb-server LLGS support for Darwin. It does not include the
Xcode project changes needed, as we don't want to throw that switch
until more support is implemented (i.e. this change is inert, no
build systems use it yet. I've verified on Ubuntu 16.04, macOS
Xcode and macOS cmake builds).
This change does some minimal refactoring of code that is shared
with the Linux LLGS portion, moving it from NativeProcessLinux into
NativeProcessProtocol. That code is also used by NativeProcessDarwin.
Current state on Darwin:
* Process launching is implemented. (Attach is not).
Launching on devices has not yet been tested (FBS/BKS might
need a bit of work).
* Inferior waitpid monitoring and communication of exit status
via MainLoop callback is implemented.
* Memory read/write, breakpoints, thread register context, etc.
are not yet implemented. This impacts process stop/resume, as
the initial launch suspended immediately starts the process
up and running because it doesn't know it is supposed to remain
stopped.
* I implemented the equivalent of MachThreadList as
NativeThreadListDarwin, in anticipation that we might want to
factor out common parts into NativeThreadList{Protocol} and share
some code here. After writing it, though, the fallout from merging
Mach Task/Process into a single concept plus some other minor
changes makes the whole NativeThreadListDarwin concept nothing more
than dead weight. I am likely going to get rid of this class and
just manage it directly in NativeProcessDarwin, much like I did
for NativeProcessLinux.
* There is a stub-out call for starting a STDIO thread. That will
go away and adopt the MainLoop pselect-based IOObject reading.
I am developing the fully-integrated changes in the following repo,
which contains the necessary Xcode bits and the glue that enables
lldb-debugserver on a macOS system:
https://github.com/tfiala/lldb/tree/llgs-darwin
This change also breaks out a few of the lldb-server tests into
their own directory, and adds some $qHostInfo tests (not sure why
I didn't write those tests back when I initially implemented that
on the Linux side).
llvm-svn: 280604
|
|
|
|
| |
llvm-svn: 280513
|
|
|
|
| |
llvm-svn: 280492
|
|
|
|
| |
llvm-svn: 280490
|
|
|
|
|
|
|
|
| |
this is a resubmission of r280476. The problem with the original commit was that it was printing
out all numbers as signed, which was wrong for unsigned numbers with the MSB set. Fix that and
add a unit test covering that case.
llvm-svn: 280480
|
|
|
|
|
|
|
| |
This reverts commit r280476 as it breaks several tests on i386. I was fixing an 32-bit
breakage, and I did not run the 32-bit test suite before submitting, oops.
llvm-svn: 280478
|
|
|
|
|
|
| |
Still a bit flaky on remote targets. Trying a larger bump this time. :/
llvm-svn: 280477
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
It seems the original intention of the function was printing signed values in decimal format, and
unsigned values in hex (without the leading "0x"). However, signed and unsigned long were
exchanged, which lead to amusing test failures in TestMemoryFind.py.
Instead of just switching the two, I think we should just print everything in decimal here, as
the current behaviour is very confusing (especially when one does not request printing of types).
Nothing seems to depend on this behaviour except and we already have a way for the user to
request the format he wants when printing values for most commands (which presumably does not go
through this function).
I also add a unit tests for the function in question.
Reviewers: clayborg, granata.enrico
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24126
llvm-svn: 280476
|
|
|
|
|
|
| |
whether it changed
llvm-svn: 280395
|
|
|
|
|
|
| |
Fixes rdar://25192935
llvm-svn: 280389
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This is a Minidump parsing code.
There are still some more structures/data streams that need to be added.
The aim ot this is to be used in the implementation of
a minidump debugging plugin that works on all platforms/architectures.
Currently we have a windows-only plugin that uses the WinAPI to parse
the dump files.
Also added unittests for the current functionality.
Reviewers: labath, amccarth
Subscribers: tberghammer, danalbert, srhines, lldb-commits, dschuff
Differential Revision: https://reviews.llvm.org/D23545
llvm-svn: 280356
|
|
|
|
|
|
|
|
| |
the test fails for a very prosaic reason: `(const char *)0x1000` returns "4096" on x86_64 and
"1000" (without the "0x") on i386. I haven't tried other 32-bit arches, but I am guessing the
behaviour is the same. XFAIL until someone can get a chance to look at this.
llvm-svn: 280344
|
|
|
|
|
|
|
|
| |
assert on a std::shared_ptr<>
Appease it by being very very very explicit about what I mean
llvm-svn: 280328
|
|
|
|
|
|
|
|
| |
algorithm
Fixes rdar://15455621 (and adds a test case for this command which - surprisingly and sadly - was not there originally)
llvm-svn: 280327
|
|
|
|
| |
llvm-svn: 280295
|
|
|
|
|
|
| |
the same size as the containing type
llvm-svn: 280294
|
|
|
|
|
|
| |
Patch by Taras Tsugrii
llvm-svn: 280283
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The vdso is full of hand-written assembly which the instruction emulator has a hard time
understanding. Luckily, the kernel already provides us with correct unwind info for them. So
let's use it.
This fixes (at least) the AssertingInferiorTestCase.test_inferior_asserting_disassemble test on
android N i386.
Reviewers: tberghammer
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: https://reviews.llvm.org/D24079
llvm-svn: 280264
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- copies the new file in the cmake build
- adds an additional import statement
- marks the test as no-debug-info specific, as it seems to be testing a python feature
Reviewers: granata.enrico
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24074
llvm-svn: 280261
|
|
|
|
|
|
|
| |
There were a few corner cases that weren't tested for dealing with
extraction of an odd number of nibbles. Add tests for those here.
llvm-svn: 280253
|
|
|
|
|
|
| |
cause of the problem
llvm-svn: 280208
|
|
|
|
|
|
|
|
|
|
| |
The rewrite of StringExtractor::GetHexMaxU32 changes functionality in a way which makes
lldb-server crash. The crash (assert) happens when parsing the "qRegisterInfo0" packet, because
the function tries to drop_front more bytes than the packet contains. It's not clear to me
whether we should consider this a bug in the caller or the callee, but it any case, it worked
before, so I am reverting this until we can figure out what the proper interface should be.
llvm-svn: 280207
|
|
|
|
|
|
| |
PeekChar returns a character, we want the whole string there.
llvm-svn: 280204
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
https://github.com/llvm-mirror/lldb/commit/e80f43fd78fa0fbc04d2d59b5713acb5d06c8308
greatly improved an API, but missed one more occurence of legacy usage.
This leads to:
if (extractor.GetHexBytes(&payload_bytes[0], payload_bytes.size(), '\xdd') != payload_bytes.size())
~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
/lldb/include/lldb/Utility/StringExtractor.h:151:5: note: 'GetHexBytes' declared here
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24064
Author: Taras Tsugrii <ttsugrii@fb.com>
llvm-svn: 280202
|
|
|
|
| |
llvm-svn: 280200
|
|
|
|
| |
llvm-svn: 280173
|
|
|
|
|
|
|
|
| |
This class enables one to easily write a synthetic child provider by writing a class that returns pairs of names and primitive Python values - the base class then converts those into LLDB SBValues
Comes with a test case
llvm-svn: 280172
|
|
|
|
| |
llvm-svn: 280166
|
|
|
|
| |
llvm-svn: 280164
|
|
|
|
|
|
|
|
| |
(of a given size) of that type
This is currently only implemented for the clang-based TypeSystem, but other languages are welcome to jump in!
llvm-svn: 280151
|
|
|
|
|
|
|
|
|
|
|
| |
Makes Peek() return a StringRef instead of a const char*.
This leads to a few callers of Peek() being able to be made a
little nicer (for example using StringRef member functions instead
of c-style strncmp and related functions) and generally safer
usage.
llvm-svn: 280139
|
|
|
|
|
|
|
|
|
| |
LLDB was rolling its own endian conversion code, but functions to
do this already exist in LLVM. While the code was probably
correct, no point reinventing the wheel when we have well tested
equivalents in LLVM that are one-liners.
llvm-svn: 280137
|
|
|
|
|
|
|
|
| |
This is a NFC that adds more unit test coverage of the GetHex***
functions as well as the functions to extract numbers with a
specific endianness.
llvm-svn: 280124
|
|
|
|
|
|
|
|
|
|
| |
MutableArrayRef<T> is essentially a safer version of passing around
(T*, length) pairs and provides some convenient functions for working
with the data without having to manually manipulate indices.
This is a minor NFC.
llvm-svn: 280123
|
|
|
|
|
|
|
|
|
| |
autoconf+make have been removed from LLVM and LLDB ~6month ago. We
shouldn't advertise it on the website as a valid way to build LLDB.
Differential revision: https://reviews.llvm.org/D24025
llvm-svn: 280102
|
|
|
|
|
|
| |
This reverts commit r279725 as it breaks "dynamic register size" feature of mips.
llvm-svn: 280088
|