[Bug debugedit/33789] debugedit corrupts RISC-V object files

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=33789

Mark Wielaard <mark at klomp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at sourceware dot org   |mark at klomp dot org

--- Comment #8 from Mark Wielaard <mark at klomp dot org> ---
Thanks for the binary and patch idea of updating the symtab symbol values after
the .debug_str and .debug_line_str are updated for symbols that point into
those pools.

But I have to check why that works.

On every other architecture the symbol used for debug section relocation is the
zero/section symbol. So they have very few local symbols, basically none
for/inside the .debug_str or .debug_line_str section.

On other arches we only have to update the relocation addend.
Here, with the patch, we would update both.

It would be good to figure out why we are getting all these local symbols
inside the .debug_str and .debug_line_str. It looks very inefficient. You seem
to have a symbol and a relocation for each string. Which seems to explain why
all relocations have an addend of zero.

So on x86_64 you would have:

Relocation section [26] '.rela.debug_line' for section [25] '.debug_line' at
offset 0x96f18 contains 52 entries:
  Offset              Type            Value               Addend Name
  0x0000000000000022  X86_64_32       000000000000000000     +47
.debug_line_str
  0x0000000000000026  X86_64_32       000000000000000000     +76
.debug_line_str
  0x000000000000002a  X86_64_32       000000000000000000     +82
.debug_line_str
  0x000000000000002e  X86_64_32       000000000000000000     +95
.debug_line_str

Relocation section [17] '.rela.debug_line' for section [16] '.debug_line' at
offset 0x31d48 contains 375 entries:
  Offset              Type            Value               Addend Name
  0x0000000000000022  RISCV_32        0x0000000000000169      +0 .LASF1
  0x0000000000000026  RISCV_32        0x000000000000000b      +0 .LASF1650
  0x000000000000002a  RISCV_32        0x000000000000019d      +0 .LASF1651
  0x000000000000002e  RISCV_32        0x000000000000007d      +0 .LASF1652

Note how all relocations on x86_64 use the same "symbol" with Value zero, and
the relocation addend is the actual offset into the debug string table.

But on riscv each relocation has a different symbol with a value that is the
offset into the debug string table, and all the Addends are zero.

The result is a much larger symtabs.

And debugedit doing the wrong thing since it assumed only the relocation added,
and not the symbol value, needs adjusting.

It definitely seems a bug in debugedit and I'll try to fix it, Maybe by adding
a symtab update pass or maybe we can do it while updating the relocations (if
we adjust the symbols we shouldn't also update the addends).

But it would also be good if someone looked into why riscv creates these
relocation/symbol pairs for debug string tables. It seems it would be more
efficient to do like other arches and just have one symbol at the start of the
section against which you relocate.

-- 
You are receiving this mail because:
You are on the CC list for the bug.