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.maude...@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.
