This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

powerpc-eabi linker grief


Several years ago, I had major grief linking an image for a powerpc-eabi
target. I would constantly get the error ?Not enough room for program
headers (allocated 2, need 3)?. I especially had problems when code and data
sections were not contiguous. However, after days of trial and error and
reading linker documentation, I finally got a script to work. Now, a couple
of years later I am revisiting this target.? I updated my tool chain (gcc
3.3.2, binutils 2.14) to get the latest C++ capability.? I can compile fine
with the new tool chain, but this f**!!## linker error has returned and
seems to be even harder to remove. My old scripts do not work, and nothing I
try seems to work completely. I tried cloning the newlib ?yellowknife.ld?
script, and it will link a useless image. Any modification whatsoever to
locate my code where I need it fails - vector table at the start of the RAM
address space = 0x000000, remaining text, data, bss, contiguously located
afterwards. Seems like an easy case, but it does not generate the code
properly. The following addition fixed the ?Not enough room for program
headers (allocated 2, need 3)? error:
?
PHDRS
{
?? text PT_NULL;? 
?? data PT_NULL;
}
?
?
Everything linked fine after this, except my .map file had this suspicious
output
?
??????????????? 0x01800074??????????????? . = (0x1800000 + SIZEOF_HEADERS)
?
and the .init section was located improperly, namely
?
.init?????????? 0x01800074?????? 0x1c
?*(.init)
?.init????????? 0x01800074??????? 0xc
/opt/crossCompile/lib/gcc-lib/powerpc-eabi/3.3.2/ecrti.o
??????????????? 0x01800074??????????????? __init
?.init????????? 0x01800080?????? 0x10
/opt/crossCompile/lib/gcc-lib/powerpc-eabi/3.3.2/ecrtn.o
?*(.init)
?
.text ??????????0x00003000??? 0x8e804
?*(.text .stub .text.* .gnu.linkonce.t.*)
?
Does anyone have any suggestions for the magic required to rid me of this
nightmare or an example of a working powerpc-eabi linker script that allows
you to specify where you want sections. Added below is my entire cloned and
modified Yellowknife.ld script for reference.
?
Thanks,
Alex
?
OUTPUT_FORMAT("elf32-powerpc", "elf32-powerpc", "elf32-powerpc")
OUTPUT_ARCH(powerpc)
?
/* Specify the entry symbol. */
ENTRY(Entry)
?
SEARCH_DIR(/opt/crossCompile/lib/gcc-lib/powerpc-eabi/3.3.2); 
?
__ram_size = 0x3d0000;
__ram_start = 0x0;
__stack_size = DEFINED(__stack_size) ? __stack_size : __ram_size / 10;
__stack = ((__ram_size - 4) & 0xfffffffc); __ram_align =
DEFINED(__page_size) ? __page_size : 4; __text_start = 0x3000;
?
?
PHDRS
{
?? text PT_NULL;? 
?? data PT_NULL;
}
?
?
/* Do we need any of these for elf? */
?__DYNAMIC = 0;??? 
SECTIONS
{
?? /* Read-only sections, merged into text segment: */
? . = __ram_start;
? .vectorTable :? { *(.vectorTable) }
?
? . = __text_start;
?
?? /* Read-only sections, merged into text segment: */
? .interp?? : { *(.interp) }
? .hash?????????? ? : { *(.hash)????????? }
? .dynsym?? ? : { *(.dynsym)??????? }
? .dynstr?? ? : { *(.dynstr)??????? }
? .rela.text???? :
??? { *(.rela.text) *(.rela.gnu.linkonce.t*) }
? .rela.data???? :
??? { *(.rela.data) *(.rela.gnu.linkonce.d*) }
? .rela.rodata?? :
??? { *(.rela.rodata) *(.rela.gnu.linkonce.r*) }
? .rela.got ? : { *(.rela.got)????? }
? .rela.got1????? ? : { *(.rela.got1)???? }
? .rela.got2????? ? : { *(.rela.got2)???? }
? .rela.ctors???? ? : { *(.rela.ctors)??? }
? .rela.dtors???? ? : { *(.rela.dtors)??? }
? .rela.init????? ? : { *(.rela.init)???? }
? .rela.fini????? ? : { *(.rela.fini)???? }
? .rela.bss ? : { *(.rela.bss)????? }
? .rela.plt ? : { *(.rela.plt)????? }
? .rela.sdata???? ? : { *(.rela.sdata2)?? }
? .rela.sbss????? ? : { *(.rela.sbss2)??? }
? .rela.sdata2??? ? : { *(.rela.sdata2)?? }
? .rela.sbss2???? ? : { *(.rela.sbss2)??? }
? .plt?? : { *(.plt) }
? .text __text_start?? :
? {
??? *(.text)
??? /* .gnu.warning sections are handled specially by elf32.em.? */
??? *(.gnu.warning)
??? *(.gnu.linkonce.t*)
? } =0
? .init?????????? ? : { *(.init)??? ????? } =0
? .fini?????????? ? : { *(.fini)????????? } =0
? .rodata?? ? : { *(.rodata) *(.gnu.linkonce.r*) }
? .rodata1? ? : { *(.rodata1) }
? _etext = .;
? PROVIDE (etext = .);
? .sdata2?? : { *(.sdata2) }
? .sbss2?? : { *(.sbss2) }
? /* Adjust the address for the data segment.? We want to adjust up to
???? the same address within the page on the next page up.? It would
???? be more correct to do this:
?????? . = ALIGN(0x50000) + (ALIGN(8) & (0x50000 - 1));
???? The current expression does not correctly handle the case of a
???? text segment ending precisely at the end of a page; it causes the
???? data segment to skip a page.? The above expression does not have
???? this problem, but it will currently (2/95) cause BFD to allocate
??? ?a single segment, combining both text and data, for this case.
???? This will prevent the text segment from being shared among
???? multiple executions of the program; I think that is more
???? important than losing a page of the virtual address space (note
???? that no actual memory is lost; the page which is skipped can not
???? be referenced).? */
? . =? ALIGN(8) + 0x50000;
? .data??? :
? {
??? *(.data)
??? *(.gnu.linkonce.d*)
??? CONSTRUCTORS
? }
? .data1?? : { *(.data1) }
? .got1?????????? ? : { *(.got1) }
? .dynamic? ? : { *(.dynamic) }
? /* Put .ctors and .dtors next to the .got2 section, so that the pointers
???? get relocated with -mrelocatable. Also put in the .fixup pointers.
???? The current compiler no longer needs this, but keep it around for
2.7.2? */
??????????? PROVIDE (_GOT2_START_ = .);
? .got2?????????? ? :? { *(.got2) }
??????????? PROVIDE (__CTOR_LIST__ = .);
? .ctors??? ? : { *(.ctors) }
??????????? PROVIDE (__CTOR_END__ = .);
??????????? PROVIDE (__DTOR_LIST__ = .);
? .dtors??? ? : { *(.dtors) }
??????????? PROVIDE (__DTOR_END__ = .);
??????????? PROVIDE (_FIXUP_START_ = .);
? .fixup??? ? : { *(.fixup) }
??????????? PROVIDE (_FIXUP_END_ = .);
??????????? PROVIDE (_GOT2_END_ = .);
??????????? PROVIDE (_GOT_START_ = .);
? .got??????????? ? : { *(.got) }
? .got.plt? ? : { *(.got.plt) }
??????????? PROVIDE (_GOT_END_ = .);
? /* 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??? ? : { *(.sdata) }
? _edata? =? .;
? PROVIDE (edata = .);
? .sbss????? :
? {
??? PROVIDE (__sbss_start = .);
??? *(.sbss)
??? *(.scommon)
??? PROVIDE (__sbss_end = .);
? }
? .bss?????? :
? {
?? PROVIDE (__bss_start = .);
?? *(.dynbss)
?? *(.bss)
?? *(COMMON)
?? PROVIDE (__bss_end = .);
? }
? _end = . ;
? PROVIDE (end = .);
? /* These are needed for ELF backends which have not yet been
???? converted to the new style linker.? */
? .stab 0 : { *(.stab) }
? .stabstr 0 : { *(.stabstr) }
? /* DWARF debug sections.
???? Symbols in the DWARF debugging sections are relative to the beginning
???? of the section so we begin them at 0.? */
? /* DWARF 1 */
? .debug????????? 0 : { *(.debug) }
? .line?????????? 0 : { *(.line) }
? /* GNU DWARF 1 extensions */
? .debug_srcinfo? 0 : { *(.debug_srcinfo) }
? .debug_sfnames? 0 : { *(.debug_sfnames) }
? /* DWARF 1.1 and DWARF 2 */
? .debug_aranges? 0 : { *(.debug_aranges) }
? .debug_pubnames 0 : { *(.debug_pubnames) }
? /* DWARF 2 */
? .debug_info???? 0 : { *(.debug_info) }
? .debug_abbrev?? 0 : { *(.debug_abbrev) }
? .debug_line???? 0 : { *(.debug_line) }
? .debug_frame??? 0 : { *(.debug_frame) }
? .debug_str????? 0 : { *(.debug_str) }
? .debug_loc????? 0 : { *(.debug_loc) }
? .debug_macinfo? 0 : { *(.debug_macinfo) }
? /* SGI/MIPS DWARF 2 extensions */
? .debug_weaknames 0 : { *(.debug_weaknames) }
? .debug_funcnames 0 : { *(.debug_funcnames) }
? .debug_typenames 0 : { *(.debug_typenames) }
? .debug_varnames? 0 : { *(.debug_varnames) }
? /* These must appear regardless of? .? */
}





------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]