forked from llvm/llvm-project
-
Notifications
You must be signed in to change notification settings - Fork 331
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
Closed
antoniofrighetto
wants to merge
2,897
commits into
swiftlang:stable/20240723
from
antoniofrighetto:feature/update-api-swiftexpressionparser
Closed
[lldb][Plugins][Swift] Reflect API changes in SwiftExpressionParser
#8678
antoniofrighetto
wants to merge
2,897
commits into
swiftlang:stable/20240723
from
antoniofrighetto:feature/update-api-swiftexpressionparser
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[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"
rdar://121758809
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)
[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
[clang][cas] Move Error into Expected
🍒 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
…ontent-from-darwin-toolchain-6.0
Add lldb-dap to Swift distributions (llvm#88482)
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
Revert -Wformat for scoped enums
…eworkStatCachingWorkaround Temporarily disable negative `stat` caching for `.framework` directories
Add zlib compression to the debug_str_offset section
`swift::performLLVMOptimizations` was recently changed.
antoniofrighetto
changed the base branch from
swift/release/6.0
to
stable/20230725
July 31, 2024 17:24
antoniofrighetto
changed the base branch from
stable/20230725
to
stable/20240723
November 12, 2024 19:58
antoniofrighetto
requested review from
JDevlieghere,
daniel-grumberg,
cyndyishida and
dcci
as code owners
November 12, 2024 19:58
Wrong rebase, sorry for the noise. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
swift::performLLVMOptimizations
was recently changed as part of swiftlang/swift#68985.