-bash-2.05b$ cat xxx.sh -E -u main -a archive -o main /usr/ccs/lib/pa20_64/crt0.o /lib/pa20_64/unix98.o /test/gnu/gcc-4.1/objdir/gcc/stage1/crtbeginT.o -L/test/gnu/gcc-4.1/objdir/gcc/ stage1 -L/opt/gnu64/gcc/gcc-4.1.0/lib/gcc/hppa64-hp-hpux11.11/4.1.0 -L/usr/ccs/ lib/pa20_64 -L/opt/langtools/lib/pa20_64 -L/opt/gnu64/gcc/gcc-4.1.0/lib/gcc/ hppa64-hp-hpux11.11/4.1.0/../../.. -L/lib/pa20_64 -L/usr/lib/pa20_64 main.o -v - lgcc -lgcc_eh -lpthread -lc -a shared -ldld -a archive -lc -lgcc -lgcc_eh /usr/ lib/pa20_64/milli.a /test/gnu/gcc-4.1/objdir/gcc/stage1/crtend.o -bash-2.05b$ /opt/gnu64/bin/ld `cat xxx.sh` GNU ld version 2.16.91 20060318 /opt/gnu64/bin/ld: main: Not enough room for program headers (allocated 5, need 6) Section to Segment mapping: Segment Sections... 00: PHDR: 01: INTERP: .interp 02: LOAD: .interp .dynamic .hash .dynsym .dynstr .rela.data .rela.dlt .text .rodata .PARISC.unwind 03: LOAD: .eh_frame .tbss 04: LOAD: .init .fini .init_array .fini_array .ctors .dtors .jcr .data.rel.ro .data .opd .dlt .sdata .sbss .bss .PARISC.ansi.common.1 .PARISC.ansi.common.2 .PARISC.ansi.common.3 .PARISC.ansi.common.4 .PARISC.ansi.common.5 .PARISC.ansi.common.6 .PARISC.ansi.common.7 05: DYNAMIC: .dynamic /opt/gnu64/bin/ld: final link failed: Bad value </ld: main: Not enough room for program headers (allocated 5, need 6) -bash-2.05b$ cat main.c main () {} The above problem is triggered in any '-static' link with gcc: gcc -static -o main main.c '-static' used to work but I think the introduction of HP_TLS support has broken static links because the archive version of libc introduces various objects utilizing the .tbss section. This is what we have for the program headers when the application is linked with HP ld: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0x4000000000000040 0x0000000000000000 0x0000000000000230 0x0000000000000230 R 8 PARISC_UNWIND 0x000000000000e280 0x400000000000e280 0x0000000000000000 0x00000000000047a0 0x00000000000047a0 R 4 INTERP 0x0000000000017f50 0x4000000000017f50 0x0000000000000000 0x0000000000000018 0x0000000000000018 R 1 [Requesting program interpreter: /usr/lib/pa20_64/dld.sl] DYNAMIC 0x0000000000000270 0x4000000000000270 0x0000000000000000 0x00000000000001e0 0x00000000000001e0 R 8 HP_TLS 0x000000000005f8c8 0x800000010000e580 0x0000000000000000 0x0000000000000000 0x0000000000000050 R 8 LOAD 0x0000000000000000 0x4000000000000000 0x0000000000000000 0x0000000000058540 0x0000000000058540 R E 10 LOAD 0x0000000000059000 0x8000000100000000 0x0000000000000000 0x00000000000068c8 0x000000000000e580 RW 20 HP_FASTBIND 0x000000000005f8c8 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 R 1 NOTE 0x000000000005f8c8 0x0000000000000000 0x0000000000000000 0x000000000001c638 0x0000000000000000 R 8 HP_STACK 0x000000000007bf00 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 0 Section to Segment mapping: Segment Sections... 00 01 .PARISC.unwind 02 .interp 03 .dynamic 04 .tbss 05 .dynamic .dynsym .dynstr .hash .rela.dlt .rela.init .rela.init_array . rela.fini .rela.fini_array .rela.data.rel.ro .rela.data .rela.sdata .rela.preini t .PARISC.unwind .rodata .interp .dynhash .opd .text 06 .data .ctors .dtors .init .init_array .fini .fini_array .eh_frame .jcr .data.rel.local .data.rel.ro .preinit .plt .dlt .sdata .sbss .bss 07 08 .note 09 A hack to elf64_hppa_additional_program_headers to provide an additional program header when .tbss is present allows the file to link. However, the dynamic loader rejects the executable. The HP TLS support uses different flag bits, so it's not detected as such. As can be seen above, it also uses PT_HP_TLS as its program header type.
Subject: Re: New: /opt/gnu64/bin/ld: main: Not enough room for program headers (allocated 5, need 6) The attached quick hack now allows the program to link and execute. However, it doesn't work: -bash-2.05b$ ./main Bus error (core dumped) Looking at this in gdb, I see: -bash-2.05b$ /opt/gnu64/bin/gdb-6.2 main GNU gdb 6.2 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "hppa64-hp-hpux11.11"...(no debugging symbols found)... (gdb) r Starting program: /home/dave/gcc_test/main (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... Program received signal SIGBUS, Bus error. 0x400000000000a98c in ___stdio_unsup_1 () (gdb) disass 0x400000000000a97c 0x400000000000a99c Dump of assembler code from 0x400000000000a97c to 0x400000000000a99c: 0x400000000000a97c <___stdio_unsup_1+700>: cmpib,>,n 8,r8,0x400000000000a944 <___stdio_unsup_1+644> 0x400000000000a980 <___stdio_unsup_1+704>: extrd,s r8,63,32,r13 0x400000000000a984 <___stdio_unsup_1+708>: addil 0,dp,%r1 0x400000000000a988 <___stdio_unsup_1+712>: ldd 488(r1),r22 0x400000000000a98c <___stdio_unsup_1+716>: ldd 0(r22),r8 0x400000000000a990 <___stdio_unsup_1+720>: cmpb,*= r8,r0,0x400000000000a89c <___stdio_unsup_1+476> 0x400000000000a994 <___stdio_unsup_1+724>: nop 0x400000000000a998 <___stdio_unsup_1+728>: ldi 0,r9 End of assembler dump. (gdb) p/x $r22 $1 = 0x800000000000af46 (gdb) info symbol 0x800000000000af46 ___stdio_unsup_2 in section .PARISC.ansi.common.5 This appears to be a different problem. It's seems we have a section alignment issue: [27] .PARISC.ansi.comm NOBITS 8000000000007e58 0003a520 0000000000002fe0 0000000000000000 WA 0 0 1 [28] .PARISC.ansi.comm NOBITS 800000000000ae38 0003a520 0000000000000008 0000000000000000 WA 0 0 1 [29] .PARISC.ansi.comm NOBITS 800000000000ae40 0003a520 0000000000000082 0000000000000000 WA 0 0 1 [30] .PARISC.ansi.comm NOBITS 800000000000aec2 0003a520 0000000000000004 0000000000000000 WA 0 0 1 [31] .PARISC.ansi.comm NOBITS 800000000000aec6 0003a520 0000000000000088 0000000000000000 WA 0 0 1 [32] .PARISC.ansi.comm NOBITS 800000000000af4e 0003a520 0000000000000004 0000000000000000 WA 0 0 1 [33] .PARISC.ansi.comm NOBITS 800000000000af52 0003a520 0000000000000c1d 0000000000000000 WA 0 0 1 The section to segment mappings still seem a bit wierd: Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align PHDR 0x0000000000000040 0x4000000000001040 0x4000000000001040 0x0000000000000150 0x0000000000000150 R E 8 INTERP 0x0000000000000190 0x4000000000001190 0x4000000000001190 0x0000000000000018 0x0000000000000018 R 1 [Requesting program interpreter: /usr/lib/pa20_64/dld.sl] LOAD 0x0000000000000000 0x4000000000001000 0x4000000000001000 0x0000000000033f58 0x0000000000033f58 RWE 1000 LOAD 0x0000000000034000 0x8000000000001000 0x8000000000001000 0x0000000000006520 0x000000000000ab6f RW 1000 DYNAMIC 0x00000000000001a8 0x40000000000011a8 0x40000000000011a8 0x0000000000000190 0x0000000000000190 RW 8 HP_TLS 0x0000000000034004 0x8000000000001008 0x8000000000001008 0x0000000000000000 0x000000000000003c R 8 Section to Segment mapping: Segment Sections... 00 01 .interp 02 .interp .dynamic .hash .dynsym .dynstr .rela.data .rela.dlt .text .rodata .PARISC.unwind 03 .eh_frame .tbss .init .fini .init_array .fini_array .ctors .dtors .jcr.data.rel.ro .data .opd .dlt .sdata .sbss .bss .PARISC.ansi.common.1 .PARISC.ansi.common.2 .PARISC.ansi.common.3 .PARISC.ansi.common.4 .PARISC.ansi.common.5 .PARISC.ansi.common.6 .PARISC.ansi.common.7 04 .dynamic 05 .tbss .init .fini .init_array .fini_array I don't understand why the .tbss section appears in segments 3 and 5. It doesn't in the HP linked file. Dave
Created attachment 932 [details] elf.c.d