Bug 6844 - Segmentation Fault using cross architecture ld command
Summary: Segmentation Fault using cross architecture ld command
Status: RESOLVED INVALID
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: 2.18
: P2 normal
Target Milestone: ---
Assignee: unassigned
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-14 22:31 UTC by John Morrison
Modified: 2008-09-16 04:35 UTC (History)
1 user (show)

See Also:
Host: i686-pc-linux-gnu
Target: powerpc-unknown-eabi
Build: i686-pc-linux-gnu
Last reconfirmed:


Attachments
This is trace information from GDB. (554 bytes, text/plain)
2008-08-14 22:34 UTC, John Morrison
Details
Full execution console listing while under GDB. (6.62 KB, text/plain)
2008-08-14 22:35 UTC, John Morrison
Details
The file created with the -M flag (52.64 KB, text/plain)
2008-08-14 22:36 UTC, John Morrison
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Morrison 2008-08-14 22:31:47 UTC
We are upgrading our cross-compiler from GCC 2.95.2, binutils 2.10.1 to GCC 
4.2.0, binutils 2.17.  Cross compiling from Linux i686 to PowerPC.  What we 
create is a statically built firmware from 1000+ modules. This "firmware" gets 
downloaded into flash on the devices we build.

We get a segmentation fault while trying to do the final "link" of our printer 
firmware, os and support libraries.  As you can guess, this all used to work 
fine in the previous versions (GCC and binutils).

I'm going to try and attach console listings to this bug report.  If I can't, 
you'll see them here.

Thanks
John Morrison
Comment 1 John Morrison 2008-08-14 22:34:31 UTC
Created attachment 2905 [details]
This is trace information from GDB.

Let me know if you want more information and how to get it for you.
Comment 2 John Morrison 2008-08-14 22:35:35 UTC
Created attachment 2906 [details]
Full execution console listing while under GDB.
Comment 3 John Morrison 2008-08-14 22:36:31 UTC
Created attachment 2907 [details]
The file created with the -M flag

Just in case you may have wanted it.
Comment 4 John Morrison 2008-08-14 22:37:35 UTC
I have not been really able to cut the execution down to a reasonale test 
size.  I wish I could.
Comment 5 John Morrison 2008-08-14 22:39:33 UTC
The GDB Console Listing attachment shows the parameters on the command call.
Comment 6 Alan Modra 2008-08-15 00:41:23 UTC
Does your project link if you omit --gc-sections from the ld options?
Comment 7 Nick Clifton 2008-08-15 11:02:03 UTC
Subject: Re:  New: Segmentation Fault using cross architecture
 ld	command

Hi John,

> We are upgrading our cross-compiler from GCC 2.95.2, binutils 2.10.1 to GCC 
> 4.2.0, binutils 2.17. 

Is there any particular reason that you are not using the 2.18 binutils 
release or the mainline development sources ?

Cheers
   Nick

Comment 8 John Morrison 2008-08-15 16:15:47 UTC
Reply to #6 from Alan:


