[Bug debugedit/33789] New: debugedit corrupts Risc-V object files

[nickc at redhat dot com]

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

            Bug ID: 33789
           Summary: debugedit corrupts Risc-V object files
           Product: debugedit
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: debugedit
          Assignee: unassigned at sourceware dot org
          Reporter: nickc at redhat dot com
                CC: debugedit at sourceware dot org
  Target Milestone: ---

Version 5.2 of debugedit (and version 5.1 and maybe others) appears to corrupt
some Risc-V object files.

What appears to be happening is that debugedit is changing the contents of
mergeable dwarf string sections but not correctly adjusting all of the symbols
that reference those sections.  In particular it is leaving symbols that are
placed beyond the end of the section.  This causes issues when the sections are
merged as the linker has no way to deduce the correct new location for these
symbols.  This in turn leads to relocations which reference these symbols to
misbehave, resulting in malformed DWARF debug information.

This issue is probably the cause of the problem reported in PR 33723.

In order to reproduce the issue, you need a riscv64 machine.  Speak to David
Abdurachmanov <david.abdurachmanov@gmail.com> or Kashyap Chamarthy
<kchamart@redhat.com> for assistance with this.

Once you have a machine you first need to build the tcl package.  For Fedora I
used:

  fedpkg clone tcl
  cd tcl
  fedpkg srpm
  rpm -ivh tcl*.src.rpm
  rpmbuild -bb --noclean ~/rpmbuild/SPECS/tcl.spec

I could have used "fedpkg local" I suppose, but I am more familiar with the
rpmbuild method.

Next, inspect the tclStubLib.o file in the build:

  cd ~/rpmbuild/BUILD/tcl-9.0.2-build/tcl9.0.2/unix/
  readelf --wide --sections tclStubLib.o | grep debug_line_str

   [19] .debug_line_str   PROGBITS  0000000000000000 01299d 0001dd 01  MS  0  
0  1

Note the size of the .debug_line_str section: 0x1dd bytes in this case.
Now check the location of the .LASF1 symbol:

  readelf --wide --symbols tclStubLib.o  | grep ".LASF1$"

    75: 00000000000001a3     0 NOTYPE  LOCAL  DEFAULT   19 .LASF1

Its value is 0x1a3, well inside section 19, so all is well.
Finally check the relocations that reference this symbol:

  readelf --wide --relocs  tclStubLib.o  | grep ".LASF1 "

    000000000000001b  0000004b00000001 R_RISCV_32    00000000000001a3 .LASF1 +
0
    0000000000000022  0000004b00000001 R_RISCV_32    00000000000001a3 .LASF1 +
0

These are OK too.
Now run debugedit on the file.  (I suggest making a backup of it first since
debugedit overwrites the input file).

  debugedit -b ~/rpmbuild/BUILD/tcl-9.0.2-build/tcl9.0.2 \
    -d /usr/src/debug/tcl-9.0.2-1.fc43.riscv64 \
    -l /tmp/find-debuginfo.1lDPj7/debugsources.2 \
    `pwd`/tclStubLib.o 

(I am not sure if the parameter values are significant.  They are just the ones
that are used when debugedit is invoked from inside find-debuginfo whilst
processing the libtclstub.a static archive).

Now check the .debug_line_str section:

  readelf --wide --sections tclStubLib.o | grep debug_line_str

   [19] .debug_line_str   PROGBITS   0000000000000000 023715 0001a2 01  MS  0  
0  1

It has changed size to 0x1a2.
But the .LASF1 symbol has not moved:

  readelf --wide --symbols tclStubLib.o  | grep ".LASF1$"

   75: 00000000000001a3     0 NOTYPE  LOCAL  DEFAULT   19 .LASF1

So it now references a location beyond the end of the .debug_line_str section.

And the relocations that use the .LASF1 symbol:

  readelf --wide --symbols tclStubLib.o  | grep ".LASF1$"

    000000000000001b  0000004b00000001 R_RISCV_32     00000000000001a3 .LASF1 -
2e
    0000000000000022  0000004b00000001 R_RISCV_32     00000000000001a3 .LASF1 -
2e

Now have *negative* offsets from the symbol's location.

When the tclStubLib.o object file is merged with other files the linker will
complain about "access beyond the end of a section" and the DWARF information
that relies upon those relocations will be corrupt.

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