In the case of LTO, several DWARF units can be emitted in one section. For an extremely large application, they may exceed the limit of 4GiB for 32-bit offsets. As it is now possible to emit 64-bit debugging info, the patch enables storing the larger offsets.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Looks OK - open to discussion on the assert/report_fatal_error issue.
llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp | ||
---|---|---|
594–601 | These might be report_fatal_error-worthy? (if there's ways to fail the build more nicely (without fatally stopping the program) that'd be nice - not sure how other attempts to try to use the AsmPrinter when the use is invalid fail/whether they can fail gracefully) |
llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp | ||
---|---|---|
594–601 | My personal thoughts:
|
- Added reporting a fatal error if the generated debug info exceeds the limits supported by the format.
llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp | ||
---|---|---|
594–601 | In the update, I am adding reporting a fatal error in DwarfFile::computeSizeAndOffsets(), where the offsets for DWARF units are calculated and set. As DWARF64 is not supported for Apple targets, these asserts are now not expected to be hit with the normal usage. |
llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp | ||
---|---|---|
594–601 | By "not supported" you mean "has no guarantees if you ask for it" or do you mean "will produce an error early telling the user this isn't valid/supported" & thus this assert should (assuming no other programmer bugs - but importantly /not/ assuming some well intentioned user - a user can ask for an invalid thing and should get an error, not an assert failure/crash) ? |
llvm/lib/CodeGen/AsmPrinter/AccelTable.cpp | ||
---|---|---|
594–601 | I mean that DWARF64 is not enabled for anything except ELF (see D87011), while computeAccelTableKind() returns AccelTableKind::Apple only if TT.isOSBinFormatMachO(), or if an internal tool is called with -accel-tables=Apple switch. The Apple accelerator tables are emitted only if getAccelTableKind() returns AccelTableKind::Apple, thus I cannot see a way for an end-user to trigger emitting those tables when DWARF64 is on. And if DWARF64 is off, and the debug data is extremely big, an error will be reported in DwarfFile::computeSizeAndOffsets(). |
These might be report_fatal_error-worthy? (if there's ways to fail the build more nicely (without fatally stopping the program) that'd be nice - not sure how other attempts to try to use the AsmPrinter when the use is invalid fail/whether they can fail gracefully)