This is an archive of the discontinued LLVM Phabricator instance.

[DWARF] NFC: Combine relocs with DataExtractor
ClosedPublic

Authored by probinson on Jun 27 2017, 1:27 PM.

Details

Summary

Require callers to directly associate relocations with a DataExtractor used to read data from a DWARF section, which helps a callee not make assumptions about which section it is reading.
This is the next step in reducing DWARFFormValue's dependence on DWARFUnit.

Diff Detail

Event Timeline

probinson created this revision.Jun 27 2017, 1:27 PM
dblaikie added inline comments.Jun 27 2017, 2:12 PM
include/llvm/DebugInfo/DWARF/DWARFDataExtractor.h
18

Thanks for pulling these little classes out into their own headers - it does really help readability, I think/agree!

18–26

What about composition rather than inheritance? (basically a pair of DataExtractor and RelocMap - if I recall correctly, that's how it's stored in the DWARFContext? (ah, not quite - it's the DWARFSection which is only StringRef + RelocAddrMap))

If the plan is to add more utility functions to encapsulate the use of the RelocAddrMap with the DataExtractor (especially if that could be done to the point of hiding the RelocAddrMap entirely (removing getRelocMap) from users of the DWARFDataExtractor) I could see this being a good direction.

lib/DebugInfo/DWARF/DWARFAcceleratorTable.cpp
124–125

Maybe a wrapper for getRelocatedValue that takes a DWARFDataExtractor? Or maybe that could be a member function of DWARFDataExtractor? (would that allow DWARFDataExtractor to do without getRelocMap entirely?)

lib/DebugInfo/DWARF/DWARFContext.cpp
78–79

Looks like DWARFDataExtractor could use a ctor that takes a DWARFSection? Does it need other ctors? (worst case callers could pass {Data, Relocs} even if they didn't already have a DWARFSection on hand)

595

If the RelocMap is passed through the DWARFDataExtractor, does DWARDebugLine even need to have a RelocMap passed into the ctor/as a member?

It's a bit weird that this DWARFDataExtractor uses the relocmap from the Line section from the DWARFContext but has to access a line section that's specific to this DWARFUnit. Is that right? I guess the DWARFUnit's LineSection is the sub-range of the full section that is the line table for the unit - wouldn't this make the offsets incorrect for looking up things in the reloc map maybe? (since they're relative to the whole line section, I would think)

probinson added inline comments.Jun 28 2017, 8:31 AM
include/llvm/DebugInfo/DWARF/DWARFDataExtractor.h
18

You're welcome! I didn't do that with DWARFFormParams because it seemed too tightly connected to DWARFFormValue, but in general I see the DebugInfo headers split up that way and it makes sense.

18–26

The is-a versus has-a relationship is certainly arguable here. IMO is-a has a stronger case, as I do want to replace most (ideally all) uses of getRelocatedValue with a member function here, allowing us to hide the RelocMap. In that sense, DWARFDataExtractor is extending DataExtractor (to handle relocated values) rather than using DataExtractor.
I could do the getRelocatedValue member function in this patch if you like but I was thinking to do it separately.

lib/DebugInfo/DWARF/DWARFAcceleratorTable.cpp
124–125

That's the plan.

lib/DebugInfo/DWARF/DWARFContext.cpp
78–79

I'll look at that. Sometimes the reloc map is nullptr I think, e.g. in .dwo situations.

595

Several questions there.
I hadn't noticed but yes the relocmap passed to the DWARFDebugLine ctor is now redundant. Previously it was used only to resolve address references in DW_LNE_set_address.
Line->getRelocMap() is retrieving that relocmap, which was set just a moment ago by construction of DWARFDebugLine, passing in getLineSection.Relocs(), so it's all the same relocmap. That can be more obvious (especially if the separate data member in DWARFDebugLine is removed).
The base offset for this unit's line table is passed separately to get[OrParse]LineTable, so the extractor correctly has a reference to the entire section, and lookups in the relocmap DTRT.

dblaikie added inline comments.Jun 28 2017, 3:22 PM
include/llvm/DebugInfo/DWARF/DWARFDataExtractor.h
18–26

Separately or together is fine - just wanted to check on the direction.

lib/DebugInfo/DWARF/DWARFContext.cpp
595

Are you planning changes to address these in this patch/should I wait to review them?

probinson updated this revision to Diff 104549.Jun 28 2017, 5:03 PM

Removed RelocAddrMap members from DWARFDebugLine and DWARFDebugLoc.
DWARFDataExtractor ctors accept either a DWARFSection (can have relocations) or StringRef (no relocations).
Replace more DataExtractor parameters with DWARFDataExtractor.
Replace free function getRelocatedValue() with equivalent methods on DWARFDataExtractor.
DWARFUnit's LineSection changed from StringRef to DWARFSection, to make it harder to mess up the relocations to use with it.

dblaikie accepted this revision.Jun 28 2017, 7:27 PM
dblaikie added inline comments.
include/llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h
48–50

Most other places seem to be passing DWARFDataExtractor by const ref rather than by value. Pick one? Or is there something I'm missing that motivates the difference?

include/llvm/DebugInfo/DWARF/DWARFDataExtractor.h
33

Could use a non-static data member initializer to initializer RelocMap to null & omit it from the init list here, if you like.

include/llvm/DebugInfo/DWARF/DWARFDebugLine.h
30

Drop this if it's the default/implicit

include/llvm/DebugInfo/DWARF/DWARFUnit.h
199–202

Was the original code incorrect here? (since it wasn't using relocs for whoever was calling it previously? Or have those callers been using getRelocated* and have been migrated by this change?)

This revision is now accepted and ready to land.Jun 28 2017, 7:27 PM
probinson marked 4 inline comments as done.Jun 29 2017, 8:28 AM

Thanks for taking time with this!

include/llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h
48–50

No, just missed one place.

include/llvm/DebugInfo/DWARF/DWARFUnit.h
199–202

The latter. In fact before I did this, I had tripped over a case where I incorrectly attached the .debug_line relocations to a use of .debug_line.dwo, and this turned out to be a good refactoring to avoid that kind of mistake.

probinson marked an inline comment as done.Jun 29 2017, 8:36 AM
probinson added inline comments.
include/llvm/DebugInfo/DWARF/DWARFUnit.h
199–202

Duh, not .debug_line.dwo, but .debug_types.dwo got relocations incorrectly. Anyway, commit coming as soon as the test run finishes.

This revision was automatically updated to reflect the committed changes.