[lldb][NFC] Make the target's SectionLoadList private. (#113278)

Lots of code around LLDB was directly accessing the target's section
load list. This NFC patch makes the section load list private s

[lldb][NFC] Make the target's SectionLoadList private. (#113278)

Lots of code around LLDB was directly accessing the target's section
load list. This NFC patch makes the section load list private so the
Target class can access it, but everyone else now uses accessor
functions. This allows us to control the resolving of addresses and will
allow for functionality in LLDB which can lazily resolve addresses in
JIT plug-ins with a future patch.

show more ...

Reland: [lldb] Implement a formatter bytecode interpreter in C++

Compared to the python version, this also does type checking and error
handling, so it's slightly longer, however, it's still comfort

Reland: [lldb] Implement a formatter bytecode interpreter in C++

Compared to the python version, this also does type checking and error
handling, so it's slightly longer, however, it's still comfortably
under 500 lines.

Relanding with more explicit type conversions.

show more ...

Revert "[lldb] Add cast to fix compile error on 32-bit platforms"

This reverts commit f6012a209dca6b1866d00e6b4f96279469884320.

Revert "[lldb] Add cast to fix compile error on 32-but platforms"

Th

Revert "[lldb] Add cast to fix compile error on 32-bit platforms"

This reverts commit f6012a209dca6b1866d00e6b4f96279469884320.

Revert "[lldb] Add cast to fix compile error on 32-but platforms"

This reverts commit d300337e93da4ed96b044557e4b0a30001967cf0.

Revert "[lldb] Improve log message to include missing strings"

This reverts commit 0be33484853557bc0fd9dfb94e0b6c15dda136ce.

Revert "[lldb] Add comment"

This reverts commit e2bb47443d2e5c022c7851dd6029e3869fc8835c.

Revert "[lldb] Implement a formatter bytecode interpreter in C++"

This reverts commit 9a9c1d4a6155a96ce9be494cec7e25731d36b33e.

show more ...

[lldb] Implement a formatter bytecode interpreter in C++

Compared to the python version, this also does type checking and error
handling, so it's slightly longer, however, it's still comfortably
und

[lldb] Implement a formatter bytecode interpreter in C++

Compared to the python version, this also does type checking and error
handling, so it's slightly longer, however, it's still comfortably
under 500 lines.

show more ...

