[LLDB][ThreadELFCore] Set all the properties of ELFLinuxSigInfo to a non build dependent size (#117604)

On #110065 the changes to LinuxSigInfo Struct introduced some variables
that will differ in s

[LLDB][ThreadELFCore] Set all the properties of ELFLinuxSigInfo to a non build dependent size (#117604)

On #110065 the changes to LinuxSigInfo Struct introduced some variables
that will differ in size on 32b or 64b. I've rectified this by setting
them all to build independent types.

show more ...

[LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (#110065)

This fixes a functionality gap with GDB, where GDB will properly decode
the stop reason and give the addres

[LLDB][ProcessELFCore] Add Description to ProcessELFCore/ELFThread stop reasons (#110065)

This fixes a functionality gap with GDB, where GDB will properly decode
the stop reason and give the address for SIGSEGV. I also added
descriptions to all stop reasons, following the same code path that the
Native Linux Thread uses.

show more ...

[lldb] Add Populate Methods for ELFLinuxPrPsInfo and ELFLinuxPrStatus (#104109)

To create elf core files there are multiple notes in the core file that
contain these structs as the note. These popu

[lldb] Add Populate Methods for ELFLinuxPrPsInfo and ELFLinuxPrStatus (#104109)

To create elf core files there are multiple notes in the core file that
contain these structs as the note. These populate methods take a Process
and produce fully specified structures that can be used to fill these
note sections. The pr also adds tests to ensure these structs are
correctly populated.

show more ...

[LLDB] Show sub type of signals when debugging a core file

Previously we only looked at the si_signo field, so you got:
```
(lldb) bt
* thread #1, name = 'a.out.mte', stop reason = signal SIGSEGV

[LLDB] Show sub type of signals when debugging a core file

Previously we only looked at the si_signo field, so you got:
```
(lldb) bt
* thread #1, name = 'a.out.mte', stop reason = signal SIGSEGV
* frame #0: 0x00000000004007f4
```
This patch adds si_code so we can show:
```
(lldb) bt
* thread #1, name = 'a.out.mte', stop reason = signal SIGSEGV: sync tag check fault
* frame #0: 0x00000000004007f4
```

The order of errno and code was incorrect in ElfLinuxSigInfo::Parse.
It was the order that a "swapped" siginfo arch would use, which for Linux,
is only MIPS. We removed MIPS Linux support some time ago.

See:
https://github.com/torvalds/linux/blob/fe15c26ee26efa11741a7b632e9f23b01aca4cc6/include/uapi/asm-generic/siginfo.h#L121

A test is added using memory tagging faults. Which were the original
motivation for the changes.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D146045

show more ...

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pa

[lldb] Update header guards to be consistent and compliant with LLVM (NFC)

LLDB has a few different styles of header guards and they're not very
consistent because things get moved around or copy/pasted. This patch
unifies the header guards across LLDB and converts everything to match
LLVM's style.

Differential revision: https://reviews.llvm.org/D74743

show more ...

[lldb] NFC modernize codebase with modernize-use-nullptr

Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]

This commit is the result of modernizing the LLDB codeba

[lldb] NFC modernize codebase with modernize-use-nullptr

Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]

This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.

This is the command I ran and I to fix and format the code base:

```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```

NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.

NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.

Reviewers: martong, espindola, shafik, #lldb, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits

Tags: #lldb, #llvm

Differential Revision: https://reviews.llvm.org/D61847

llvm-svn: 361484

show more ...

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

[windows] LLDB shows the wrong values when register read is executed at a frame other than zero

Summary:
This is a clean version of the change suggested here: https://bugs.llvm.org/show_bug.cgi?id=3

[windows] LLDB shows the wrong values when register read is executed at a frame other than zero

Summary:
This is a clean version of the change suggested here: https://bugs.llvm.org/show_bug.cgi?id=37495

The main change is to follow the same pattern as non-windows targets and use an unwinder object to retrieve the register context. I also changed a couple of the comments to actually log, so that issues with unsupported scenarios can be tracked down more easily. Lastly, ClearStackFrames is implemented in the base class, so individual thread implementations don't have to override it.

Reviewers: asmith, zturner, aleksandr.urakov

Reviewed By: aleksandr.urakov

Subscribers: emaste, stella.stamenova, tatyana-krasnukha, llvm-commits

Differential Revision: https://reviews.llvm.org/D49111

llvm-svn: 336732

show more ...

elf-core: Convert remaining register context to use register set maps

In https://reviews.llvm.org/D39681, we started using a map instead
passing a long list of register sets to the ppc64le register

elf-core: Convert remaining register context to use register set maps

In https://reviews.llvm.org/D39681, we started using a map instead
passing a long list of register sets to the ppc64le register context.
However, existing register contexts were still using the old method.

This converts the remaining register contexts to use this approach.
While doing that, I've had to modify the approach a bit:
- the general purpose register set is still kept as a separate field,
because this one is always present, and it's parsing is somewhat
different than that of other register sets.
- since the same register sets have different IDs on different operating
systems, but we use the same register context class to represent
different register sets, I've needed to add a layer of indirection to
translate os-specific constants (e.g. NETBSD::NT_AMD64_FPREGS) into more
generic terms (e.g. floating point register set).

While slightly more complicated, this setup allows for better separation
of concerns. The parsing code in ProcessElfCore can focus on parsing
OS-specific core file notes, and can completely ignore
architecture-specific register sets (by just storing any unrecognised
notes in a map). These notes will then be passed on to the
architecture-specific register context, which can just deal with
architecture specifics, because the OS-specific note types are hidden in
a register set description map.

This way, adding an register set, which is already supported on other
OSes, to a new OS, should in most cases be as simple as adding a new
entry into the register set description map.

Differential Revision: https://reviews.llvm.org/D40133

llvm-svn: 319162

show more ...

elf-core: Split up parsing code into os-specific functions

Summary:
We've had a single function responsible for splitting a core segment
into notes, and parsing the notes themselves, bearing in mind

elf-core: Split up parsing code into os-specific functions

Summary:
We've had a single function responsible for splitting a core segment
into notes, and parsing the notes themselves, bearing in mind variations
between 4 supported OS types. This commit splits that code into 5
pieces:
- (os-independent) code for splitting a segment into individual notes
- per-os function for parsing the notes into thread information

Reviewers: clayborg, krytarowski, emaste, alexandreyy, kettenis

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D40311

llvm-svn: 318903

show more ...

Implement core dump debugging for PPC64le

Summary: Implement core dump debugging for PPC64le.

Reviewers: labath

Reviewed By: labath

Subscribers: JDevlieghere, krytarowski, clayborg, labath, lbian

Implement core dump debugging for PPC64le

Summary: Implement core dump debugging for PPC64le.

Reviewers: labath

Reviewed By: labath

Subscribers: JDevlieghere, krytarowski, clayborg, labath, lbianc, nemanjai, gut, anajuliapc, mgorny, kbarton, lldb-commits

Differential Revision: https://reviews.llvm.org/D39681
Patch by Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br>

llvm-svn: 318399

show more ...

Rename Error -> Status.

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 h

Rename Error -> Status.

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

show more ...

[LLDB][MIPS] Core Dump Support.

Reviewers: labath, emaste

Subscribers: jaydeep, bhushan, lldb-commits, slthakur

Differential Revision: https://reviews.llvm.org/D30457

llvm-svn: 299200

Move DataBuffer / DataExtractor and friends from Core -> Utility.

llvm-svn: 296943

Patch for lldb bug 26322 “core load hangs”

Summary:
This patch changes the way ProcessElfCore.cpp handles signal information.
The patch changes ProcessElfCore.cpp to use the signal from si_signo in

Patch for lldb bug 26322 “core load hangs”

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

show more ...

*** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:

Firstly, merging t

*** This commit represents a complete reformatting of the LLDB source code
*** 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

show more ...

Add/fix support for i386 elf core files

Summary:
There were places in the code, assuming(hardcoding) offsets
and types that were only valid for the x86_64 elf core file format.

The NT_PRSTATUS and

Add/fix support for i386 elf core files

Summary:
There were places in the code, assuming(hardcoding) offsets
and types that were only valid for the x86_64 elf core file format.

The NT_PRSTATUS and NT_PRPSINFO structures are with the 64 bit layout.
I have reused them and parse i386 files manually, and fill them in the
same struct.

Also added some error handling during parsing that checks if the
available bytes in the buffer are enough to fill the structures.

The i386 core file test case now passes.

For reference on the structures layout, I generally used the
source of binutils (bfd, readelf)

Bug: https://llvm.org/bugs/show_bug.cgi?id=26947

Reviewers: labath

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D22917

llvm-svn: 277140

show more ...

Fixing layout of elf-core file related structures

Summary:
The binary layout of prstatus and prpsinfo was wrong.
Some of the member variables where not aligned properly
and others where with a wrong

Fixing layout of elf-core file related structures

Summary:
The binary layout of prstatus and prpsinfo was wrong.
Some of the member variables where not aligned properly
and others where with a wrong type (e.g. the time related
stuff in prstatus).

I used the structs defined in bfd in binutils to see what the layout
of the elf-core format in these section is.
(https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/hosts/x86-64linux.h;h=4e420a1f2081dd3b51f5d6b7a8e4093580f5cdb5;hb=master)
Note: those structures are only for x86 64 bit elf-core files

This shouldn't have any impact on the functionality, because
lldb actually uses only a few of the member variables of those structs
and they are with a correct type and alignment.

I found this while trying to add/fix the support for
i386 core files (https://llvm.org/bugs/show_bug.cgi?id=26947)

Reviewers: labath

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D22628
Author: Dimitar Vlahovski <dvlahovski@google.com>

llvm-svn: 276406

show more ...

Support Linux on SystemZ as platform

This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementat

Support Linux on SystemZ as platform

This patch adds support for Linux on SystemZ:
- A new ArchSpec value of eCore_s390x_generic
- A new directory Plugins/ABI/SysV-s390x providing an ABI implementation
- Register context support
- Native Linux support including watchpoint support
- ELF core file support
- Misc. support throughout the code base (e.g. breakpoint opcodes)
- Test case updates to support the platform

This should provide complete support for debugging the SystemZ platform.
Not yet supported are optional features like transaction support (zEC12)
or SIMD vector support (z13).

There is no instruction emulation, since our ABI requires that all code
provide correct DWARF CFI at all PC locations in .eh_frame to support
unwinding (i.e. -fasynchronous-unwind-tables is on by default).

The implementation follows existing platforms in a mostly straightforward
manner. A couple of things that are different:

- We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers,
since some registers (access register) reside at offsets in the user area
that are multiples of 4, but the PTRACE_PEEKUSER interface only allows
accessing aligned 8-byte blocks in the user area. Instead, we use a s390
specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that
allows accessing a whole block of the user area in one go, so in effect
allowing to treat parts of the user area as register sets.

- SystemZ hardware does not provide any means to implement read watchpoints,
only write watchpoints. In fact, we can only support a *single* write
watchpoint (but this can span a range of arbitrary size). In LLDB this
means we support only a single watchpoint. I've set all test cases that
require read watchpoints (or multiple watchpoints) to expected failure
on the platform. [ Note that there were two test cases that install
a read/write watchpoint even though they nowhere rely on the "read"
property. I've changed those to simply use plain write watchpoints. ]

Differential Revision: http://reviews.llvm.org/D18978

llvm-svn: 266308

show more ...

Fix Clang-tidy modernize-use-override warnings in some files in source/Plugins; other minor fixes.

Differential Revision: http://reviews.llvm.org/D13840

llvm-svn: 250721

Report original thread ID for FreeBSD core files

On FreeBSD the tid is (somewhat unintuitively) found in the pr_pid
field of the NT_PRSTATUS note. Collect it when parsing the note and
store it in th

Report original thread ID for FreeBSD core files

On FreeBSD the tid is (somewhat unintuitively) found in the pr_pid
field of the NT_PRSTATUS note. Collect it when parsing the note and
store it in the thread data.

For Linux I've left the original behaviour of using sequential TIDs
(0, 1, 2...) as I don't yet have code to obtain it.

Differential Revision: http://reviews.llvm.org/D11652

llvm-svn: 243748

show more ...

Implement initial Altivec support

Summary:
This adds the register plumbing, as well as register reading in FreeBSD core
dumps. Further work on the POSIX/FreeBSD ProcessMonitor is required in order

Implement initial Altivec support

Summary:
This adds the register plumbing, as well as register reading in FreeBSD core
dumps. Further work on the POSIX/FreeBSD ProcessMonitor is required in order to
support ptrace access to these registers.

Reviewers: tfiala, emaste

Reviewed By: emaste

Subscribers: emaste, lldb-commits

Differential Revision: http://reviews.llvm.org/D7039

llvm-svn: 228278

show more ...

elf-core: Strip trailing whitespace

llvm-svn: 206468

si_errno and friends are macros on NetBSD, so #undef them first.

llvm-svn: 191388