To reproduce this bug you need to compile binutils with -fsanitize=undefined # echo "int main () { return 0; }" > test.c # cc test.c -o test /tmp/portage/sys-devel/binutils-2.28/work/binutils-2.28/bfd/elflink.c:124:12: runtime error: member access within null pointer of type 'struct elf_link_hash_entry' /tmp/portage/sys-devel/binutils-2.28/work/binutils-2.28/bfd/elflink.c:11979:58: runtime error: member access within null pointer of type 'elf_section_list' (aka 'struct elf_section_list') # gcc -v gcc version 4.9.4 (Gentoo 4.9.4 p1.0, pie-0.6.4) # ld -v GNU ld (Gentoo 2.28 p1.0) 2.28
Hi Agostino, > To reproduce this bug you need to compile binutils with -fsanitize=undefined > # echo "int main () { return 0; }" > test.c I could not reproduce this problem on my local machine. Please could you tell us: a. For which architecture(s) did you encounter the problem ? b. What was the full linker command line that was in use ? It would also help a lot if you could upload the compiled test.o file so that we can be sure that we are testing the same binary. The implication of these null pointer dereferences is that a non-ELF format file was involved in the link somehow. Is this a possibility ? Cheers Nick
Hi Nick, (In reply to Nick Clifton from comment #1) > a. For which architecture(s) did you encounter the problem ? x86_64 > b. What was the full linker command line that was in use ? Where do I need to add verbosity? Can you specify? > It would also help a lot if you could upload the compiled test.o file so that > we can be sure that we are testing the same binary. I can, sure > The implication of these null pointer dereferences is that a non-ELF format > file was involved in the link somehow. Is this a possibility ? I guess so....
Hi Agostino, > > b. What was the full linker command line that was in use ? > Where do I need to add verbosity? Can you specify? To the cc command line, ie: cc -v test.c -o test If you add the --save-temps option this will also leave the test.o file around for you to upload as well. Cheers Nick
Created attachment 9965 [details] cc --save-temps -v test.c -o test
Created attachment 9966 [details] test.o
The current output is about the current git version of binutils. So the problem is reproducible with both 2.28 and master.
Created attachment 9967 [details] Proposed patch Hi Agostino, Unfortunately even with the test.o file and the linker command line I still cannot reproduce the failure. :-( I can however guess at the problems, so I have uploaded a possible patch. Please can you try it out and let me know if it works for you. Cheers Nick
(In reply to Nick Clifton from comment #7) > Unfortunately even with the test.o file and the linker command line I still > cannot reproduce the failure. :-( I need to admit that I missed to say that binutils was compiled with clang-4. Can you give it a try? Agostino
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ad32986fdf9da1c8748e47b8b45100398223dba8 commit ad32986fdf9da1c8748e47b8b45100398223dba8 Author: Nick Clifton <nickc@redhat.com> Date: Tue Apr 4 11:23:36 2017 +0100 Fix null pointer dereferences when using a link built with clang. PR binutils/21342 * elflink.c (_bfd_elf_define_linkage_sym): Prevent null pointer dereference. (bfd_elf_final_link): Only initialize the extended symbol index section if there are extended symbol tables to list.
Hi Agostino, > I need to admit that I missed to say that binutils was compiled with > clang-4. Can you give it a try? Sadly no. Fedora 25 only has clang-3.9, at that is unable to compile with sanitization enabled. (Because of some silly library problem). But, I was able to compile the binutils with clang-5, and that did indeed trigger the problem that you reported. Fortunately this also meant that I was able to test my proposed patch and find that it worked. So the patch is in and the bug is closed. :-) Cheers Nick
*** Bug 23143 has been marked as a duplicate of this bug. ***
Ignore last comment, I typoed the bug number