[lldb] Load embedded type summary section (#7859) (#8040)

Add support for type summaries embedded into the binary.

These embedded summaries will typically be generated by Swift macros,
but can also

[lldb] Load embedded type summary section (#7859) (#8040)

Add support for type summaries embedded into the binary.

These embedded summaries will typically be generated by Swift macros,
but can also be generated by any other means.

rdar://115184658

show more ...

Revert "Re-apply [lldb] Do not use LC_FUNCTION_STARTS data to determine symbol size as symbols are created (#117079)"

This reverts commit ba668eb99c5dc37d3c5cf2775079562460fd7619.

Below test starte

Revert "Re-apply [lldb] Do not use LC_FUNCTION_STARTS data to determine symbol size as symbols are created (#117079)"

This reverts commit ba668eb99c5dc37d3c5cf2775079562460fd7619.

Below test started failing again on x86_64 macOS CI. We're unsure
if this patch is the exact cause, but since this patch has broken
this test before, we speculatively revert it to see if it was indeed
the root cause.
```
FAIL: lldb-shell :: Unwind/trap_frame_sym_ctx.test (1692 of 2162)
******************** TEST 'lldb-shell :: Unwind/trap_frame_sym_ctx.test' FAILED ********************
Exit Code: 1

Command Output (stderr):
--
RUN: at line 7: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/clang --target=specify-a-target-or-use-a-_host-substitution --target=x86_64-apple-darwin22.6.0 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -fmodules-cache-path=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-shell /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/call-asm.c /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/trap_frame_sym_ctx.s -o /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp
+ /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/clang --target=specify-a-target-or-use-a-_host-substitution --target=x86_64-apple-darwin22.6.0 -isysroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -fmodules-cache-path=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-shell /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/call-asm.c /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/Inputs/trap_frame_sym_ctx.s -o /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp
clang: warning: argument unused during compilation: '-fmodules-cache-path=/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/lldb-test-build.noindex/module-cache-clang/lldb-shell' [-Wunused-command-line-argument]
RUN: at line 8: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/lldb --no-lldbinit -S /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/lit-lldb-init-quiet /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp -s /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test -o exit | /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/FileCheck /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test
+ /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/lldb --no-lldbinit -S /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/lit-lldb-init-quiet /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/tools/lldb/test/Shell/Unwind/Output/trap_frame_sym_ctx.test.tmp -s /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test -o exit
+ /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/lldb-build/bin/FileCheck /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test
/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test:21:10: error: CHECK: expected string not found in input
^
<stdin>:26:64: note: scanning from here
frame #1: 0x0000000100003ee9 trap_frame_sym_ctx.test.tmp`tramp
^
<stdin>:27:2: note: possible intended match here
frame #2: 0x00007ff7bfeff6c0
^

Input file: <stdin>
Check file: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test

-dump-input=help explains the following input dump.

Input was:
<<<<<<
.
.
.
21: 0x100003ed1 <+0>: pushq %rbp
22: 0x100003ed2 <+1>: movq %rsp, %rbp
23: (lldb) thread backtrace -u
24: * thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1
25: * frame #0: 0x0000000100003ecc trap_frame_sym_ctx.test.tmp`bar
26: frame #1: 0x0000000100003ee9 trap_frame_sym_ctx.test.tmp`tramp
check:21'0 X error: no match found
27: frame #2: 0x00007ff7bfeff6c0
check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
check:21'1 ? possible intended match
28: frame #3: 0x0000000100003ec6 trap_frame_sym_ctx.test.tmp`main + 22
check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
29: frame #4: 0x0000000100003ec6 trap_frame_sym_ctx.test.tmp`main + 22
check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30: frame #5: 0x00007ff8193cc41f dyld`start + 1903
check:21'0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
31: (lldb) exit
check:21'0 ~~~~~~~~~~~~
>>>>>>
```

show more ...

[lldb][Mach-O] Handle shared cache binaries correctly (#117832)

The Mach-O load commands have an LC_SYMTAB / struct symtab_command which
represents the offset of the symbol table (nlist records) an

[lldb][Mach-O] Handle shared cache binaries correctly (#117832)

The Mach-O load commands have an LC_SYMTAB / struct symtab_command which
represents the offset of the symbol table (nlist records) and string
table for this binary. In a mach-o binary on disk, these are file
offsets. If a mach-o binary is loaded in memory with all segments
consecutive, the `symoff` and `stroff` are the offsets from the TEXT
segment (aka the mach-o header) virtual address to the virtual address
of the start of these tables.

However, if a Mach-O binary is a part of the shared cache, then the
segments will be separated -- they will have different slide values. And
it is possible for the LINKEDIT segment to be greater than 4GB away from
the TEXT segment in the virtual address space, so these 32-bit offsets
cannot express the offset from TEXT segment to these tables.

Create separate uint64_t variables to track the offset to the symbol
table and string table, instead of reusing the 32-bit ones in the
symtab_command structure.

rdar://140432279

show more ...

[lldb][NFC] Whitespace fix for mis-indented block

This mis-indented block makes a FC change I'm about
to propose look larger than it is when clang-formatted.

Re-apply [lldb] Do not use LC_FUNCTION_STARTS data to determine symbol size as symbols are created (#117079)

I backed this out due to a problem on one of the bots that myself and
others have proble

Re-apply [lldb] Do not use LC_FUNCTION_STARTS data to determine symbol size as symbols are created (#117079)

I backed this out due to a problem on one of the bots that myself and
others have problems reproducing locally. I'd like to try to land it
again, at least to gain more information.

Summary:
This improves the performance of ObjectFileMacho::ParseSymtab by
removing eager and expensive work in favor of doing it later in a
less-expensive fashion.

Experiment:
My goal was to understand LLDB's startup time.
First, I produced a Debug build of LLDB (no dSYM) and a
Release+NoAsserts build of LLDB. The Release build debugged the Debug
build as it debugged a small C++ program. I found that
ObjectFileMachO::ParseSymtab accounted for somewhere between 1.2 and 1.3
seconds consistently. After applying this change, I consistently
measured a reduction of approximately 100ms, putting the time closer to
1.1s and 1.2s on average.

Background:
ObjectFileMachO::ParseSymtab will incrementally create symbols by
parsing nlist entries from the symtab section of a MachO binary. As it
does this, it eagerly tries to determine the size of symbols (e.g. how
long a function is) using LC_FUNCTION_STARTS data (or eh_frame if
LC_FUNCTION_STARTS is unavailable). Concretely, this is done by
performing a binary search on the function starts array and calculating
the distance to the next function or the end of the section (whichever
is smaller).

However, this work is unnecessary for 2 reasons:
1. If you have debug symbol entries (i.e. STABs), the size of a function
is usually stored right after the function's entry. Performing this work
right before parsing the next entry is unnecessary work.
2. Calculating symbol sizes for symbols of size 0 is already performed
in `Symtab::InitAddressIndexes` after all the symbols are added to the
Symtab. It also does this more efficiently by walking over a list of
symbols sorted by address, so the work to calculate the size per symbol
is constant instead of O(log n).

show more ...

[lldb] fix one-off error in vformat specifier

Results in an assert at runtime, when run on an improperly formed
corefile.

rdar://136659551

Revert "[lldb] Do not use LC_FUNCTION_STARTS data to determine symbol size as symbols are created" (#108715)

Reverts llvm/llvm-project#106791 because it breaks
`trap_frame_sym_ctx.test ` on x86_64.

Revert "[lldb] Do not use LC_FUNCTION_STARTS data to determine symbol size as symbols are created" (#108715)

Reverts llvm/llvm-project#106791 because it breaks
`trap_frame_sym_ctx.test ` on x86_64.

https://green.lab.llvm.org/job/llvm.org/view/LLDB/job/lldb-cmake/5745/

show more ...

[lldb] Do not use LC_FUNCTION_STARTS data to determine symbol size as symbols are created (#106791)

Summary:
This improves the performance of ObjectFileMacho::ParseSymtab by
removing eager and exp

[lldb] Do not use LC_FUNCTION_STARTS data to determine symbol size as symbols are created (#106791)

Summary:
This improves the performance of ObjectFileMacho::ParseSymtab by
removing eager and expensive work in favor of doing it later in a
less-expensive fashion.

Experiment:
My goal was to understand LLDB's startup time.
First, I produced a Debug build of LLDB (no dSYM) and a
Release+NoAsserts build of LLDB. The Release build debugged the Debug
build as it debugged a small C++ program. I found that
ObjectFileMachO::ParseSymtab accounted for somewhere between 1.2 and 1.3
seconds consistently. After applying this change, I consistently
measured a reduction of approximately 100ms, putting the time closer to
1.1s and 1.2s on average.

Background:
ObjectFileMachO::ParseSymtab will incrementally create symbols by
parsing nlist entries from the symtab section of a MachO binary. As it
does this, it eagerly tries to determine the size of symbols (e.g. how
long a function is) using LC_FUNCTION_STARTS data (or eh_frame if
LC_FUNCTION_STARTS is unavailable). Concretely, this is done by
performing a binary search on the function starts array and calculating
the distance to the next function or the end of the section (whichever
is smaller).

However, this work is unnecessary for 2 reasons:
1. If you have debug symbol entries (i.e. STABs), the size of a function
is usually stored right after the function's entry. Performing this work
right before parsing the next entry is unnecessary work.
2. Calculating symbol sizes for symbols of size 0 is already performed
in `Symtab::InitAddressIndexes` after all the symbols are added to the
Symtab. It also does this more efficiently by walking over a list of
symbols sorted by address, so the work to calculate the size per symbol
is constant instead of O(log n).

show more ...

[LLDB] Reapply SBSaveCore Add Memory List (#107937)

Recently in #107731 this change was revereted due to excess memory size
in `TestSkinnyCore`. This was due to a bug where a range's end was being

[LLDB] Reapply SBSaveCore Add Memory List (#107937)

Recently in #107731 this change was revereted due to excess memory size
in `TestSkinnyCore`. This was due to a bug where a range's end was being
passed as size. Creating massive memory ranges.

Additionally, and requiring additional review, I added more unit tests
and more verbose logic to the merging of save core memory regions.

@jasonmolenda as an FYI.

show more ...

Revert "[LLDB] Reappply SBSaveCore AddMemoryList" (#107731)

Reverts llvm/llvm-project#107159 as this is still causing
`TestSkinnyCorefile.py` to time out.


https://ci.swift.org/view/all/job/llv

Revert "[LLDB] Reappply SBSaveCore AddMemoryList" (#107731)

Reverts llvm/llvm-project#107159 as this is still causing
`TestSkinnyCorefile.py` to time out.


https://ci.swift.org/view/all/job/llvm.org/view/LLDB/job/as-lldb-cmake/11099/

https://ci.swift.org/view/all/job/llvm.org/view/LLDB/job/lldb-cmake/5544/

show more ...

[LLDB] Reappply SBSaveCore AddMemoryList (#107159)

Reapplies #106293, testing identified issue in the merging code. I used
this opportunity to strip CoreFileMemoryRanges to it's own file and then

[LLDB] Reappply SBSaveCore AddMemoryList (#107159)

Reapplies #106293, testing identified issue in the merging code. I used
this opportunity to strip CoreFileMemoryRanges to it's own file and then
add unit tests on it's behavior.

show more ...

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

…ror() [NFC]

Revert "[LLDB][SBSaveCore] Add selectable memory regions to SBSaveCor… (#106293)

Reverts #105442. Due to `TestSkinnyCoreFailing` and root causing of the
failure will likely take longer than EOD.

[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][SBSaveCore] Add selectable memory regions to SBSaveCore (#105442)

This patch adds the option to specify specific memory ranges to be
included in a given core file. The current implementation

[LLDB][SBSaveCore] Add selectable memory regions to SBSaveCore (#105442)

This patch adds the option to specify specific memory ranges to be
included in a given core file. The current implementation lets user
specified ranges either be in addition to a certain save style, or
independent of them via the newly added custom enum.

To achieve being inclusive of save style, I've moved from a std::vector
of ranges to a RangeDataVector, and to join overlapping ranges to
prevent duplication of memory ranges in the core file.

As a non function bonus, when SBSavecore was initially created, the
header was included in the lldb-private interfaces, and I've fixed that
and moved it the forward declare as an oversight. CC @bulbazord in case
we need to include that into swift.

show more ...

[lldb][AIX] 1. Avoid namespace collision on other platforms (#104679)

This PR is in reference to porting LLDB on AIX.

Link to discussions on llvm discourse and github:
1. https://discourse.llvm

[lldb][AIX] 1. Avoid namespace collision on other platforms (#104679)

This PR is in reference to porting LLDB on AIX.

Link to discussions on llvm discourse and github:
1. https://discourse.llvm.org/t/port-lldb-to-ibm-aix/80640
2. #101657

The complete changes for porting are present in this draft PR:
https://github.com/llvm/llvm-project/pull/102601

The changes on this PR are intended to avoid namespace collision for
certain typedefs between lldb and other platforms:
1. tid_t --> lldb::tid_t
2. offset_t --> lldb::offset_t

show more ...

[LLDB] Reapply #100443 SBSaveCore Thread list (#104497)

Reapply #100443 and #101770. These were originally reverted due to a
test failure and an MSAN failure. I changed the test attribute to
restr

[LLDB] Reapply #100443 SBSaveCore Thread list (#104497)

Reapply #100443 and #101770. These were originally reverted due to a
test failure and an MSAN failure. I changed the test attribute to
restrict to x86 (following the other existing tests). I could not
reproduce the test or the MSAN failure and no repo steps were provided.

show more ...

Revert "[LLDB][SBSaveCore] Implement a selectable threadlist for Core… (#102018)

… Options. (#100443)"

This reverts commit 3e4af616334eae532f308605b89ff158dd195180.

@adrian-prantl FYI

Reve

Revert "[LLDB][SBSaveCore] Implement a selectable threadlist for Core… (#102018)

… Options. (#100443)"

This reverts commit 3e4af616334eae532f308605b89ff158dd195180.

@adrian-prantl FYI

Reverts #100443

show more ...

Revert "[LLDB][SBSaveCore] Fix bug where default values are not propagated. (#101770)"

This reverts commit 34766d0d488ba2fbefa80dcd0cc8720a0e753448 which
caused a msan failure, see comment https://g

Revert "[LLDB][SBSaveCore] Fix bug where default values are not propagated. (#101770)"

This reverts commit 34766d0d488ba2fbefa80dcd0cc8720a0e753448 which
caused a msan failure, see comment https://github.com/llvm/llvm-project/pull/101770#issuecomment-2268373325 for details.

show more ...

[LLDB][SBSaveCore] Fix bug where default values are not propagated. (#101770)

In #100443, Mach-o and Minidump now only call process API's that take a
`SaveCoreOption` as the container for the style

[LLDB][SBSaveCore] Fix bug where default values are not propagated. (#101770)

In #100443, Mach-o and Minidump now only call process API's that take a
`SaveCoreOption` as the container for the style and information if a
thread should be included in the core or not. This introduced a bug
where in subsequent method calls we were not honoring the defaults of
both implementations.

~~To solve this I have made a copy of each SaveCoreOptions that is
mutable by the respective plugin. Originally I wanted to leave the
SaveCoreOptions as non const so these default value mutations could be
shown back to the user. Changing that behavior is outside of the scope
of this bugfix, but is context for why we are making a copy.~~

Removed const on the savecoreoptions so defaults can be inspected by the
user

CC: @Michael137

show more ...

[LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (#100443)

In #98403 I enabled the SBSaveCoreOptions object, which allows users via
the scripting API to define what they want

[LLDB][SBSaveCore] Implement a selectable threadlist for Core Options. (#100443)

In #98403 I enabled the SBSaveCoreOptions object, which allows users via
the scripting API to define what they want saved into their core file.
As the first option I've added a threadlist, so users can scan and
identify which threads and corresponding stacks they want to save.

In order to support this, I had to add a new method to `Process.h` on
how we identify which threads are to be saved, and I had to change the
book keeping in minidump to ensure we don't double save the stacks.

Important to @jasonmolenda I also changed the MachO coredump to accept
these new APIs.

show more ...