Skip to content

[llvm-debuginfo-analyzer] Support DW_AT_byte_size and DW_TAG_module #3

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.

Sign up for GitHub

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

Jump to bottom
Merged
jalopezg-git merged 2 commits into from
Apr 25, 2025
Merged

[llvm-debuginfo-analyzer] Support DW_AT_byte_size and DW_TAG_module #3

jalopezg-git merged 2 commits into from
Apr 25, 2025

Conversation

@jalopezg-git
Copy link

@jalopezg-git jalopezg-git commented Apr 24, 2025

This pull request improves LVDWARFReader to deal with a couple of unhandled cases. Specifically,

  • Add support for DW_TAG_module DIEs and recurse over their children. Prior to this patchset, entities hanging below DW_TAG_module were just not visible. This DIE kind is commonly generated by Objective-C modules.
    This patch suggests to add LVScopeModule to represent such entities, which will print as
[0x000000000b][001]              {CompileUnit} '/llvm/tools/clang/test/modules/<stdin>'
[0x000000000b][002]                {Producer} 'LLVM version 3.7.0'
                                   {Directory} '/llvm/tools/clang/test/modules'
                                   {File} '<stdin>'
[0x0000000023][002]                {Module} 'debugmodule'

The minimal test case included is just the result of

$ llc llvm/test/DebugInfo/X86/DIModule.ll -accel-tables=Dwarf -o llvm/unittests/DebugInfo/LogicalView/Inputs/test-dwarf-clang-module.o -filetype=obj
  • Introduce handling of DW_AT_byte_size. Most DWARF emitters include this attribute for types to specify the size of an entity of the given type.

__
NOTE: this PR is a backport of upstream llvm#137228 to the zmpr-b-llvmorg-19.1.1-patches branch. Such branch is forked from upstream tag llvmorg-19.1.1.

FYI @peledins-zimperium.

@jalopezg-git jalopezg-git added the enhancement New feature or request label Apr 24, 2025
@jalopezg-git jalopezg-git force-pushed the zmpr-b-llvmorg-19.1.1-logicalview-improve-LVDWARFReader branch from 3eba433 to cb04332 Compare April 24, 2025 20:30
@peledins-zimperium
Copy link

peledins-zimperium commented Apr 25, 2025

I wonder if a better name would not be
Support DW_AT_byte_size and DW_TAG_module
instead of Improve DWARF parsing capabilities

peledins-zimperium
peledins-zimperium reviewed Apr 25, 2025
View reviewed changes
peledins-zimperium
peledins-zimperium reviewed Apr 25, 2025
View reviewed changes
@jalopezg-git jalopezg-git changed the title [llvm-debuginfo-analyzer] Improve DWARF parsing capabilities [llvm-debuginfo-analyzer] Support DW_AT_byte_size and DW_TAG_module Apr 25, 2025
@jalopezg-git jalopezg-git force-pushed the zmpr-b-llvmorg-19.1.1-logicalview-improve-LVDWARFReader branch from cb04332 to c021cd2 Compare April 25, 2025 14:32
@jalopezg-git jalopezg-git force-pushed the zmpr-b-llvmorg-19.1.1-logicalview-improve-LVDWARFReader branch from c021cd2 to 6a42d8d Compare April 25, 2025 15:22
peledins-zimperium
peledins-zimperium approved these changes Apr 25, 2025
View reviewed changes
Copy link

@peledins-zimperium peledins-zimperium left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you!

