[Bug ld/2470] /opt/gnu64/bin/ld: main: Not enough room for program headers (allocated 5, need 6)

[dave at hiauly1 dot hia dot nrc dot ca]

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2006-03-20 03:53 -------
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

------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca  
2006-03-20 03:53 -------
Created an attachment (id=932)
 --> (http://sourceware.org/bugzilla/attachment.cgi?id=932&action=view)


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=2470

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.