Without the --gc-section option I get this error message:

  no memory region specified for loadable section `.eh_frame'

You can see our linker script in one of the console listings.  That has been 
used for years.  It wasn't until this migration/upgrade project, did we run 
into the above error and one other about .rela.dyn.
  
One of my many tests was to use the built in linker script which I adjusted 
slightly to our needs.  I can attach that if you wish.  It got the seg fault 
also, and if I remember correctly, I did not use the --gc-sections option with 
that script.

Comment 9 John Morrison 2008-08-15 16:17:33 UTC
Reply to #7 from Nick.


That was a finger-check on my part.  We started this journey with 2.17, but 
once we ran across the seg-fault, we went to 2.18 and I've been continuously 
checking with the latest snapshots.

Sorry about that.
Comment 10 Nick Clifton 2008-08-20 11:17:51 UTC
Hi John,

  Hmm, without a test case this is going to be very hard to track down and fix.
 But if you are willing to try a few things then maybe we can solve it.

  1.  Re comment #8.  If you add an entry for .eh_frame to your linker script
and try again does that work ?  (And if necessary, adding entries for any other
loadable input sections which are not currently mentioned in the linker script).

  2. It appears that code in elf32-ppc.c that is causing the problem is trying
to set an entry in the global offset table.  When the seg-fault occurs, can you
use gdb to find out the values (in hex) of:

    htab->got->contents
    htab->elf.hgot->root.u.def.value
    htab->got->size

Cheers
  Nick
Comment 11 John Morrison 2008-08-20 18:33:59 UTC
Reply to #10:

Item 1.  I'll play around so more with the linker script.

Item 2.  Here is the information you asked for (i hope):

I've edited out my mistakes...
For brevity I change "/home/morr_jo/work/ToolChain/cross"  to "***"
At point of fault, htab is 0x00.  
Going UP the call chain to the caller, I got the values below.  I stopped there.


Program received signal SIGSEGV, Segmentation fault.
0x0806fe40 in bfd_putb32 (data=1317011489, p=0xb66f694) at
***/src/binutils-2.18.50/bfd/libbfd.c:742
742       addr[0] = (data >> 24) & 0xff;

(gdb) bt
#0  0x0806fe40 in bfd_putb32 (data=1317011489, p=0xb66f694) at
***/src/binutils-2.18.50/bfd/libbfd.c:742
#1  0x08085cce in ppc_elf_finish_dynamic_sections (output_bfd=0x892fbe0,
info=0x8110e60) at ***/src/binutils-2.18.50/bfd/elf32-ppc.c:7739
#2  0x080a28f1 in bfd_elf_final_link (abfd=0x892fbe0, info=0x8110e60) at
***/src/binutils-2.18.50/bfd/elflink.c:10801
#3  0x0805ba4d in ldwrite () at ***/src/binutils-2.18.50/ld/ldwrite.c:567
#4  0x08059843 in main (argc=50, argv=0xbff83044) at
***/src/binutils-2.18.50/ld/ldmain.c:462

(gdb) print htab
$1 = 0

(gdb) print htab->got->contents
Attempt to extract a component of a value that is not a structure pointer.

(gdb) up
#1  0x08085cce in ppc_elf_finish_dynamic_sections (output_bfd=0x892fbe0,
info=0x8110e60) at ***/src/binutils-2.18.50/bfd/elf32-ppc.c:7739
7739            bfd_put_32 (output_bfd, 0x4e800021 /* blrl */, p - 4);

(gdb) print htab
$2 = (struct ppc_elf_link_hash_table *) 0x8931df0

(gdb) print htab->got
$3 = (asection *) 0x893a7e4

(gdb) x/50x htab->got
0x893a7e4:      0x08103048      0x00000018      0x00000008      0x0893a88c
0x893a7f4:      0x0893a73c      0x00104113      0x00000102      0x00000000
0x893a804:      0x00000000      0x00000010      0x00000000      0x000cb0b0
0x893a814:      0x08931730      0x00000002      0x00000000      0x00000000
0x893a824:      0x00000000      0x00000000      0x00000000      0x00000000
0x893a834:      0x00000000      0x00000000      0x00000000      0x00000000
0x893a844:      0x0aaba718      0x00000000      0x00000000      0x00000000
0x893a854:      0x00000000      0x00000000      0x00000000      0x00000000
0x893a864:      0x08939148      0x00000000      0x089380a0      0x089391f4
0x893a874:      0x0893a870      0x08943644      0x09ec8d5c      0x00000000
0x893a884:      0x08103043      0x056935ec      0x08103043      0x00000019
0x893a894:      0x00000009      0x0893a934      0x0893a7e4      0x0010c10b
0x893a8a4:      0x00000100      0x00000000

(gdb) print htab->got->contents
$4 = (unsigned char *) 0xaaba718 ""

(gdb) x/50x htab->got->contents
0xaaba718:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba728:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba738:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba748:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba758:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba768:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba778:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba788:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba798:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba7a8:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba7b8:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba7c8:      0x00000000      0x00000000      0x00000000      0x00000000
0xaaba7d8:      0x00000000      0x00000000

(gdb) print/x htab->elf.hgot->root.u.def.value
$7 = 0xbb4f80

(gdb) print/x  htab->got->size
$8 = 0x10


(gdb) up
#2  0x080a28f1 in bfd_elf_final_link (abfd=0x892fbe0, info=0x8110e60) at
***/src/binutils-2.18.50/bfd/elflink.c:10801

10801         if (! (*bed->elf_backend_finish_dynamic_sections) (abfd, info))

(gdb) x/30x htab->got->contents
Attempt to extract a component of a value that is not a structure pointer.

(gdb) print/x  htab->got->size
Attempt to extract a component of a value that is not a structure pointer.

(gdb) print/x htab->elf.hgot->root.u.def.value
Attempt to extract a component of a value that is not a structure pointer.

(gdb) bt
#0  0x0806fe40 in bfd_putb32 (data=1317011489, p=0xb66f694) at
***/src/binutils-2.18.50/bfd/libbfd.c:742
#1  0x08085cce in ppc_elf_finish_dynamic_sections (output_bfd=0x892fbe0,
info=0x8110e60) at ***/src/binutils-2.18.50/bfd/elf32-ppc.c:7739
#2  0x080a28f1 in bfd_elf_final_link (abfd=0x892fbe0, info=0x8110e60) at
***/src/binutils-2.18.50/bfd/elflink.c:10801
#3  0x0805ba4d in ldwrite () at ***/src/binutils-2.18.50/ld/ldwrite.c:567
#4  0x08059843 in main (argc=50, argv=0xbff83044) at
***/src/binutils-2.18.50/ld/ldmain.c:462
(gdb) 
Comment 12 John Morrison 2008-08-20 22:26:24 UTC
Reply to #10:

Item 1:  here is the updated linker script with the .eh_frame "clause" (near the
end).  I still get the
   no memory region specified for loadable section `.eh_frame'
