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.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
include/llvm/DebugInfo/DWARF/DWARFDataExtractor.h | ||
---|---|---|
18 ↗ | (On Diff #104245) | Thanks for pulling these little classes out into their own headers - it does really help readability, I think/agree! |
18–26 ↗ | (On Diff #104245) | 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 ↗ | (On Diff #104245) | 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 ↗ | (On Diff #104245) | 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 ↗ | (On Diff #104245) | 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) |
include/llvm/DebugInfo/DWARF/DWARFDataExtractor.h | ||
---|---|---|
18 ↗ | (On Diff #104245) | 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 ↗ | (On Diff #104245) | 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. |
lib/DebugInfo/DWARF/DWARFAcceleratorTable.cpp | ||
124–125 ↗ | (On Diff #104245) | That's the plan. |
lib/DebugInfo/DWARF/DWARFContext.cpp | ||
78–79 ↗ | (On Diff #104245) | I'll look at that. Sometimes the reloc map is nullptr I think, e.g. in .dwo situations. |
595 ↗ | (On Diff #104245) | Several questions there. |
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.
include/llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h | ||
---|---|---|
48 ↗ | (On Diff #104549) | 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 | ||
32 ↗ | (On Diff #104549) | 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 | ||
29 ↗ | (On Diff #104549) | Drop this if it's the default/implicit |
include/llvm/DebugInfo/DWARF/DWARFUnit.h | ||
200–203 ↗ | (On Diff #104549) | 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?) |
Thanks for taking time with this!
include/llvm/DebugInfo/DWARF/DWARFAcceleratorTable.h | ||
---|---|---|
48 ↗ | (On Diff #104549) | No, just missed one place. |
include/llvm/DebugInfo/DWARF/DWARFUnit.h | ||
200–203 ↗ | (On Diff #104549) | 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. |
include/llvm/DebugInfo/DWARF/DWARFUnit.h | ||
---|---|---|
200–203 ↗ | (On Diff #104549) | Duh, not .debug_line.dwo, but .debug_types.dwo got relocations incorrectly. Anyway, commit coming as soon as the test run finishes. |