-
Notifications
You must be signed in to change notification settings - Fork 14.9k
[BOLT][DWARF] Fix debug info update issue with dwarf4 dwp #155619
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
base: main
Are you sure you want to change the base?
[BOLT][DWARF] Fix debug info update issue with dwarf4 dwp #155619
Conversation
@llvm/pr-subscribers-bolt Author: Jinjie Huang (Jinjie-Huang) ChangesCurrently in emitDWOBuilder(), when emitting Compile Units for DWO with dwarf version below 4, the Compile Unit information is obtained through SplitCU.getContext().dwo_compile_units(). This seems to assume that SplitCU is a DWO. However, if it is a DWP, it will at this point fetch and iterate over CUs that do not belong to the current DWO (and have not been registered), which will lead to a crash during emitUnit. I may not be fully clear about some of the context, but it seems that a better approach here would be to align with the handling in dwarf5 and directly emit the current SplitCU. And this seems to both avoid the crash issue and be more efficient? Full diff: https://github.com/llvm/llvm-project/pull/155619.diff 1 Files Affected:
diff --git a/bolt/lib/Rewrite/DWARFRewriter.cpp b/bolt/lib/Rewrite/DWARFRewriter.cpp
index 0c1a1bac6c72e..6eefa5155298b 100644
--- a/bolt/lib/Rewrite/DWARFRewriter.cpp
+++ b/bolt/lib/Rewrite/DWARFRewriter.cpp
@@ -504,9 +504,7 @@ static void emitDWOBuilder(const std::string &DWOName,
}
emitUnit(DWODIEBuilder, *Streamer, SplitCU);
} else {
- for (std::unique_ptr<llvm::DWARFUnit> &CU :
- SplitCU.getContext().dwo_compile_units())
- emitUnit(DWODIEBuilder, *Streamer, *CU);
+ emitUnit(DWODIEBuilder, *Streamer, SplitCU);
// emit debug_types sections for dwarf4
for (DWARFUnit *CU : DWODIEBuilder.getDWARF4TUVector())
|
@ayermolo @kazutakahirata PTAL, thanks! |
Umm yes, makes sense. |
a2de810
to
1405795
Compare
@ayermolo Thanks for review, and the test has been added. |
Thanks for adding a test. Can you convert it to assembly test, and minimize assembly as much as possible, so it is more robust. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for improving support for split dwarf.
As this is generic, we’d welcome a test that runs on AArch64 too (if not much effort). :)
1405795
to
2884b59
Compare
I've modified the test to use the minimal assembly, and the test for AArch64 has also been added. |
8b89a0e
to
5625046
Compare
5625046
to
4e82b92
Compare
@@ -0,0 +1,450 @@ | |||
# RUN: rm -rf %t && mkdir -p %t && cd %t |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add description of what this test does.
I think current convention is to use ## for Comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Got it. It seems we don't need to describe how the assembly comes via update_test_body.py, so I've also
removed this part for now.
@@ -0,0 +1,453 @@ | |||
# RUN: rm -rf %t && mkdir -p %t && cd %t |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please add description of what this test does.
I think current convention is to use ## for Comments.
echo '#--- callee.s' | ||
clang++ --target=aarch64-unknown-unknown -c -g -gdwarf-4 -gsplit-dwarf -fdebug-compilation-dir=. -Xclang -split-dwarf-file -Xclang main.exe-callee.dwo -S callee.cpp -o - | ||
#--- main.s | ||
.file "main.cpp" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please minimize assembly. Example: #120103
85d39ff
to
6840dc8
Compare
Currently in emitDWOBuilder(), when emitting Compile Units for DWO with dwarf version below 4, the Compile Unit information is obtained through SplitCU.getContext().dwo_compile_units(). This seems to assume that SplitCU is a DWO. However, if it is a DWP, it will at this point fetch and iterate over CUs that do not belong to the current DWO (and have not been registered), which will lead to a crash during emitUnit.
I may not be fully clear about some of the context, but it seems that a better approach here would be to align with the handling in dwarf5 and directly emit the current SplitCU. And this seems to both avoid the crash issue and be more efficient?