* Re: GNU ld on x86 Solaris
@ 1997-11-05 19:32 meissner
1997-11-05 23:22 ` Fred Richardson
1997-11-05 23:22 ` Fred Richardson
0 siblings, 2 replies; 6+ messages in thread
From: meissner @ 1997-11-05 19:32 UTC (permalink / raw)
To: egcs, frichard
| I've been tooling around with GNU ld to see if I can get it to work on
| x86 Solaris. I thought this wouldn't be a problem since GNU ld seems
| to work fine on Sparc Solaris. But I'm getting this message:
|
| ld.new: foo: Not enough room for program headers (allocated 5, need 6)
| ld.new: final link failed: Bad value
|
| Here's a complete dump of ld's verbose output. Perhaps I shouldn't be
| using this version of BFD? Any help would be appreciated:
A program header is describes a region of memory to the dynamic linker (IMHO
this is a wart in ELF, that there are two different ways of describing memory,
sections being the other). In any case, for other ELF x86 systems, BFD
believes their will be five regions for programs that contain references to
shared libraries:
1) Program header region that contains the program headers themselves;
2) The interpreter region that points to the interpreter to invoke to
start the program;
3) The read-only, execute enabled text section;
4) The read/write, execute disabled data section;
5) The data passed to the dynamic loader.
If BFD claims it needs 6 tables, then you have an extra section that must be
accounted for (such as r/w data in the middle of r/o data).
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GNU ld on x86 Solaris
1997-11-05 19:32 GNU ld on x86 Solaris meissner
1997-11-05 23:22 ` Fred Richardson
@ 1997-11-05 23:22 ` Fred Richardson
1 sibling, 0 replies; 6+ messages in thread
From: Fred Richardson @ 1997-11-05 23:22 UTC (permalink / raw)
To: meissner; +Cc: egcs
Mike-
I found a temporary work around. I create a new "spec" file which
takes out all of the "values-*" objects passed to the linker. Any
idea what the consequences of this might be?
Again, thanks for any help or insight you can offer,
-Fred
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GNU ld on x86 Solaris
1997-11-05 19:32 GNU ld on x86 Solaris meissner
@ 1997-11-05 23:22 ` Fred Richardson
1997-11-06 15:17 ` Michael Meissner
1997-11-05 23:22 ` Fred Richardson
1 sibling, 1 reply; 6+ messages in thread
From: Fred Richardson @ 1997-11-05 23:22 UTC (permalink / raw)
To: meissner; +Cc: egcs
Mike-
Thanks for the info! I took a closer look at the program headers when
I link with the Solaris x86 linker. Here are the 6 fields it uses:
============================================
| On a x86 Solaris box:
============================================
% ../binutils/objdump --all-headers foo.2
foo.2: file format elf32-i386
foo.2
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08048834
Program Header:
PHDR off 0x00000034 vaddr 0x08048034 paddr 0x00000000 align 2**0
filesz 0x000000c0 memsz 0x000000c0 flags r-x
INTERP off 0x0000013c vaddr 0x00000000 paddr 0x00000000 align 2**0
filesz 0x00000011 memsz 0x00000000 flags r--
LOAD off 0x00000000 vaddr 0x08048000 paddr 0x00000000 align 2**12
filesz 0x000014bc memsz 0x000014bc flags r-x
LOAD off 0x000014bc vaddr 0x0804a4bc paddr 0x00000000 align 2**12
filesz 0x0000060c memsz 0x00000614 flags rwx
DYNAMIC off 0x000014ec vaddr 0x0804a4ec paddr 0x00000000 align 2**0
filesz 0x00000088 memsz 0x00000000 flags rwx
NOTE off 0x00001ac8 vaddr 0x00000000 paddr 0x00000000 align 2**0
filesz 0x00000050 memsz 0x00000000 flags ---
============================================
| On a sparc Solaris box:
============================================
% objdump --all-headers foo
foo: file format elf32-sparc
foo
architecture: sparc, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0001051c
Program Header:
PHDR off 0x00000034 vaddr 0x00010034 paddr 0x00010034 align 2**2
filesz 0x000000a0 memsz 0x000000a0 flags r-x
INTERP off 0x000000d4 vaddr 0x000100d4 paddr 0x000100d4 align 2**0
filesz 0x00000011 memsz 0x00000011 flags r--
LOAD off 0x00000000 vaddr 0x00010000 paddr 0x00010000 align 2**16
filesz 0x00000746 memsz 0x00000746 flags r-x
LOAD off 0x00000748 vaddr 0x00020748 paddr 0x00020748 align 2**16
filesz 0x00000188 memsz 0x000001cc flags rwx
DYNAMIC off 0x00000840 vaddr 0x00020840 paddr 0x00020840 align 2**2
filesz 0x00000090 memsz 0x00000090 flags rw-
So I wonder what "NOTE" is for...
I also found that if I run the linker without including:
/usr/ccs/lib/values-Xa.o
the program links successfully. But on the sparc, the same file is
included without causing a hitch...
Well, one further clue. On the sparc, each of these files:
/usr/ccs/lib/values-Xa.o
/usr/ccs/lib/values-Xc.o
/usr/ccs/lib/values-Xs.o
/usr/ccs/lib/values-Xt.o
has these sections:
0 .text
1 .data
2 .rodata
3 .stab.index
4 .stab.indexstr
5 .comment
but on the x86, they have these sections:
0 .text
1 .stab.index
2 .stab.indexstr
3 .comment
4 .data
5 .stab.excl
6 .stab.exclstr
Could the ".stab.excl" and ".stab.exclstr" have something to do with
the new "NOTE" section? I'm afraid I don't really know what any of
this is...
-Fred
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GNU ld on x86 Solaris
1997-11-05 23:22 ` Fred Richardson
@ 1997-11-06 15:17 ` Michael Meissner
0 siblings, 0 replies; 6+ messages in thread
From: Michael Meissner @ 1997-11-06 15:17 UTC (permalink / raw)
To: frichard; +Cc: meissner, egcs
Fred Richardson writes:
| So I wonder what "NOTE" is for...
I believe the NOTE identifies this program as being linked for
Solaris/x86, as opposed to some other x86 supporting the System V ABI
(like Linux).
| I also found that if I run the linker without including:
| /usr/ccs/lib/values-Xa.o
| the program links successfully. But on the sparc, the same file is
| included without causing a hitch...
|
| Well, one further clue. On the sparc, each of these files:
| /usr/ccs/lib/values-Xa.o
| /usr/ccs/lib/values-Xc.o
| /usr/ccs/lib/values-Xs.o
| /usr/ccs/lib/values-Xt.o
| has these sections:
| 0 .text
| 1 .data
| 2 .rodata
| 3 .stab.index
| 4 .stab.indexstr
| 5 .comment
|
| but on the x86, they have these sections:
| 0 .text
| 1 .stab.index
| 2 .stab.indexstr
| 3 .comment
| 4 .data
| 5 .stab.excl
| 6 .stab.exclstr
|
| Could the ".stab.excl" and ".stab.exclstr" have something to do with
| the new "NOTE" section? I'm afraid I don't really know what any of
| this is...
|
| -Fred
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GNU ld on x86 Solaris
1997-11-05 17:54 Fred Richardson
@ 1997-11-05 20:48 ` Ian Lance Taylor
0 siblings, 0 replies; 6+ messages in thread
From: Ian Lance Taylor @ 1997-11-05 20:48 UTC (permalink / raw)
To: frichard; +Cc: egcs
Date: Wed, 5 Nov 1997 20:53:50 -0500
From: Fred Richardson <frichard@bbn.com>
I've been tooling around with GNU ld to see if I can get it to work on
x86 Solaris.
Please send GNU ld bug reports to bug-gnu-utils@prep.ai.mit.edu. The
egcs list is for discussion of the egcs compiler. In my opinion,
we're already seeing a few too many random messages.
I thought this wouldn't be a problem since GNU ld seems
to work fine on Sparc Solaris. But I'm getting this message:
ld.new: foo: Not enough room for program headers (allocated 5, need 6)
ld.new: final link failed: Bad value
If you can get a map file, that may show the problem. Otherwise, new
program headers are allocated in map_sections_to_segments in
bfd/elf.c. You need to figure out why you are getting an extra one.
Five is the typical number: PT_PHDR, PT_INTERP, PT_DYNAMIC, a PT_LOAD
for the text segment, and a PT_LOAD for the data segment. You are
most likely getting another PT_LOAD for some reason.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* GNU ld on x86 Solaris
@ 1997-11-05 17:54 Fred Richardson
1997-11-05 20:48 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: Fred Richardson @ 1997-11-05 17:54 UTC (permalink / raw)
To: egcs
Hi-
I've been tooling around with GNU ld to see if I can get it to work on
x86 Solaris. I thought this wouldn't be a problem since GNU ld seems
to work fine on Sparc Solaris. But I'm getting this message:
ld.new: foo: Not enough room for program headers (allocated 5, need 6)
ld.new: final link failed: Bad value
Here's a complete dump of ld's verbose output. Perhaps I shouldn't be
using this version of BFD? Any help would be appreciated:
=============================================================================
GNU ld version cygnus-2.8.1 (with BFD linux-2.8.1.0.15)
Supported emulations:
elf_i386
GNU ld version cygnus-2.8.1 (with BFD linux-2.8.1.0.15)
Supported emulations:
elf_i386
using internal linker script:
==================================================
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
"elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
SEARCH_DIR(/lib); SEARCH_DIR(/usr/lib); SEARCH_DIR(/usr/ccs/lib); SEARCH_DIR(/d4mutl/contrib/egcs/lib); SEARCH_DIR(/usr/local/lib); SEARCH_DIR(/d4mutl/contrib/egcs/i386-pc-solaris2.5.1/lib);
/* Do we need any of these for elf?
__DYNAMIC = 0; */
SECTIONS
{
/* Read-only sections, merged into text segment: */
. = 0x08048000 + SIZEOF_HEADERS;
.interp : { *(.interp) }
.hash : { *(.hash) }
.dynsym : { *(.dynsym) }
.dynstr : { *(.dynstr) }
.gnu.version : { *(.gnu.version) }
.gnu.version_d : { *(.gnu.version_d) }
.gnu.version_r : { *(.gnu.version_r) }
.rel.text :
{ *(.rel.text) *(.rel.gnu.linkonce.t*) }
.rela.text :
{ *(.rela.text) *(.rela.gnu.linkonce.t*) }
.rel.data :
{ *(.rel.data) *(.rel.gnu.linkonce.d*) }
.rela.data :
{ *(.rela.data) *(.rela.gnu.linkonce.d*) }
.rel.rodata :
{ *(.rel.rodata) *(.rel.gnu.linkonce.r*) }
.rela.rodata :
{ *(.rela.rodata) *(.rela.gnu.linkonce.r*) }
.rel.got : { *(.rel.got) }
.rela.got : { *(.rela.got) }
.rel.ctors : { *(.rel.ctors) }
.rela.ctors : { *(.rela.ctors) }
.rel.dtors : { *(.rel.dtors) }
.rela.dtors : { *(.rela.dtors) }
.rel.init : { *(.rel.init) }
.rela.init : { *(.rela.init) }
.rel.fini : { *(.rel.fini) }
.rela.fini : { *(.rela.fini) }
.rel.bss : { *(.rel.bss) }
.rela.bss : { *(.rela.bss) }
.rel.plt : { *(.rel.plt) }
.rela.plt : { *(.rela.plt) }
.init : { *(.init) } =0x9090
.plt : { *(.plt) }
.text :
{
*(.text)
*(.stub)
/* .gnu.warning sections are handled specially by elf32.em. */
*(.gnu.warning)
*(.gnu.linkonce.t*)
} =0x9090
_etext = .;
PROVIDE (etext = .);
.fini : { *(.fini) } =0x9090
.rodata : { *(.rodata) *(.gnu.linkonce.r*) }
.rodata1 : { *(.rodata1) }
/* Adjust the address for the data segment. We want to adjust up to
the same address within the page on the next page up. */
. = ALIGN(0x1000) + (. & (0x1000 - 1));
.data :
{
*(.data)
*(.gnu.linkonce.d*)
CONSTRUCTORS
}
.data1 : { *(.data1) }
.ctors :
{
*(.ctors)
}
.dtors :
{
*(.dtors)
}
.got : { *(.got.plt) *(.got) }
.dynamic : { *(.dynamic) }
/* 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 = .);
__bss_start = .;
.sbss : { *(.sbss) *(.scommon) }
.bss :
{
*(.dynbss)
*(.bss)
*(COMMON)
}
_end = . ;
PROVIDE (end = .);
/* Stabs debugging sections. */
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
/* 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 . */
}
==================================================
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/crt1.o succeeded
/d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/crt1.o
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/crti.o succeeded
/d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/crti.o
attempt to open /usr/ccs/lib/values-Xa.o succeeded
/usr/ccs/lib/values-Xa.o
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/crtbegin.o succeeded
/d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/crtbegin.o
attempt to open foo.o succeeded
foo.o
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/libstdc++.so failed
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/libstdc++.a failed
attempt to open /d4mutl/contrib/egcs/i386-pc-solaris2.5.1/lib/libstdc++.so failed
attempt to open /d4mutl/contrib/egcs/i386-pc-solaris2.5.1/lib/libstdc++.a failed
attempt to open /usr/ccs/bin/libstdc++.so failed
attempt to open /usr/ccs/bin/libstdc++.a failed
attempt to open /usr/ccs/lib/libstdc++.so failed
attempt to open /usr/ccs/lib/libstdc++.a failed
attempt to open /d4mutl/contrib/egcs/lib/libstdc++.so succeeded
-lstdc++ (/d4mutl/contrib/egcs/lib/libstdc++.so)
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/libgcc.so failed
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/libgcc.a succeeded
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/libc.so failed
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/libc.a failed
attempt to open /d4mutl/contrib/egcs/i386-pc-solaris2.5.1/lib/libc.so failed
attempt to open /d4mutl/contrib/egcs/i386-pc-solaris2.5.1/lib/libc.a failed
attempt to open /usr/ccs/bin/libc.so failed
attempt to open /usr/ccs/bin/libc.a failed
attempt to open /usr/ccs/lib/libc.so failed
attempt to open /usr/ccs/lib/libc.a failed
attempt to open /d4mutl/contrib/egcs/lib/libc.so failed
attempt to open /d4mutl/contrib/egcs/lib/libc.a failed
attempt to open /usr/ccs/lib/libc.so failed
attempt to open /usr/ccs/lib/libc.a failed
attempt to open /usr/lib/libc.so succeeded
-lc (/usr/lib/libc.so)
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/libgcc.so failed
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/libgcc.a succeeded
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/crtend.o succeeded
/d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/crtend.o
attempt to open /d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/crtn.o succeeded
/d4mutl/contrib/egcs/lib/gcc-lib/i386-pc-solaris2.5.1/egcs-2.90.15/crtn.o
ld.new: foo: Not enough room for program headers (allocated 5, need 6)
ld.new: final link failed: Bad value
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1997-11-06 15:17 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-11-05 19:32 GNU ld on x86 Solaris meissner
1997-11-05 23:22 ` Fred Richardson
1997-11-06 15:17 ` Michael Meissner
1997-11-05 23:22 ` Fred Richardson
-- strict thread matches above, loose matches on Subject: below --
1997-11-05 17:54 Fred Richardson
1997-11-05 20:48 ` Ian Lance Taylor
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).