Added support for DWARF5 Split Dwarf.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Probably worth changing the == 5 version checks to >= 5 since most things stay the same between DWARF versions, and the things that don't are the exceptions/things we'll need to touch on the next version (& nice to not have to touch/update code for things that stay the same)
bolt/include/bolt/Core/DebugData.h | ||
---|---|---|
376–378 | That seems like a somewhat problematic API - returning two very different kinds of data (the DWO_ID or the unit offset) seems quite easy to misuse this? | |
387 | Probably name the parameter the same as the member, rather than one character different/lower case. | |
bolt/lib/Rewrite/DWARFRewriter.cpp | ||
210–212 | Probably an uppercase V since that's a separate word within the name? | |
308 | ||
322 | reinterpret_cast seems a bit scary here - perhaps TempRangesSectionWriter should be a void* if it could be a pointer to two unrelated types (if it's a pointer to a base class that covers both ranges and rnglists, then a static_cast should suffice for the downcasting from base pointer to derived pointer) | |
329–331 | to avoid two lookups (one for count, the other for op[]) perhaps this code should use find? |
Comments from @maksfb
bolt/include/bolt/Core/DebugData.h | ||
---|---|---|
220 | delete | |
231 | make reference | |
348 | add documentation. | |
387 | Pass BC by reference | |
400 | isFinalized | |
403 | releaseBuffer() | |
bolt/lib/Core/DebugData.cpp | ||
210 | const | |
358–359 | const | |
415–417 | AM --> AMIter | |
484–486 | const | |
1062 | remove method, move to constructor | |
1073 | const | |
1075 | Darf --> Dwarf | |
1079 | use static_cast | |
1097 | remove curly braces | |
bolt/lib/Rewrite/DWARFRewriter.cpp | ||
168 | const Unit, AttrInfoVal | |
170 | const | |
210–211 | const DwarfVersion | |
306 | add else if for DWARF < 5 else case llvm_unreachable | |
324 | make finalizeSection virtual and do nothing for dwarf4. | |
337–338 | Make initSection virtual and do nothing for DWARF4 | |
1178 | ||
1722 | const | |
bolt/test/X86/dwarf4-df-dualcu.test | ||
24 | dwarf4 |
bolt/include/bolt/Core/DebugData.h | ||
---|---|---|
376–378 | The idea I had behind this APIS is for it to return unique ID representing the CU. As it applies to .debug_addr. For monolithic case is its offset with .debug_info for Split Dwarf case is its DWO ID. At least in my head viewed in that context the return data is the same. It's just something that uniquely identifies this CU, and logic is encapsulated in it. |
bolt/include/bolt/Core/DebugData.h | ||
---|---|---|
376–378 | Could you use the offset consistently? The debug_addr section is always in the executable - the offset of the skeleton CU would be unique? |
bolt/include/bolt/Core/DebugData.h | ||
---|---|---|
376–378 | In theory yes, if I always use offset of the CU/Skeleton CU in the main binary. For that I still need to do a check of CU that is passed in is DWO CU, get it skeleton CU, then get it's offset. At the end what we get is offset all the time. Is it really better? Sure we always getting an offset, but intent of this API is not really get an offset but the unique ID of the CU. Are you concern that offset and DWO ID will collide? |
delete