Bug 11675 - -- oformat binary or srec broken
Summary: -- oformat binary or srec broken
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.21
: P1 critical
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-07 22:22 UTC by Vincent Rivière
Modified: 2015-02-17 02:14 UTC (History)
2 users (show)

See Also:
Host:
Target: m68k-elf
Build:
Last reconfirmed:


Attachments
Issue an error if an attempt is made to change the output format whilst linking m68k-elf binaries (546 bytes, patch)
2010-06-21 10:11 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Vincent Rivière 2010-06-07 22:22:57 UTC
Linking any object using --oformat binary or srec fails with a Segmentation 
fault.
It fails in bfd/elf32-m68k.c:4757, function bfd_elf_m68k_set_target_options()
      /* --got=single.  */
      htab->local_gp_p = FALSE; // <-- here

This causes the ld-srec tests to fail.
Comment 1 Nick Clifton 2010-06-16 16:18:30 UTC
Hi Vincent,

  I am unable to reproduce this problem.  Please could you provide a small test
case that demonstrates it ?  (Note - I did run the ld-srec tests but although
the tests failed to link there were no segmentation faults.  This was with a
m68k-elf targeted toolchain running on an i686-pc-linux-gnu host).

Cheers
  Nick
Comment 2 Vincent Rivière 2010-06-17 18:01:23 UTC
I can reproduce the bug again very easily.
My host is Cygwin, I get explicitly a Segmentation fault when linking.
Here is a very simple testcase:

$ cat a.s
        nop

$ gas/as-new a.s -o a.o

$ ld/ld-new a.o -o a --oformat srec
Segmentation fault (core dumped)

With gdb:
Program received signal SIGSEGV, Segmentation fault.
bfd_elf_m68k_set_target_options (info=0x4cb048, got_handling=0) 
at ../../binutils-CVS-20100617/bfd/elf32-m68k.c:4757
4757          htab->local_gp_p = FALSE;

I have put a trace, and I see that htab is NULL.
It comes from elf_m68k_hash_table().
Comment 3 Nick Clifton 2010-06-21 10:10:52 UTC
Hi Vincent,

  Duh - I wonder why that did not work for me when I tried.

  Anyway I can now reproduce the problem.  It is possible to fix the code in
bfd_elf_m68k_set_target_options to avoid the seg-fault, but I think that this is
the wrong approach.  Essentially the m68k-elf code in the BFD library needs some
special fields in the global info structure and these are only created if the
output format is m68k-elf.  So it is not possible to link m68k-elf binaries and
change the output format at the same time.  (This restriction is common to quite
a few linker targets).  So instead I am proposing the uploaded patch to issue an
error if an attempt is made to link m68k-elf binaries and change the output
format at the same time.  What do you think ?

Cheers
  Nick
Comment 4 Nick Clifton 2010-06-21 10:11:50 UTC
Created attachment 4854 [details]
Issue an error if an attempt is made to change the output format whilst linking m68k-elf binaries
Comment 5 Vincent Rivière 2010-06-22 18:47:03 UTC
Hello, Nick.
I don't really use the m68k-elf target myself, I discovered this bug by 
running the testsuite. I often use an a.out toolchain to produce srec binaries 
directly from .o files, it works well and it is very handy.
You suggest to link first to ELF, then use objcopy to convert the executable 
to binary. I have not enough background with the binutils to say if it is an 
acceptable solution or not.
Anyway, this bug seems to be a recent regression in the current binutils, I 
have an old toolchain of binutils 2.19.1 for ELF and it works well.
Comment 6 Tom Rix 2015-02-17 02:14:53 UTC
This is fixed in top of tree 67ca0b7662419d76375773e0e8aba545d0c43e34

This is the change that fixed the problem

commit b1345da313436ded1bc8328b21a283dc4d65a9a4
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date:   Fri Aug 20 21:06:30 2010 +0000

        * elf32-m68k.c (bfd_elf_m68k_set_target_options): Don't set GOT
        options unless an m68k hash table has been found.

The problem was reproduced on the change immediately before this change.
0982e15774ff2baa92f4d595266eb29c154a8037