[Bug ld/29852] New: segmentation fault in ld when using --just-sybols option with some executables

[address@hidden]

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

            Bug ID: 29852
           Summary: segmentation fault in ld when using --just-sybols
                    option with some executables
           Product: binutils
           Version: 2.40 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: christian.mauderer@embedded-brains.de
  Target Milestone: ---

Created attachment 14482
  --> https://sourceware.org/bugzilla/attachment.cgi?id=14482&action=edit
Executables and linker calls to cause the ld SegFault.

Hello,

short form: I have two exe files and an object file attached. I want to
resolve some symbols in the object using references from the executables. With
one it works. The other causes a segfault in ld in cmse_scan in
bfd/elf32-arm.c.
Both executables contain the symbols but one is build with a newlib option that
(most likely beneath other effects) adds a few sections to the executable and
moves some symbols into different sections.

Long form with some background:

I'm working on updating an RTEMS (embedded operating system) application to the
latest version. In the latest RTEMS version, newlib is compiled with
--enable-newlib-reent-thread-local which (beneath other effects) adds a few
sections to the executables.

In the application I'm working on, we create a firmware update image. For that,
one step is to use a small C file with only a definition of a structure to
create a header for the image. To fill in information like start and end of the
flash area or the entry point, we use the -R (--just-symbols) option of ld with
the real application as a reference. That worked well in the past. But since
the
new option is added to RTEMS newlib, ld crashes with a segmentation fault.

I attached an archive with a stripped down sample of an application executable
build right before and after the change in RTEMS as well as a c and an object
file with the structure. The archive also contains a "script.sh" that shows how
the header would be compiled and the following two ld calls:

  + arm-rtems6-ld -e bin_img_image_header -R hello_good.exe header.o -o
image_good.exe
  + arm-rtems6-ld -e bin_img_image_header -R hello_bad.exe header.o -o
image_bad.exe
  ./script.sh: line 5: 10836 Segmentation fault      (core dumped)

The segmentation fault happens in the cmse_scan function. If I start ld in gdb
I
get the following backtrace (paths a bit shortened to make it better readable):

  Program received signal SIGSEGV, Segmentation fault.
  cmse_scan (cmse_stub_created=<synthetic pointer>, sym_hashes=0x5c7800,
out_attr=0x5a75c8, htab=0x5a9230, input_bfd=0x5bf9f0) at
/.../binutils-gdb/bfd/elf32-arm.c:6011
  6011              sym_name = (char *) cmse_hash->root.root.root.string;
  (gdb) bt
  #0  cmse_scan (cmse_stub_created=<synthetic pointer>, sym_hashes=0x5c7800,
out_attr=0x5a75c8,
      htab=0x5a9230, input_bfd=0x5bf9f0)
      at /.../binutils-gdb/bfd/elf32-arm.c:6011
  #1  elf32_arm_size_stubs (output_bfd=0x5a70d0, stub_bfd=<optimized out>,
info=0x583880 <link_info>,
      group_size=<optimized out>,
      add_stub_section=add_stub_section@entry=0x425ed0
<elf32_arm_add_stub_section>,
      layout_sections_again=layout_sections_again@entry=0x425de0
<gldarm_layout_sections_again>)
      at /.../binutils-gdb/bfd/elf32-arm.c:6542
  #2  0x0000000000425d73 in gldarmelf_after_allocation () at earmelf.c:433
  #3  0x00000000004177cd in lang_process ()
      at /.../binutils-gdb/ld/ldlang.c:8157
  #4  0x0000000000404ed2 in main (argc=<optimized out>, argv=<optimized out>)
      at /.../binutils-gdb/ld/ldmain.c:497
  (gdb)

The line numbers in the backtrace belong to
git://sourceware.org/git/binutils-gdb.git revision 942fa4fb32738. The
problematic lines are the following two:

  6010       cmse_hash = elf32_arm_hash_entry (sym_hashes[i - ext_start]);
  6011       sym_name = (char *) cmse_hash->root.root.root.string;

cmse_hash is a pointer to 0x0 in this case which causes a crash in the second
line. sym_hashes[i-ext_start-1] would still contain a valid value. So it seems
that for some reason the end of the array isn't detected correctly. But I don't
know the elf format well enough to find the bug. Any ideas?

Note: The executables have been build with the default version of the tools
provided by RTEMS. The linker used in this call is build from
git://sourceware.org/git/binutils-gdb.git revision 942fa4fb32738 build with the
options from the attached "binutils.sh" script. I tried different versions both
for building RTEMS and linking this header but it doesn't seem to make a
difference.

Best regards

Christian

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