Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[lldb][Plugins][Swift] Reflect API changes in SwiftExpressionParser #8678

Conversation

antoniofrighetto
Copy link

swift::performLLVMOptimizations was recently changed as part of swiftlang/swift#68985.

JDevlieghere and others added 30 commits March 22, 2024 08:05
[lldb] Be more precise when copying over Swift resources
[lldb] Move two settings from target.experimental to symbols
Skip 32 bit relocation addend partitioning in MCCAS.
…gen-cherrypick

[lldb][progress][NFC] Clarify Doxygen comments for `details` field (#…
Add a frame recognizer for Swift runtime error with instrumentation.
For testing purposes, it's useful to have a setting to disable the
instantiation of SwiftASTContext, to ensure that
TypeSystemSwiftTypeRef, which by default falls back to it on failure, is
working independently.

This setting might also be useful for end users, as when debugging
a program that was built with a different compiler version versus what
is embedded in LLDB instantiation of Swift AST contexts would be moot.
Split TestSwiftEmbeddedFrameVariable into one test that runs with
instantiation of SwiftASTContext enabled, and one that runs with it
disabled.

The first one is useful because of the validation code that compares
TypeSystemSwiftTypeRef results with SwiftASTContext's.

The second one is useful to validate that the test is passing without
TypeSystemSwiftTypeRef falling back to SwiftASTContext.
[ConstantRange] Fix miscompile caused by off by 1 bugs in UIToFP and SIToFP handling
Disable driver tests on macosx that are currently disabled on darwin
[lldb] Split TestSwiftEmbeddedFrameVariable into two tests
PrintRegularClangComments is being removed in swift.

(cherry picked from commit 3979c8a)
…ssions (llvm#85492)

The idea behind the address-expression is that it handles all the common
expressions that produce addresses. It handles actual valid expressions
that return a scalar, and it handles useful cases that the various
source languages don't support. At present, the fallback handles:

<symbol_name>{+-}<offset>

which isn't valid C but is very handy.

This patch adds handling of:

$<reg_name>

and

$<reg_name>{+-}<offset>

That's kind of pointless in C because the C expression parser handles
that expression already. But some languages don't have a straightforward
way to represent register values like this (swift) so having this
fallback is quite a quality of life improvement.

I added a test which tests that I didn't mess up either of these
fallbacks, though it doesn't test the actually handling of registers
that I added, since the expression parser for C succeeds in that case
and returns before this code gets run.

I will add a test on the swift fork for that checks that this works the
same way for a swift frame after this check.

(cherry picked from commit 2c76e88)
…lvm#86359)

It is possible to gather code coverage in a firmware environment, where
the __LLVM_COV segment will not be mapped in memory but does exist in
the binary, see

https://llvm.org/devmtg/2020-09/slides/PhippsAlan_EmbeddedCodeCoverage_LLVM_Conf_Talk_final.pdf

The __LLVM_COV segment in the binary happens to be at the same address
as the __DATA segment, so if lldb treats this segment as loaded, it
shadows the __DATA segment and address->symbol resolution can fail.

For these non-userland code cases, we need to mark __LLVM_COV as not a
loadable segment.

rdar://124475661
(cherry picked from commit 765d4c4)
…-in-memory-6.0

[lldb] [ObjectFileMachO] LLVM_COV is not mapped into firmware memory (llvm#86359)
…lvm#86603)

Fixing a crash in lldb when `symbols.auto-download` setting is enabled.
When doing a backtrace, this feature has lldb search for a SymbolFile
for stack frames when we are backtracing, and add them either
synchoronously or asynchronously, depending on the specific setting
used.

Module::SetSymbolFileFileSpec clears the Module's UnwindTable, once we
find a new SymbolFile. We may be adding a source of unwind information
that we did not have when lldb was working only with the executable
binary.

What happens in practice is that we're using a reference to the Module's
UnwindTable, and then the other thread getting the SymbolFile clears it
and now the first thread is referring to freed memory and we can crash.
When built with address sanitizer, it crashes much more reliably.

Given that unwind information used for exception handling -- eh_frame,
compact unwind -- is present in executable binaries, the only thing
we're likely to *add* would be DWARF's `debug_frame` if that was also
available. The actual value of re-creating the UnwindTable when we have
added a SymbolFile is not large.

I also tried fixing this by changing the Module to have a shared_ptr to
the UnwindTable, so we could have two different UnwindTable's in use
simultaneously for a brief period. This would be fine TODAY, but it
introduces a very subtle bug that someone will have a heck of a time
figuring out in the future.

In the end, I believe the safest approach is to sacrifice the possible
marginal gain of reconstructing the UnwindTable once a SymbolFile has
been added, to sidestep this whole problem area.

Also, in `Module::GetUnwindTable()`, call `DownloadSymbolFileAsync`
before we create the UnwindTable for the first time, in case the symbol
file is fetched synchronously, we will have it for that possible
marginal gain.

(cherry picked from commit 2f63718)
[cherry-pick stable/20230725] Revert "[ClangScanDeps] Fix cas dependency scanning test after D159064"
Add an <address-expression> fallback that handles register expressions
Clear the Clang type cache when new modules are loaded / Create non-null typerefs in field descriptors for Clang types
Since b4c83a1, `Preprocessor` and
`Lexer` are aware of the concept of scanning dependency directives. This
makes it possible to scan for them on-demand rather than eagerly on the
first filesystem operation (open, or even just stat).

This might improve performance, but is also necessary for the "PCH as
module" mode. Some precompiled header sources use the ".pch" file
extension, which means they were not getting scanned for dependency
directives. This was okay when the PCH was the main input file in a
separate scan step, because there we just lex the file in a
scanning-specific frontend action. But when such source gets treated as
a module implicitly loaded from a TU, it will get compiled as any other
module - with Sema - which will result in compilation errors. (See
attached test case.)

rdar://107663951
(cherry picked from commit b768a8c)
[DebugInfo] Add default true return for unexpected types in isUnsignedType
In
     commit 2f63718
     Author: Jason Molenda <[email protected]>
     Date:   Tue Mar 26 09:07:15 2024 -0700

[lldb] Don't clear a Module's UnwindTable when adding a SymbolFile
(llvm#86603)

I stopped clearing a Module's UnwindTable when we add a SymbolFile to
avoid the memory management problems with adding a symbol file
asynchronously while the UnwindTable is being accessed on another
thread. This broke the target-symbols-add-unwind.test shell test on
Linux which removes the DWARF debub_frame section from a binary, loads
it, then loads the unstripped binary with the DWARF debug_frame section
and checks that the UnwindPlans for a function include debug_frame.

I originally decided that I was willing to sacrifice the possiblity of
additional unwind sources from a symbol file because we rely on assembly
emulation so heavily, they're rarely critical. But there are targets
where we we don't have emluation and rely on things like DWARF
debug_frame a lot more, so this probably wasn't a good choice.

This patch adds a new UnwindTable::Update method which looks for any new
sources of unwind information and adds it to the UnwindTable, and calls
that after a new SymbolFile has been added to a Module.

(cherry picked from commit 6a0ec8e)
Currently, progress events reported by the ProgressManager and broadcast
to eBroadcastBitProgressCategory always specify they're complete. The
problem is that the ProgressManager reports kNonDeterministicTotal for
both the total and the completed number of (sub)events. Because the
values are the same, the event reports itself as complete.

This patch fixes the issue by reporting 0 as the completed value for the
start event and kNonDeterministicTotal for the end event.

(cherry picked from commit ea49e04)
adrian-prantl and others added 21 commits April 25, 2024 16:02
[lldb] Support reconstructing types compiled with a different abi name
…ift-6

[6.0][IncludeTree] Fix PPCallback for include tree that can cause missing .d file
🍒 Compact C Type Format Cherrypicks
llvm#87409 removed the broadcast
bits from SBDebugger and placed them in `lldb-enumerations.h`. This is
API-breaking so this commits places the enum back into `SBDebugger.h`
and references the bits from `lldb-enumerations.h`.

rdar://127128536
(cherry picked from commit a4c21d1)
This is a companion to swiftlang/swift#73255, and
it's needed in some Apple internal configurations.

Addresses rdar://127113448

(cherry picked from commit 842763b)
…gger-bits

[lldb][sbapi] Fix API break in SBDebugger broadcast bits (llvm#90261)
…progress-reports

[lldb][progress] Mitigate non-specific LLDB progress reports in Swift
With Swift, misconfigured Xcode projects currently may fail with negative 'stat' caching of `.framework` directories enabled, because they do not always explicitly specify their target dependencies and may be either getting lucky wih build timing, or compiling against wrong dependenceis a lot of the time: e.g. an SDK variant of a dependency module, instead of one in the project's own build directory. Temporarily disable negative 'stat' caching here until all such projects are fixed.

rdar://127079541
…ion (llvm#86386)

Move the code adding top-level cmake/Modules directory to
CMAKE_MODULE_PATH prior to including `GetDarwinLinkerVersion`, in order
to fix standalone builds.

Fixes a regression introduced by
3bc71c2.
llvm#86220)

The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects
the linker version at configure time. The driver uses this information
to build the correct set of arguments for the linker. This patch detects
the linker version again during compiler-rt configuration and passes it
to the tests. This allows a clang built on a machine with a new linker
to run compiler-rt tests on a machine with an old linker.

rdar://125198603
The HOST_LINK_VERSION is a hardcoded string in Darwin clang that detects
the linker version at configure time. The driver uses this information
to build the correct set of arguments for the linker. This patch detects
the linker version again during compiler-rt configuration and passes it
to the libfuzzer tests. This allows a clang built on a machine with a
new linker to run compiler-rt tests on a machine with an old linker.

rdar://125932376
This is not needed as the correct linker version is detected at
configure time and passed to all tests on Darwin.

rdar://125052667
In MCCAS, the DWARF5 size is larger than the DWARF4 size because of the
presence of the debug_str_offset section. There is not much we can do to
improve the deduplication rate of that section, so the only thing to do
is to compress the data in that cas block, which is what this patch adds
support for.

(cherry picked from commit de44455)
[Cherrypicks] Sanitizer ci fixes and a test fix
…eworkStatCachingWorkaround

Temporarily disable negative `stat` caching for `.framework` directories
Add zlib compression to the debug_str_offset section
`swift::performLLVMOptimizations` was recently changed.
@antoniofrighetto antoniofrighetto changed the base branch from swift/release/6.0 to stable/20230725 July 31, 2024 17:24
@antoniofrighetto antoniofrighetto changed the base branch from stable/20230725 to stable/20240723 November 12, 2024 19:58
@antoniofrighetto
Copy link
Author

Wrong rebase, sorry for the noise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.