This patch adds support for emission of following DWARFv5 macro forms in debug_macro section.
- DW_MACRO_start_file
- DW_MACRO_end_file
- DW_MACRO_define_strp
- DW_MACRO_undef_strp.
Differential D72828
[DWARF5] Added support for emission of debug_macro section. SouraVX on Jan 16 2020, 2:55 AM. Authored by
Details This patch adds support for emission of following DWARFv5 macro forms in debug_macro section.
Diff Detail Event TimelineComment Actions Unit tests: fail. 61911 tests passed, 1 failed and 783 were skipped. failed: LLVM.MC/WebAssembly/debug-info.ll clang-tidy: unknown. clang-format: pass. Build artifacts: diff.json, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
Comment Actions Please implement the dwarfdump support first (this patch can be reviewed during that time - but shouldn't be committed without tests & ideally those tests should be written using dwarfdump (sometimes there are exceptions for especially complicated dumping situations, where raw assembly testing is used instead, but I don't think it's necessary to make that tradeoff here)) & I'm surprised this patch causes updates to the tests - what changes in the patch caused changes in these tests? (stringpool and dbg-stack-value-range.mir) - ah, because debug_str now needs to be emitted after debug_macro because the macro section might introduce new strings? OK. Could you separate that ordering change/test update out into a standalone patch. It'll make the rest of this more targeted when reviewing.
Comment Actions I'm trying to get that patch ready. As for this, this patch doesn't have dependency on dwarfdump except that testing the section contents part. I've verified integrity of section content using objdump and lldb/gdb. My rationale behind this was this patch can get in, till we discuss and agree on dwarfdump extension to accommodate macro support.
Yes, that' s intentional. I've shifted the string emission to post macro emission to put macro content in string section. BTW are you suggesting here to do that change/patch commit separately ?? Thanks David for reviewing/sharing your thoughts on this.
Comment Actions Thanks @probinson for sharing thoughts.
Comment Actions Thank You, @aprantl, for your acceptance. I agree, that part of macro implementation needs refactoring/In my opinion/. That was the reason, I was delaying and created separate patch for llvm-dwarfdump D73086. So that, even if we disagree/want changes, for a better implementation of dumping part. Comment Actions Ping! Comment Actions This doesn't seem to be tested - the couple of test updates are to keep them passing after changing the ordering of sections - ideally that change (changing the ordering of sections, so strings can come after macros) should be committed separately (just change the order and update the few tests that need it) & explicit/full test coverage for this feature should be added and should use llvm-dwarfdump (so this patch should come after the one that adds functionality to llvm-dwarfdump for dumping this section).
Comment Actions Incorporated @dblaikie comments! Comment Actions Ping this when the llvm-dwarfdump support for debug_macro is in and this patch has been updated with test coverage using that support.
Comment Actions Incorporated @ikudrin comments,
Comment Actions Hi @ikudrin and other reviewers, How about committing Dwarf.def and Dwarf.h changes/Mostly Flag encodings/ and stringify encoding functionalties as separate commit. That will resolve most of false dependencies. In my opinion that part adding those flags and encoding is independent of these patches(for instance, most of other encodings/flags described by dwarfv5 spec are their, even when LLVM/consumer might not be using them at present) and should be committed separately. Comment Actions In my understanding, this should still depend on D73086 because this revision requires the dumper for the test(s).
Comment Actions Addressed review comments by @dblaikie. Thanks for this! Comment Actions Looks good to me - please wait for @ikudrin to circle back on this and approve it as well.
|
Remove OFFSET_SIZE_32, as this value does not define any real flag.