[ECOS] powerpc.ld question

[ECOS] powerpc.ld question

[Will Wagner]

I am trying to upgrade to a new version of binutils as I'm experiencing 
problems with my current version.

The new version of ld throws an error when trying to link saying that 
the section .eh_frame_hdr is not specified.

I know I need to add an entry to /hal/powerpc/src/powerpc.ld, but I'm 
not sure where this needs to go. The only other .ld file I could find 
that referenced eh_frame_hdr is sh4_202_md.ld but that file is so 
different I didn't find it very useful.

So anyone able to tell me what I should be adding and where?

Many thanks,

Will
-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner@carallon.com
Senior Project Engineer                        Office Tel: 0207 371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] powerpc.ld question

[Gary Thomas]

Will Wagner wrote:
> I am trying to upgrade to a new version of binutils as I'm experiencing 
> problems with my current version.
> 
> The new version of ld throws an error when trying to link saying that 
> the section .eh_frame_hdr is not specified.
> 
> I know I need to add an entry to /hal/powerpc/src/powerpc.ld, but I'm 
> not sure where this needs to go. The only other .ld file I could find 
> that referenced eh_frame_hdr is sh4_202_md.ld but that file is so 
> different I didn't find it very useful.
> 

What version of binutils (and GCC) are you using?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] powerpc.ld question

[Will Wagner]

Have had issues with 2.16 & 2.17 of binutils so am now trying to get the 
HEAD of CVS working.

Am using GCC 3.3.3

Gary Thomas wrote:
> Will Wagner wrote:
>> I am trying to upgrade to a new version of binutils as I'm 
>> experiencing problems with my current version.
>>
>> The new version of ld throws an error when trying to link saying that 
>> the section .eh_frame_hdr is not specified.
>>
>> I know I need to add an entry to /hal/powerpc/src/powerpc.ld, but I'm 
>> not sure where this needs to go. The only other .ld file I could find 
>> that referenced eh_frame_hdr is sh4_202_md.ld but that file is so 
>> different I didn't find it very useful.
>>
> 
> What version of binutils (and GCC) are you using?
> 

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner@carallon.com
Senior Project Engineer                        Office Tel: 0207 371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] powerpc.ld question

[Gary Thomas]

Will Wagner wrote:
> Have had issues with 2.16 & 2.17 of binutils so am now trying to get the 
> HEAD of CVS working.

Just curious - what issues did you have with these previous versions?
I run 2.16 and 2.16.1 here (gcc 3.4.3 and 4.1.0 respectively) with
no problems.

Does your powerpc.ld file not include a line which looks like this?
   *(.eh_frame)
Perhaps it needs to be written as:
   *(.eh_frame_hdr) *(.eh_frame)

I'm perplexed though; I've never had a need for this.  Maybe it's in
your usage of GCC or how you configured it when building it.

> 
> Am using GCC 3.3.3
> 
> Gary Thomas wrote:
>> Will Wagner wrote:
>>> I am trying to upgrade to a new version of binutils as I'm 
>>> experiencing problems with my current version.
>>>
>>> The new version of ld throws an error when trying to link saying that 
>>> the section .eh_frame_hdr is not specified.
>>>
>>> I know I need to add an entry to /hal/powerpc/src/powerpc.ld, but I'm 
>>> not sure where this needs to go. The only other .ld file I could find 
>>> that referenced eh_frame_hdr is sh4_202_md.ld but that file is so 
>>> different I didn't find it very useful.
>>>
>>
>> What version of binutils (and GCC) are you using?
>>
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] powerpc.ld question

[Will Wagner]

I am seeing two issues with the linker. Either I get the internal error 
ld: internal error /src/binutils-2.17/ld/ldlang.c 3803 when trying to 
link. Or I see that it links but when executing the image and an 
exception is thrown the code doesn't handle it correctly. By changing a 
few lines of code (often containing strings) I can get either of those 
behaviours or an image that works correctly.

Could well be an issue with the gcc I am using, however ld should not 
fail with an internal error either. Have been in touch with binutils 
developers and they suggested to try the head version of ld.

My powerpc.ld file does contain .eh_frame:

#define SECTION_eh_frame(_region_, _vma_, _lma_)      \
   .eh_frame _vma_ : _lma_                             \
     {                                                 \
        FORCE_OUTPUT;  __EH_FRAME_BEGIN__ = .;         \
        KEEP(*(.eh_frame))                             \
        __FRAME_END__ = .;                             \
        . = . + 8;                                     \
     } > _region_ = 0

