[Bug 204084] libdwarf does not handle SHT_REL relocations properly

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Oct 28 06:17:32 UTC 2015


            Bug ID: 204084
           Summary: libdwarf does not handle SHT_REL relocations properly
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: arm
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: standards
          Assignee: freebsd-standards at FreeBSD.org
          Reporter: hackagadget at gmail.com

Created attachment 162523
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=162523&action=edit
Sample object file with bogus .SUNW_ctf due to SHT_REL mishandling

When using dtrace on ARM and I tracked it down to what I think is an issue in
libdwarf and how it is handling relocations.

>From what I've been able to tell from reading various specifications and other
documents, relocations of the DWARF sections are supposed to be handled as
1. Given the following:
   P is the address we want to do relocations on
   S is the value of the symbol referenced in the relocation entry
   A is the addendum in the relocation entry
2. For SHT_RELA type, we need to take S, add A, then store the resulting value
at the location P
3. For SHT_REL type, we need to take the value at the location P, add S, then
store the resulting value at the location P

>From what I was able to read in the libdwarf code
(contrib/elftoolchain/libdwarf/libdwarf_elf_init.c), it looks like SHT_RELA
type is handled correctly. However, for SHT_REL type, there seems to be a
missing step. It looks like it is just taking S and storing that at the
location P, which ends up clobbering the value that was already at the location

This ends up being a disaster for ctfconvert, as you end up with very few to no
actual symbols in that binary able to be used in probe statements.

See the attached arc4random.o file. This was built with the clang 3.5.1 for
ARM. You should be able to use ctfdump on it to see the bogus .SUNW_ctf section
data generated by ctfconvert as the code currently exists (with the flawed REL
relocation handling.)

You are receiving this mail because:
You are the assignee for the bug.

More information about the freebsd-standards mailing list