Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 28 Oct 2015 06:17:31 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-standards@FreeBSD.org
Subject:   [Bug 204084] libdwarf does not handle SHT_REL relocations properly
Message-ID:  <bug-204084-15@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204084

            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@FreeBSD.org
          Reporter: hackagadget@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
follows:
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
P.

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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-204084-15>