[PATCH] D146852: [DWARF][GDB INDEX] Fix to deal with constant pool de-dupliation Summary:

Mon Mar 27 09:54:12 PDT 2023

ayermolo added a comment.

In D146852#4221678 <https://reviews.llvm.org/D146852#4221678>, @dblaikie wrote:

> Hmm, the way we're reading this doesn't seem like it /quite/ makes sense - we read the offsets that are encoded in the "symbol table" but then we read the constant pool CU vectors directly based on the number of unique offsets in the symbol table.
>
> Perhaps we should be reading at the offsets specified by the symbol table instead of reading one after the other - maybe at some later date the format changes and other data is stored there, etc?
>
> Seems like `CUIndeces` should more accurately be called be called `CUOffsets`? & perhaps we could sort that (or maybe use a sorted set?) and walk the offsets in order and read at those offset locations?
>
> (as for testing - how's the exsiting functionality tested? I guess it's not tested by running lld (since llvm-dwarfdump testing shouldn't depend on lld) so there's probably a checked in binary with a gdb index, or maybe assembly file that can be assembled into an object file with a gdb index in it? But something like that should be done for this test too - if you wanted' you could also add a test in cross-project-tests that runs gdb itself to generate the index - but that might be a bit brittle depending on what gdb version is installed on the test machine, etc)

Originally I just found tests that used LLD, but found one that was using binary: dwarfdump-dump-gdbindex.test
So there is precedence.

Poking around previously I found lld/test/ELF/gdb-index.s which does use LLD.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D146852/new/

https://reviews.llvm.org/D146852