@jalopezg-git jalopezg-git merged commit 5f4f314 into Zimperium:zmpr-b-llvmorg-19.1.1-patches Apr 25, 2025
2 checks passed
@jalopezg-git jalopezg-git deleted the zmpr-b-llvmorg-19.1.1-logicalview-improve-LVDWARFReader branch April 25, 2025 16:16
peledins-zimperium pushed a commit that referenced this pull request May 22, 2025
@anutosh491 @tstellar
[clang-repl] : Fix clang-repl crash with --cuda flag (llvm#136404)
c877757 
`clang-repl --cuda` was previously crashing with a segmentation fault,
instead of reporting a clean error
```
(base) anutosh491@Anutoshs-MacBook-Air bin % ./clang-repl --cuda
#0 0x0000000111da4fbc llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x150fbc)
#1 0x0000000111da31dc llvm::sys::RunSignalHandlers() (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x14f1dc)
#2 0x0000000111da5628 SignalHandler(int) (/opt/local/libexec/llvm-20/lib/libLLVM.dylib+0x151628)
#3 0x000000019b242de4 (/usr/lib/system/libsystem_platform.dylib+0x180482de4)
#4 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0)
#5 0x0000000107f638d0 clang::IncrementalCUDADeviceParser::IncrementalCUDADeviceParser(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, clang::CompilerInstance&, llvm::IntrusiveRefCntPtr<llvm::vfs::InMemoryFileSystem>, llvm::Error&, std::__1::list<clang::PartialTranslationUnit, std::__1::allocator<clang::PartialTranslationUnit>> const&) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x216b8d0)
llvm#6 0x0000000107f6bac8 clang::Interpreter::createWithCUDA(std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>, std::__1::unique_ptr<clang::CompilerInstance, std::__1::default_delete<clang::CompilerInstance>>) (/opt/local/libexec/llvm-20/lib/libclang-cpp.dylib+0x2173ac8)
llvm#7 0x000000010206f8a8 main (/opt/local/libexec/llvm-20/bin/clang-repl+0x1000038a8)
llvm#8 0x000000019ae8c274
Segmentation fault: 11
```

The underlying issue was that the `DeviceCompilerInstance` (used for
device-side CUDA compilation) was never initialized with a `Sema`, which
is required before constructing the `IncrementalCUDADeviceParser`.

https://github.com/llvm/llvm-project/blob/89687e6f383b742a3c6542dc673a84d9f82d02de/clang/lib/Interpreter/DeviceOffload.cpp#L32

https://github.com/llvm/llvm-project/blob/89687e6f383b742a3c6542dc673a84d9f82d02de/clang/lib/Interpreter/IncrementalParser.cpp#L31

Unlike the host-side `CompilerInstance` which runs `ExecuteAction`
inside the Interpreter constructor (thereby setting up Sema), the
device-side CI was passed into the parser uninitialized, leading to an
assertion or crash when accessing its internals.

To fix this, I refactored the `Interpreter::create` method to include an
optional `DeviceCI` parameter. If provided, we know we need to take care
of this instance too. Only then do we construct the
`IncrementalCUDADeviceParser`.

(cherry picked from commit 21fb19f)
peledins-zimperium pushed a commit that referenced this pull request May 22, 2025
@anutosh491 @tstellar
[clang-repl] Fix destructor for interpreter for the cuda negation case (
2b34040 
llvm#138091)

Check this error for more context
(https://github.com/compiler-research/CppInterOp/actions/runs/14749797085/job/41407625681?pr=491#step:10:531)

This fails with
```
* thread #1, name = 'CppInterOpTests', stop reason = signal SIGSEGV: address not mapped to object (fault address: 0x55500356d6d3)
  * frame #0: 0x00007fffee41cfe3 libclangCppInterOp.so.21.0gitclang::PragmaNamespace::~PragmaNamespace() + 99
    frame #1: 0x00007fffee435666 libclangCppInterOp.so.21.0gitclang::Preprocessor::~Preprocessor() + 3830
    frame #2: 0x00007fffee20917a libclangCppInterOp.so.21.0gitstd::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release() + 58
    frame #3: 0x00007fffee224796 libclangCppInterOp.so.21.0gitclang::CompilerInstance::~CompilerInstance() + 838
    frame #4: 0x00007fffee22494d libclangCppInterOp.so.21.0gitclang::CompilerInstance::~CompilerInstance() + 13
    frame #5: 0x00007fffed95ec62 libclangCppInterOp.so.21.0gitclang::IncrementalCUDADeviceParser::~IncrementalCUDADeviceParser() + 98
    frame llvm#6: 0x00007fffed9551b6 libclangCppInterOp.so.21.0gitclang::Interpreter::~Interpreter() + 102
    frame llvm#7: 0x00007fffed95598d libclangCppInterOp.so.21.0gitclang::Interpreter::~Interpreter() + 13
    frame llvm#8: 0x00007fffed9181e7 libclangCppInterOp.so.21.0gitcompat::createClangInterpreter(std::vector<char const*, std::allocator<char const*>>&) + 2919
```

Problem :

1) The destructor currently handles no clearance for the DeviceParser
and the DeviceAct. We currently only have this

https://github.com/llvm/llvm-project/blob/976493822443c52a71ed3c67aaca9a555b20c55d/clang/lib/Interpreter/Interpreter.cpp#L416-L419

2) The ownership for DeviceCI currently is present in
IncrementalCudaDeviceParser. But this should be similar to how the
combination for hostCI, hostAction and hostParser are managed by the
Interpreter. As on master the DeviceAct and DeviceParser are managed by
the Interpreter but not DeviceCI. This is problematic because :
IncrementalParser holds a Sema& which points into the DeviceCI. On
master, DeviceCI is destroyed before the base class ~IncrementalParser()
runs, causing Parser::reset() to access a dangling Sema (and as Sema
holds a reference to Preprocessor which owns PragmaNamespace) we see
this
```
  * frame #0: 0x00007fffee41cfe3 libclangCppInterOp.so.21.0gitclang::PragmaNamespace::~PragmaNamespace() + 99
    frame #1: 0x00007fffee435666 libclangCppInterOp.so.21.0gitclang::Preprocessor::~Preprocessor() + 3830

```

(cherry picked from commit 529b6fc)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@peledins-zimperium peledins-zimperium peledins-zimperium approved these changes

Assignees

@jalopezg-git jalopezg-git

Labels

enhancement New feature or request

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@jalopezg-git @peledins-zimperium