But no mention of .eh_frame_hdr. Should I add it to that KEEP directive? 
Wasn't sure if it should be there or in the text section.

Will.


Gary Thomas wrote:
> Will Wagner wrote:
>> Have had issues with 2.16 & 2.17 of binutils so am now trying to get 
>> the HEAD of CVS working.
> 
> Just curious - what issues did you have with these previous versions?
> I run 2.16 and 2.16.1 here (gcc 3.4.3 and 4.1.0 respectively) with
> no problems.
> 
> Does your powerpc.ld file not include a line which looks like this?
>   *(.eh_frame)
> Perhaps it needs to be written as:
>   *(.eh_frame_hdr) *(.eh_frame)
> 
> I'm perplexed though; I've never had a need for this.  Maybe it's in
> your usage of GCC or how you configured it when building it.
> 
>>
>> Am using GCC 3.3.3
>>
>> Gary Thomas wrote:
>>> Will Wagner wrote:
>>>> I am trying to upgrade to a new version of binutils as I'm 
>>>> experiencing problems with my current version.
>>>>
>>>> The new version of ld throws an error when trying to link saying 
>>>> that the section .eh_frame_hdr is not specified.
>>>>
>>>> I know I need to add an entry to /hal/powerpc/src/powerpc.ld, but 
>>>> I'm not sure where this needs to go. The only other .ld file I could 
>>>> find that referenced eh_frame_hdr is sh4_202_md.ld but that file is 
>>>> so different I didn't find it very useful.
>>>>
>>>
>>> What version of binutils (and GCC) are you using?
>>>
>>
> 
> 

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner@carallon.com
Senior Project Engineer                        Office Tel: 0207 371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] powerpc.ld question

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]

Will Wagner wrote:
> I am seeing two issues with the linker. Either I get the internal error 
> ld: internal error /src/binutils-2.17/ld/ldlang.c 3803 when trying to 
> link. Or I see that it links but when executing the image and an 
> exception is thrown the code doesn't handle it correctly. By changing a 
> few lines of code (often containing strings) I can get either of those 
> behaviours or an image that works correctly.
> 
> Could well be an issue with the gcc I am using, however ld should not 
> fail with an internal error either. Have been in touch with binutils 
> developers and they suggested to try the head version of ld.

What's your host?  I've *never* seen any of these behaviours on Linux.

> 
> My powerpc.ld file does contain .eh_frame:
> 
> #define SECTION_eh_frame(_region_, _vma_, _lma_)      \
>   .eh_frame _vma_ : _lma_                             \
>     {                                                 \
>        FORCE_OUTPUT;  __EH_FRAME_BEGIN__ = .;         \
>        KEEP(*(.eh_frame))                             \
>        __FRAME_END__ = .;                             \
>        . = . + 8;                                     \
>     } > _region_ = 0
> 
> But no mention of .eh_frame_hdr. Should I add it to that KEEP directive? 
> Wasn't sure if it should be there or in the text section.

This is not the same setup - try using the version from CVS (attached)
Note: the last time it was changed was 2003-04-10, so you must be
working with some *vintage* code :-)

