[lldb] Correct address calculation for reading segment data (#120655)

This commit addresses a bug introduced in commit bcf654c, which
prevented LLDB from parsing the GNU build ID for the main execu

[lldb] Correct address calculation for reading segment data (#120655)

This commit addresses a bug introduced in commit bcf654c, which
prevented LLDB from parsing the GNU build ID for the main executable
from a core file. The fix finds the `p_vaddr` of the first `PT_LOAD`
segment as the `base_addr` and subtract this `base_addr` from the
virtual address being read.

Co-authored-by: George Hu <hyubo@meta.com>

show more ...

[lldb] Fix TestLoadUnload.py (#117416)

ELF core debugging fix #117070 broke TestLoadUnload.py tests due to
GetModuleSpec call, ProcessGDBRemote fetches modules from remote. Revise
the original PR,

[lldb] Fix TestLoadUnload.py (#117416)

ELF core debugging fix #117070 broke TestLoadUnload.py tests due to
GetModuleSpec call, ProcessGDBRemote fetches modules from remote. Revise
the original PR, renamed FindBuildId to FindModuleUUID.

show more ...

[lldb] Fix ELF core debugging (#117070)

DynamicLoader does not use ProcessElfCore NT_FILE entries to get
UUID. Use GetModuleSpec to get UUID from Process.

[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] Fix loading UUIDs from ELF headers. (#117028)

A previous patch added the ability to load UUID from ELF headers using
the program header and finding PT_NOTE entries. The fix would attempt to

[lldb] Fix loading UUIDs from ELF headers. (#117028)

A previous patch added the ability to load UUID from ELF headers using
the program header and finding PT_NOTE entries. The fix would attempt to
read the data for the PT_NOTE from memory, but it didn't slide the
address so it ended up only working for the main executable if it wasn't
moved in memory. This patch slides the address and adds logging.

All processes map the ELF header + program headers + some program header
contents into memory. The program header for the `PT_NOTE` entries are
mapped, but the p_vaddr doesn't get relocated and is relative to the
load address of the ELF header. So we take a "p_vaddr" (file address)
and convert it into a load address in the process so we can load the
correct bytes that contain the `PT_NOTE` contents.

show more ...

[lldb] Make conversions from llvm::Error explicit with Status::FromEr… (#107163)

…ror() [NFC]

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
ant

[lldb] Turn lldb_private::Status into a value type. (#106163)

This patch removes all of the Set.* methods from Status.

This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.

This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()

Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form

` ResultTy DoFoo(Status& error)
`
to

` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?

The interesting changes are in Status.h and Status.cpp, all other
changes are mostly

` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.

show more ...

[lldb][NFCI] Simplify ProcessElfCore::GetAuxvData() (#102263)

There is no need to clone the content and set extraction properties
because `m_auxv` is already in the required form.

Read and store gnu build id from loaded core file (#92492)

As we have debuginfod as symbol locator available in lldb now, we want
to make full use of it.
In case of post mortem debugging, we don't

Read and store gnu build id from loaded core file (#92492)

As we have debuginfod as symbol locator available in lldb now, we want
to make full use of it.
In case of post mortem debugging, we don't always have the main
executable available.
However, the .note.gnu.build-id of the main executable(some other
modules too), should be available in the core file, as those binaries
are loaded in memory and dumped in the core file.

We try to iterate through the NT_FILE entries, read and store the gnu
build id if possible. This will be very useful as this id is the unique
key which is needed for querying the debuginfod server.

Test:
Build and run lldb. Breakpoint set to
https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolLocator/Debuginfod/SymbolLocatorDebuginfod.cpp#L147
Verified after this commit, module_uuid is the correct gnu build id of
the main executable which caused the crash(first in the NT_FILE entry)

Previous PR: https://github.com/llvm/llvm-project/pull/92078 was
mistakenly merged. This PR is re-opening the commit.

show more ...

Revert "Read and store gnu build id from loaded core file" (#92181)

Reverts llvm/llvm-project#92078

Read and store gnu build id from loaded core file (#92078)

As we have debuginfod as symbol locator available in lldb now, we want
to make full use of it.
In case of post mortem debugging, we don't

Read and store gnu build id from loaded core file (#92078)

As we have debuginfod as symbol locator available in lldb now, we want
to make full use of it.
In case of post mortem debugging, we don't always have the main
executable available.
However, the .note.gnu.build-id of the main executable(some other
modules too), should be available in the core file, as those binaries
are loaded in memory and dumped in the core file.

We try to iterate through the NT_FILE entries, read and store the gnu
build id if possible. This will be very useful as this id is the unique
key which is needed for querying the debuginfod server.

Test:
Build and run lldb. Breakpoint set to
https://github.com/llvm/llvm-project/blob/main/lldb/source/Plugins/SymbolLocator/Debuginfod/SymbolLocatorDebuginfod.cpp#L147
Verified after this commit, module_uuid is the correct gnu build id of
the main executable which caused the crash(first in the NT_FILE entry)

show more ...

Add a new SBProcess:: GetCoreFile() API (#80767)

We have a Python script that needs to locate coredump path during
debugging so that we can retrieve certain metadata files associated with
it. Curr

Add a new SBProcess:: GetCoreFile() API (#80767)

We have a Python script that needs to locate coredump path during
debugging so that we can retrieve certain metadata files associated with
it. Currently, there is no API for this.

This patch adds a new `SBProcess::GetCoreFile()` to retrieve target dump
file spec used for dump debugging. Note: this is different from the main
executable module spec. To achieve this, the patch hoists m_core_file
into PostMortemProcess for sharing.

---------

Co-authored-by: jeffreytan81 <jeffreytan@fb.com>

show more ...

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,end

[lldb] Use StringRef::{starts,ends}_with (NFC)

This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.

I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.

show more ...

Fix a stall in running `quit` while a live process is running (#74687)

We need to generate events when finalizing, or we won't know that we
succeeded in stopping the process to detach/kill. Instea

Fix a stall in running `quit` while a live process is running (#74687)

We need to generate events when finalizing, or we won't know that we
succeeded in stopping the process to detach/kill. Instead, we stall and
then after our 20 interrupt timeout, we kill the process (even if we
were supposed to detach) and exit.

OTOH, we have to not generate events when the Process is being
destructed because shared_from_this has already been torn down, and
using it will cause crashes.

show more ...

[lldb] Fix duplicate word typos; NFC

Those fixes were taken from https://reviews.llvm.org/D137338

[lldb] Fix typo in comments and in test

Reviewed By: DavidSpickett

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

[lldb][NFCI] Remove use of ConstString from ProcessElfCore

I'm not convinced that it makes sense for the paths to be ConstStrings. We're
going to be putting them into FileSpecs (which are backed by

[lldb][NFCI] Remove use of ConstString from ProcessElfCore

I'm not convinced that it makes sense for the paths to be ConstStrings. We're
going to be putting them into FileSpecs (which are backed by
ConstStrings, for now) but otherwise there's no need to store them as
ConstStrings upfront.

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

show more ...

Revert "[lldb] Move UnixSignals creation into Platform plugins"

This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3.
As discussed in https://reviews.llvm.org/D146668 we'll find another way

Revert "[lldb] Move UnixSignals creation into Platform plugins"

This reverts commit ee232506b870ce5282cc4da5ca493d41d361feb3.
As discussed in https://reviews.llvm.org/D146668 we'll find another way
forward.

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] Move UnixSignals creation into Platform plugins

The high level goal of this change is to remove lldbTarget's dependency
on lldbPluginProcessUtility. The reason for this existing dependency is

[lldb] Move UnixSignals creation into Platform plugins

The high level goal of this change is to remove lldbTarget's dependency
on lldbPluginProcessUtility. The reason for this existing dependency is
so that we can create the appropriate UnixSignals object based on an
ArchSpec. Instead of using the ArchSpec, we can instead take advantage
of the Platform associated with the current Target.

This is accomplished by adding a new method to Platform,
CreateUnixSignals, which will create the correct UnixSignals object for
us. We then can use `Platform::GetUnixSignals` and rely on that to give
us the correct signals as needed.

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

show more ...

[lldb][AArch64] Add support for memory tags in core files

This teaches ProcessElfCore to recognise the MTE tag segments.

https://www.kernel.org/doc/html/latest/arm64/memory-tagging-extension.html#c

[lldb][AArch64] Add support for memory tags in core files

This teaches ProcessElfCore to recognise the MTE tag segments.

https://www.kernel.org/doc/html/latest/arm64/memory-tagging-extension.html#core-dump-support

These segments contain all the tags for a matching memory segment
which will have the same size in virtual address terms. In real terms
it's 2 tags per byte so the data in the segment is much smaller.

Since MTE is the only tag type supported I have hardcoded some
things to those values. We could and should support more formats
as they appear but doing so now would leave code untested until that
happens.

A few things to note:
* /proc/pid/smaps is not in the core file, only the details you have
in "maps". Meaning we mark a region tagged only if it has a tag segment.
* A core file supports memory tagging if it has at least 1 memory
tag segment, there is no other flag we can check to tell if memory
tagging was enabled. (unlike a live process that can support memory
tagging even if there are currently no tagged memory regions)

Tests have been added at the commands level for a core file with
mte and without.

There is a lot of overlap between the "memory tag read" tests here and the unit tests for
MemoryTagManagerAArch64MTE::UnpackTagsFromCoreFileSegment, but I think it's
worth keeping to check ProcessElfCore doesn't cause an assert.

Depends on D129487

Reviewed By: omjavaid

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

show more ...

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.c

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:

1476275, 1274012, 1455035, 1364789, 1454282
1467483, 1406152, 1406255, 1454837, 1454416
1467446, 1462022, 1461909, 1420566, 1327228
1367767, 1431254, 1467299, 1312678, 1431780
1454731, 1490403

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

show more ...

Revert "[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2"

This reverts commit b9aedd94e6796e4b4866ab4c091b736b3db58cb7.

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.c

[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2

Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from
scan.coverity.com:

1476275, 1274012, 1455035, 1364789, 1454282
1467483, 1406152, 1406255, 1454837, 1454416
1467446, 1462022, 1461909, 1420566, 1327228
1367767, 1431254, 1467299, 1312678, 1431780
1454731, 1490403

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

show more ...

[lldb][AArch64] Fix corefile memory reads when there are non-address bits

Previously if you read a code/data mask before there was a valid thread
you would get the top byte mask. This meant the valu

[lldb][AArch64] Fix corefile memory reads when there are non-address bits

Previously if you read a code/data mask before there was a valid thread
you would get the top byte mask. This meant the value was "valid" as in,
don't read it again.

When using a corefile we ask for the data mask very early on and this
meant that later once you did have a thread it wouldn't read the
register to get the rest of the mask.

This fixes that and adds a corefile test generated from the same program
as in my previous change on this theme.

Depends on D118794

Reviewed By: omjavaid

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

show more ...