This is an archive of the discontinued LLVM Phabricator instance.

[DWARFYAML][debug_info] Use 'AbbrCode' to index the abbreviation.
ClosedPublic

Authored by Higuoxing on Jun 19 2020, 3:04 AM.

Details

Summary

Before this patch, we use (uint32_t)AbbrCode - (uint32_t)FirstAbbrCode to index the abbreviation. It's impossible for we to use the preceeding abbreviation of the previous one (e.g., if the previous DIE's AbbrCode is 2, we are unable to use the abbreviation with index 1). In this patch, we use AbbrCode to index the abbreviation directly.

Diff Detail

Event Timeline

Higuoxing created this revision.Jun 19 2020, 3:04 AM
jhenderson added inline comments.Jun 19 2020, 3:28 AM
llvm/test/tools/yaml2obj/ELF/DWARF/debug-info.yaml
632

Probably "ignores the contents of entries with abbrev code 0". (I wouldn't use the full term "abbreviation" as I think it's not particularly common usage in this context).

I'd also move this case later in the sequence (possibly the last one), since we should allow a non-zero value to be the "First" abbrev.

636

using the ... -> when the abbrev code is specified.

I think the value 2 is unimportant here.

642

using the ... -> when the abbrev code is specified to be lower than the first abbrev.

652–660

There's a bit of tension here between the AbbrOffset and the behaviour. Since the AbbrOffset should point to the start of the table containing the corresponding abbrevs, it's a little unclear what the behaviour should be if the offset is nonsensical. It also prevents us having multiple abbrev tables as it stands.

I think it's okay to add this test case for now, but I might suggest a change for the future, to split the abbrev section into distinct tables which can be referenced by some ID from the .debug_info. Different .debug_info tables can refer to the same or different abbrev tables that way. The offset would be auto-calculated to match, but could be overridden to a different value (the ID could still be used to actually identify how to write the values).

grimar added inline comments.Jun 19 2020, 3:55 AM
llvm/lib/ObjectYAML/DWARFVisitor.cpp
60

Doesn't seem this assert is helpful. AbbrevDecls is std::vector<Abbrev>,
Most (or all) of STL implementations check the out of bounds access internally I think.

Probably you should add a test case and do the following for now:

if (AbbrCode > DebugInfo.AbbrevDecls.size())
  report_fatal_error(...)
61

Since you are touching this line, could you convert the auto to an actual type?

Higuoxing updated this revision to Diff 272038.Jun 19 2020, 6:03 AM
Higuoxing marked 7 inline comments as done.

Address comments.

llvm/lib/ObjectYAML/DWARFVisitor.cpp
60

Sorry, I haven't tested a report_fatal_error() before. What will be checked? The dumped stack trace? or something else? Can I leave a "TODO" here and let this function return Error in a follow-up patch?

llvm/test/tools/yaml2obj/ELF/DWARF/debug-info.yaml
652–660

I think it's okay to add this test case for now, but I might suggest a change for the future, to split the abbrev section into distinct tables which can be referenced by some ID from the .debug_info. Different .debug_info tables can refer to the same or different abbrev tables that way. The offset would be auto-calculated to match, but could be overridden to a different value (the ID could still be used to actually identify how to write the values).

Yeah, the current implementation of the .debug_abbrev section doesn't support multiple tables. I deleted this test. I will it once generating multiple abbreviation tables is supported.

jhenderson accepted this revision.Jun 19 2020, 7:09 AM

LGTM.

llvm/lib/ObjectYAML/DWARFVisitor.cpp
60

Typically, you wouldn't test a report_fatal_error as it shouldn't be possible to reach that bit of code. It's like an assert, but works without asserts being enabled too.

This revision is now accepted and ready to land.Jun 19 2020, 7:09 AM
grimar added inline comments.Jun 19 2020, 7:43 AM
llvm/lib/ObjectYAML/DWARFVisitor.cpp
60

What will be checked? The dumped stack trace? or something else?

Just the fact of crash of the test case. In the follow-up you could fix the crash then.
It should be possible to check that crash with --crash option for not:

RUN: llvm-mc -filetype=obj -triple aarch64-windows %s -o - \
RUN: | not --crash llvm-readobj --unwind - 2>&1 | FileCheck %s

I do not mind leaving the test case for a follow-up. It was just important not to use an assert here.
report_fatal_error calls abort().

Higuoxing updated this revision to Diff 272298.Jun 21 2020, 2:41 AM
Higuoxing marked 2 inline comments as done.

Address comment.

llvm/lib/ObjectYAML/DWARFVisitor.cpp
60

Thanks! I added one more test case for it :-)

jhenderson accepted this revision.Jun 22 2020, 1:41 AM

LGTM, thanks.

llvm/lib/ObjectYAML/DWARFVisitor.cpp
60

I'd change "Report" to "Handle", since the error is now being reported (although not in the best way).

jhenderson added inline comments.Jun 22 2020, 1:45 AM
llvm/lib/ObjectYAML/DWARFVisitor.cpp
61

Should this message be "... less than or equal to ..."?

Higuoxing updated this revision to Diff 272354.Jun 22 2020, 2:26 AM
Higuoxing marked 2 inline comments as done.

Address review comments.

jhenderson accepted this revision.Jun 22 2020, 2:53 AM
This revision was automatically updated to reflect the committed changes.