> Gary Thomas wrote:
>> Will Wagner wrote:
>>> Have had issues with 2.16 & 2.17 of binutils so am now trying to get 
>>> the HEAD of CVS working.
>>
>> Just curious - what issues did you have with these previous versions?
>> I run 2.16 and 2.16.1 here (gcc 3.4.3 and 4.1.0 respectively) with
>> no problems.
>>
>> Does your powerpc.ld file not include a line which looks like this?
>>   *(.eh_frame)
>> Perhaps it needs to be written as:
>>   *(.eh_frame_hdr) *(.eh_frame)
>>
>> I'm perplexed though; I've never had a need for this.  Maybe it's in
>> your usage of GCC or how you configured it when building it.
>>
>>>
>>> Am using GCC 3.3.3
>>>
>>> Gary Thomas wrote:
>>>> Will Wagner wrote:
>>>>> I am trying to upgrade to a new version of binutils as I'm 
>>>>> experiencing problems with my current version.
>>>>>
>>>>> The new version of ld throws an error when trying to link saying 
>>>>> that the section .eh_frame_hdr is not specified.
>>>>>
>>>>> I know I need to add an entry to /hal/powerpc/src/powerpc.ld, but 
>>>>> I'm not sure where this needs to go. The only other .ld file I 
>>>>> could find that referenced eh_frame_hdr is sh4_202_md.ld but that 
>>>>> file is so different I didn't find it very useful.
>>>>>
>>>>
>>>> What version of binutils (and GCC) are you using?
>>>>
>>>
>>
>>
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[-- Attachment #2: powerpc.ld --]
[-- Type: text/plain, Size: 7606 bytes --]

//==========================================================================
//
//	powerpc.ld
//
//	Linker script for PowerPC
//
//==========================================================================
//####ECOSGPLCOPYRIGHTBEGIN####
// -------------------------------------------
// This file is part of eCos, the Embedded Configurable Operating System.
// Copyright (C) 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
//
// eCos is free software; you can redistribute it and/or modify it under
// the terms of the GNU General Public License as published by the Free
// Software Foundation; either version 2 or (at your option) any later version.
//
// eCos is distributed in the hope that it will be useful, but WITHOUT ANY
// WARRANTY; without even the implied warranty of MERCHANTABILITY or
// FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
// for more details.
//
// You should have received a copy of the GNU General Public License along
// with eCos; if not, write to the Free Software Foundation, Inc.,
// 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA.
//
// As a special exception, if other files instantiate templates or use macros
// or inline functions from this file, or you compile this file and link it
// with other works to produce a work based on this file, this file does not
// by itself cause the resulting work to be covered by the GNU General Public
// License. However the source code for this file must still be made available
// in accordance with section (3) of the GNU General Public License.
//
// This exception does not invalidate any other reasons why a work based on
// this file might be covered by the GNU General Public License.
//
// Alternative licenses for eCos may be arranged by contacting Red Hat, Inc.
// at http://sources.redhat.com/ecos/ecos-license/
// -------------------------------------------
//####ECOSGPLCOPYRIGHTEND####
//==========================================================================
//#####DESCRIPTIONBEGIN####
//
// Author(s): 	jskov
// Contributors:jskov
// Date:	1999-01-18
// Purpose:	PowerPC Linker script
//
//####DESCRIPTIONEND####
//
//==========================================================================
STARTUP(vectors.o)
ENTRY(__exception_reset)
#ifdef EXTRAS
INPUT(extras.o)
#endif
#if (__GNUC__ >= 3)
GROUP(libtarget.a libgcc.a libsupc++.a)
#else
GROUP(libtarget.a libgcc.a)
#endif

#define ALIGN_LMA 8
#define FOLLOWING(_section_) AT ((LOADADDR (_section_) + SIZEOF (_section_) + ALIGN_LMA - 1) & ~ (ALIGN_LMA - 1))
#define LMA_EQ_VMA
#define FORCE_OUTPUT . = .


#define SECTIONS_BEGIN

#define SECTION_vectors(_region_, _vma_, _lma_)        \
  .vectors _vma_ : _lma_                                              \
  { FORCE_OUTPUT; KEEP(*(.vectors)) }         \
  > _region_

#define SECTION_text(_region_, _vma_, _lma_)           \
  .text _vma_ : _lma_                                                 \
  { _stext = .;       \
    *(.text*) *(.gnu.warning) *(.gnu.linkonce*) *(.init) }      \
  > _region_                                                    \
  _etext = .;  PROVIDE (etext = .);

#define SECTION_fini(_region_, _vma_, _lma_)   \
    .fini _vma_ : _lma_                                       \
    { FORCE_OUTPUT; *(.fini) }        \
    > _region_

#define SECTION_rodata1(_region_, _vma_, _lma_)        \
    .rodata1 _vma_ : _lma_                                            \
    { FORCE_OUTPUT; *(.rodata1*) }             \
    > _region_

#define SECTION_rodata(_region_, _vma_, _lma_) \
    .rodata _vma_ : _lma_                                     \
    { FORCE_OUTPUT; *(.rodata*) }     \
    > _region_

#define SECTION_fixup(_region_, _vma_, _lma_)                      \
    .fixup _vma_ : _lma_                                                          \
    { __FIXUP_START__ = ABSOLUTE(.); *(.fixup) __FIXUP_END__ = ABSOLUTE(.);}\
    > _region_

#define SECTION_gcc_except_table(_region_, _vma_, _lma_)       \
    .gcc_except_table _vma_ : _lma_                                           \
    { __EXCEPT_START__ = ABSOLUTE(.); *(.gcc_except_table)              \
      __EXCEPT_END__ = ABSOLUTE(.);}                                    \
    > _region_

#define SECTION_data(_region_, _vma_, _lma_)                         \
    .data _vma_ : _lma_                                                             \
    { __ram_data_start = ABSOLUTE(.); *(.data*)                                 \
    __GOT1_START__ = ABSOLUTE(.); *(.got1) __GOT1_END__ = ABSOLUTE(.);        \
      /* Put .ctors and .dtors next to the .got2 section, so that */          \
      /* the pointers get relocated with -mrelocatable.           */          \
     . = 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)                                   \
    *(.eh_frame)                                                              \
      /* We want the small data sections together, so single-instruction */   \
      /* offsets can access them all, and initialized data all before    */   \
      /* uninitialized, so we can shorten the on-disk segment size.      */   \
    __SDATA_START__ = ABSOLUTE(.); *(.sdata) *(.sdata.*)                      \
    __SDATA2_START__ = ABSOLUTE(.); *(.sdata2*) }                             \
    > _region_                                                                \
    __rom_data_start = LOADADDR(.data);                                       \
    __ram_data_end = .; PROVIDE(__ram_data_end = .);                          \
    _edata = .; PROVIDE (edata = .);

