bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/22875] New: Strip complains about and then destroys unreco


From: nickc at redhat dot com
Subject: [Bug binutils/22875] New: Strip complains about and then destroys unrecognised relocs
Date: Thu, 22 Feb 2018 13:07:15 +0000

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

            Bug ID: 22875
           Summary: Strip complains about and then destroys unrecognised
                    relocs
           Product: binutils
           Version: 2.31 (HEAD)
            Status: NEW
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: nickc at redhat dot com
  Target Milestone: ---

Hi Guys,

If strip encounters a relocation that it does not recognise, it issues a
warning message, and then proceeds to replace the relocation with a null
version.  It then completes successfully, even though it has now produced a
corrupt binary.

For example, consider this test:

  % cat unknown-reloc.s
        .text
  foo:
        .dc.l    0x12345678

        .section .rela.text
        .dc.l    0
        .dc.l    0
        .dc.l    0x12345678
        .dc.l    0

        .dc.l    0
        .dc.l    0
        .dc.l    0
        .dc.l    0

  % as unknown-reloc.s -o unknown-reloc.o

  % readelf -r unknown-reloc.o
  Relocation section '.rela.text' at offset 0x44 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name +
Addend
  000000000000  000012345678 unrecognized: 12345678                    0

  % strip -g unknown-reloc.o
  strip: bad-reloc.o: invalid relocation type 120

  % echo $?
  0

  % readelf -r unknown-reloc.o
  Relocation section '.rela.text' at offset 0xc8 contains 1 entries:
  Offset          Info           Type           Sym. Value    Sym. Name +
Addend
  000000000000  000000000000 R_X86_64_NONE                        0

This is not just a theoretical problem.  We (Red Hat) recently had a user
report
that they were seeing corrupt binaries, and the problem turned out to be that
they were compiling using a toolchain with a 2.28 assembler that produced 
R_X86_64_REX_GOTPCRELX relocations, but using a version of strip that came from
the 2.25 binutils release.

There are at least two bugs here:

  * strip should not replace relocations that it does not recognise.
  * strip should either accept and ignore unknown relocations, or, if
   it must, complain about them, leave the input alone, and return an
   exit failure status.

I am filing this bug as a reminder to myself to investigate and fix the
problems.  That is unless somebody else does it first... :-)

Cheers
  Nick

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]