This is an archive of the discontinued LLVM Phabricator instance.

[DWARF] [NFC] Move a couple of member functions to DWARFUnit (baseclass) from DWARFCompileUnit (derived class)
ClosedPublic

Authored by wolfgangp on Jun 28 2017, 10:27 AM.

Details

Summary

Moving member functions addSectionDelta() and addSectionLabel() into DWARFUnit, which is the base class for DWARFCompileUnit and DWARFTypeUnit. This is to prepare for generating DWARF v5 string offsets tables. We need those 2 functions in both DWARFCompileUnit and DWARFTypeUnit. NFC.

Diff Detail

Repository
rL LLVM

Event Timeline

wolfgangp created this revision.Jun 28 2017, 10:27 AM
dblaikie edited edge metadata.Jun 28 2017, 10:46 AM

This is for DW_AT_str_offsets_base in a type unit?

Is the delta version needed? (is that modifying the existing use in split DWARF to now require a tag for str_offsets_base when none was needed before) Or only the addSectionLabel?

This is for DW_AT_str_offsets_base in a type unit?

Yes.

Is the delta version needed? (is that modifying the existing use in split DWARF to now require a tag for str_offsets_base when none was needed before) Or only the addSectionLabel?

The delta version avoids generating relocations, which we can't have for split DWARF, so for version >=5 the plan is to generate the str_offsets_base tag using addSectionLabel() for when we can use relocations and addSectionDelta() for when we can't (such as split DWARF, or Mach-O).

This is for DW_AT_str_offsets_base in a type unit?

Yes.

Is the delta version needed? (is that modifying the existing use in split DWARF to now require a tag for str_offsets_base when none was needed before) Or only the addSectionLabel?

The delta version avoids generating relocations, which we can't have for split DWARF, so for version >=5 the plan is to generate the str_offsets_base tag using addSectionLabel() for when we can use relocations and addSectionDelta() for when we can't (such as split DWARF, or Mach-O).

Right, sorry I wasn't very clear - what I was asking is: In DWARF5 do .dwo CUs have a str_offsets_base? They didn't in the pre-standard Fission that's implemented in LLVM at the moment - because the value was effectively zero always.

This is for DW_AT_str_offsets_base in a type unit?

Yes.

Is the delta version needed? (is that modifying the existing use in split DWARF to now require a tag for str_offsets_base when none was needed before) Or only the addSectionLabel?

The delta version avoids generating relocations, which we can't have for split DWARF, so for version >=5 the plan is to generate the str_offsets_base tag using addSectionLabel() for when we can use relocations and addSectionDelta() for when we can't (such as split DWARF, or Mach-O).

Right, sorry I wasn't very clear - what I was asking is: In DWARF5 do .dwo CUs have a str_offsets_base? They didn't in the pre-standard Fission that's implemented in LLVM at the moment - because the value was effectively zero always.

No you're right, my bad. Units in the .dwo sections (both type and CU) don't have a str_offsets_base, which implies that the .debug_str_offsets.dwo section has to consist of a monolithic table of string offsets (without the 8 or 16-byte header that's specified in section 7.26 of the DWARF 5 standard). Section 7.26 seems to say the opposite, though. It seems I'll have to clarify this with the DWARF5 folks.

In any case, I think the Delta is still needed for str_offsets_base (and addr_base) in file formats that don't seem to support cross section relocations (like Mach-O).

dblaikie accepted this revision.Jun 29 2017, 11:37 AM

Good point re: Mach0.

This revision is now accepted and ready to land.Jun 29 2017, 11:37 AM

No you're right, my bad. Units in the .dwo sections (both type and CU) don't have a str_offsets_base, which implies that the .debug_str_offsets.dwo section has to consist of a monolithic table of string offsets (without the 8 or 16-byte header that's specified in section 7.26 of the DWARF 5 standard). Section 7.26 seems to say the opposite, though. It seems I'll have to clarify this with the DWARF5 folks.

Worth clarifying on the dwarf-discuss list but I believe the idea is that the .dwo would have a single .debug_str_offsets.dwo contribution (complete with header), corresponding to the .debug_str.dwo contribution, and all units in the compilation would share it just like they would ordinarily share the single .debug_str section in a non-split compilation.

No you're right, my bad. Units in the .dwo sections (both type and CU) don't have a str_offsets_base, which implies that the .debug_str_offsets.dwo section has to consist of a monolithic table of string offsets (without the 8 or 16-byte header that's specified in section 7.26 of the DWARF 5 standard). Section 7.26 seems to say the opposite, though. It seems I'll have to clarify this with the DWARF5 folks.

Worth clarifying on the dwarf-discuss list but I believe the idea is that the .dwo would have a single .debug_str_offsets.dwo contribution (complete with header), corresponding to the .debug_str.dwo contribution, and all units in the compilation would share it just like they would ordinarily share the single .debug_str section in a non-split compilation.

So then given the lack of a str_offsets_base attribute in the unit DIEs the string indices in the .dwo units would have to start with 2 instead of 0 in order to ignore the header. Or else the (absent) attribute would have an implicit value of 8 (or 16 for DWARF64). Seems a bit odd.

No you're right, my bad. Units in the .dwo sections (both type and CU) don't have a str_offsets_base, which implies that the .debug_str_offsets.dwo section has to consist of a monolithic table of string offsets (without the 8 or 16-byte header that's specified in section 7.26 of the DWARF 5 standard). Section 7.26 seems to say the opposite, though. It seems I'll have to clarify this with the DWARF5 folks.

Worth clarifying on the dwarf-discuss list but I believe the idea is that the .dwo would have a single .debug_str_offsets.dwo contribution (complete with header), corresponding to the .debug_str.dwo contribution, and all units in the compilation would share it just like they would ordinarily share the single .debug_str section in a non-split compilation.

So then given the lack of a str_offsets_base attribute in the unit DIEs the string indices in the .dwo units would have to start with 2 instead of 0 in order to ignore the header. Or else the (absent) attribute would have an implicit value of 8 (or 16 for DWARF64). Seems a bit odd.

Right, the absent attribute is implicitly 8 or 16, and you need to parse the header anyway to know whether elements are 32-bit or 64-bit.

This revision was automatically updated to reflect the committed changes.