[llvm] Solve llvm-dwp overflow problem, skipped over 4GB '.dwo' files (PR #71902)

Jinjie Huang via llvm-commits llvm-commits at lists.llvm.org
Sun Nov 12 22:41:46 PST 2023


Labman-001 wrote:

> The whole point of the ContinueOnCuIndexOverflow is to continue(& allow tools like llvm-dwarfdump and lldb to continue with this corrupted index by reconstructing the .debug_info column in the DWP despite the overflow, by parsing the .debug_info section to find the boundary points/rebuild that column in the index) so this patch wouldn't be compatible with that goal.

I see. But according to my current test result, gdb(10.1) can't recognise '.dwp' files emitted after the debug_info section exceeds 4GB, and gdb reports an error about the dwarf version.I'm not sure if it's because GDB10.1 can't rebuild the correct column. But it looks like there's a problem with processing the dwarf header, which makes debugging completely impossible.

I'm wondering if it's better to change the logic of 'ContinueOnCuIndexOverflow' in this case, or if it's better for me to add a   extra flag like 'ContinueWithBestEffort'.

And in the part shown below, when there is an overflow problem, it will just RETURN, rather than continue emitting, which seems like a wrong way to do it?
<img width="1498" alt="image" src="https://github.com/llvm/llvm-project/assets/150100070/549b7a24-aef4-47a5-8928-398b72ff8f97">




https://github.com/llvm/llvm-project/pull/71902


More information about the llvm-commits mailing list