error message.

STARTUP(vectors.o)
ENTRY(__exception_reset)

INPUT(extras.o)


GROUP(libtarget.a libgcc.a embedded.lib kerberos.lib )



MEMORY
{
    ram : ORIGIN = 0, LENGTH = 0x1000000
}

SECTIONS
{
     
    .vectors   0  :      { . = . ; KEEP(*(.vectors)) } >  ram  
     __reserved_vsr_table   = 0x3000; . =  __reserved_vsr_table   + 0x200;
    .hwinfo 0x3200 : { . = . ; __hwinfo = .; *(.hwinfo) } > ram 
    .vecipds 0x3FFF : { . = . ; __vecipds = . ; *(.vecipds) ; BYTE(0) } > ram 
    .sram  0x4000  : { _sram_start = . ; *(SORT(.sram*)) ; _sram_end = . ; } > ram
    .text   ALIGN (0x4)  :      { _stext = .; *(.text*) *(.gnu.warning)
*(.gnu.linkonce*) *(.init) } >  ram  _etext = .;  PROVIDE (etext = .);    
    .fini   ALIGN (0x4)  :      { . = . ; *(.fini) } >  ram  
    .rodata1   ALIGN (0x8)  :      { . = . ; *(.rodata1*) } >  ram  
    .rodata   ALIGN (0x8)  :      { . = . ; *(.rodata*) } >  ram  
    .fixup   ALIGN (0x4)  :      { __FIXUP_START__ = ABSOLUTE(.); *(.fixup)
__FIXUP_END__ = ABSOLUTE(.);} >  ram      
    .eh_frame : { KEEP (*(.eh_frame)) } > ram
    .gcc_except_table   ALIGN (0x1)  :      { __EXCEPT_START__ = ABSOLUTE(.);
*(.gcc_except_table) __EXCEPT_END__ = ABSOLUTE(.);} >  ram  
    .data   ALIGN (0x8)  :      { __ram_data_start = ABSOLUTE(.); *(.data*)
__GOT1_START__ = ABSOLUTE(.); *(.got1) __GOT1_END__ = ABSOLUTE(.); . = ALIGN(8);
__CTOR_LIST__ = ABSOLUTE(.); KEEP(*(SORT(.ctors*))) __CTOR_END__ = ABSOLUTE(.);
__DTOR_LIST__ = ABSOLUTE(.); KEEP(*(SORT(.dtors*))) __DTOR_END__ = ABSOLUTE(.);
. = ALIGN(8); KEEP(*( SORT (.ecos.table.*))) ; . = ALIGN(4); *( .2ram.*) ;
__GOT2_START__ = ABSOLUTE(.); *(.got2) __GOT2_END__ = ABSOLUTE(.); __GOT_START =
ABSOLUTE(.); _GLOBAL_OFFSET_TABLE_ = ABSOLUTE(. + 32768); _SDA_BASE_ =
ABSOLUTE(.); *(.got.plt) *(.got) __GOT_END__ = ABSOLUTE(.);  *(.dynamic)
__SDATA_START__ = ABSOLUTE(.); *(.sdata) *(.sdata.*) __SDATA2_START__ =
ABSOLUTE(.); *(.sdata2*) } >  ram  __rom_data_start = LOADADDR(.data);
__ram_data_end = .; PROVIDE(__ram_data_end = .); _edata = .; PROVIDE (edata = .); 
    .sbss   ALIGN (0x4)  :      { __sbss_start = ABSOLUTE (.); __SBSS_START__ =
ABSOLUTE(.); *(.sbss.*) __SBSS_END__ = ABSOLUTE(.); __SBSSx_START__ =
ABSOLUTE(.); *(.sbss*) __SBSSx_END__ = ABSOLUTE(.); *(.scommon*) __sbss_end =
ABSOLUTE (.); } >  ram  
    .bss   ALIGN (0x10)  :      { __bss_start = ABSOLUTE (.); . = . ;
*(.dynbss*) *(.bss*) *(COMMON) __bss_end = ABSOLUTE (.); } >  ram  
    
    .eh_frame :  {*(.eh_frame)}
   
     __heap1   = ALIGN (0x8);
    . = ALIGN(4); _end = .; PROVIDE (end = .); 
}

hal_vsr_table = (0x0  + 0x3000) ;
hal_virtual_vector_table = ((0x0  + 0x3000)  + 0x200) ;
Comment 13 Alan Modra 2008-09-16 04:35:57 UTC
You cannot define _GLOBAL_OFFSET_TABLE_ like this in a script.