#define SECTION_sbss(_region_, _vma_, _lma_)                     \
    .sbss _vma_ : _lma_                                                         \
    { __sbss_start = ABSOLUTE (.);                                        \
    __SBSS_START__ = ABSOLUTE(.); *(.sbss.*) __SBSS_END__ = ABSOLUTE(.);   \
    __SBSSx_START__ = ABSOLUTE(.); *(.sbss*) __SBSSx_END__ = ABSOLUTE(.);\
    *(.scommon*)                                                          \
    __sbss_end = ABSOLUTE (.); }                                          \
    > _region_

#define SECTION_bss(_region_, _vma_, _lma_)                      \
    .bss _vma_ : _lma_                                                          \
    { __bss_start = ABSOLUTE (.);                       \
      FORCE_OUTPUT; *(.dynbss*) *(.bss*) *(COMMON)      \
      __bss_end = ABSOLUTE (.); }                       \
    > _region_

#define SECTIONS_END . = ALIGN(4); _end = .; PROVIDE (end = .);

#include <pkgconf/system.h>
#include CYGHWR_MEMORY_LAYOUT_LDI

// Define VSR and virtual tables to reside at fixed addresses.
#include CYGBLD_HAL_TARGET_H
hal_vsr_table = CYGHWR_HAL_VSR_TABLE;
hal_virtual_vector_table = CYGHWR_HAL_VIRTUAL_VECTOR_TABLE;


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] powerpc.ld question

[Will Wagner]

>> Could well be an issue with the gcc I am using, however ld should not 
>> fail with an internal error either. Have been in touch with binutils 
>> developers and they suggested to try the head version of ld.
> 
> What's your host?  I've *never* seen any of these behaviours on Linux.

Sadly I'm stuck on cywin which I'm sure could be causing some problems. 
Am also using an eCosCentric version to get C++ exception support which 
also may be the issue, however am sadly long out of our support period, 
so having to go it alone ;)


> 
>>
>> My powerpc.ld file does contain .eh_frame:
>>
>> #define SECTION_eh_frame(_region_, _vma_, _lma_)      \
>>   .eh_frame _vma_ : _lma_                             \
>>     {                                                 \
>>        FORCE_OUTPUT;  __EH_FRAME_BEGIN__ = .;         \
>>        KEEP(*(.eh_frame))                             \
>>        __FRAME_END__ = .;                             \
>>        . = . + 8;                                     \
>>     } > _region_ = 0
>>
>> But no mention of .eh_frame_hdr. Should I add it to that KEEP 
>> directive? Wasn't sure if it should be there or in the text section.
> 
> This is not the same setup - try using the version from CVS (attached)
> Note: the last time it was changed was 2003-04-10, so you must be
> working with some *vintage* code :-)


Stupidly didn't think of looking at what was in current CVS. Have made a 
version of that file with the eCosCentric __EH_FRAME_BEGIN__ haced in 
and it links time to test whether it works.

Thanks for your help,

Will


-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner@carallon.com
Senior Project Engineer                        Office Tel: 0207 371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss