[Bug c/11726] New: compiling programs with -static -fPIC produces code that will not run

[Bug c/11726] New: compiling programs with -static -fPIC produces code that will not run

[tausq at debian dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11726

           Summary: compiling programs with -static -fPIC produces code that
                    will not run
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: tausq at debian dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: hppa-unknown-linux
  GCC host triplet: hppa-unknown-linux
GCC target triplet: hppa-unknown-linux

e.g.
#include <stdio.h>
int main()
{
        printf("Hello\n");
        return 0;
}

tausq@ios:~$ gcc -fPIC -static -o hello hello.c
tausq@ios:~$ ./hello
Segmentation fault

The problem seems to be that the PIC register (r19) is not properly initialized 
for static executables.
GDB output:
Program received signal SIGSEGV, Segmentation fault.
0x00010268 in main ()
(gdb) disassemble
Dump of assembler code for function main:
0x1024c <main>: stw rp,-14(sr0,sp)
0x10250 <main+4>:       copy r3,r1
0x10254 <main+8>:       copy sp,r3
0x10258 <main+12>:      stw,ma r1,40(sr0,sp)
0x1025c <main+16>:      stw r4,8(sr0,r3)
0x10260 <main+20>:      stw r19,-20(sr0,sp)
0x10264 <main+24>:      addil 1000,r19,%r1
0x10268 <main+28>:      ldw f0(sr0,r1),r1
0x1026c <main+32>:      copy r1,r26
0x10270 <main+36>:      copy r19,r4
0x10274 <main+40>:      b,l 0x109d0 <printf>,rp
0x10278 <main+44>:      nop
0x1027c <main+48>:      copy r4,r19
0x10280 <main+52>:      ldi 0,r20
0x10284 <main+56>:      copy r20,ret0
0x10288 <main+60>:      ldw -14(sr0,r3),rp
0x1028c <main+64>:      ldw 8(sr0,r3),r4
0x10290 <main+68>:      ldo 40(r3),sp
0x10294 <main+72>:      ldw,mb -40(sr0,sp),r3
0x10298 <main+76>:      bv,n r0(rp)
End of assembler dump.
(gdb) info reg
     flags: 0                       pcsqt: b80
        r1: 1004                     eiem: 0
        rp: 1063f                     iir: 482101e0
        r3: faf00500                  isr: b80
        r4: 401ed644                  ior: 10f4
        r5: faf0038a                 ipsw: 4fe0f
        r6: 1                        cr31: 0
        r7: faf00188                  sr4: b80
        r8: 0                         sr0: 0
        r9: 63254                     sr1: b80
       r10: 100c4                     sr2: 0
       r11: 1024c                     sr3: b80
       r12: 211908                    sr5: b80
       r13: 1fc908                    sr6: b80
       r14: 211908                    sr7: b80
       r15: 1f8108                   rcnt: 0
       r16: 213040                  ptid1: 0
       r17: 0                       ptid2: 0
       r18: 213030                    ccr: 0
       r19: 4                       ptid3: 0
       r20: 1000                    ptid4: 0
       r21: 0                        cr24: 0
       r22: 1024c                    cr25: 0
       r23: 81010100                 cr26: 0
       r24: faf00190                 cr27: 4017b2a0
       r25: faf00188                 cr28: 0
       r26: 1                        cr29: 0
        dp: 88700                    cr30: 0
      ret0: ffffffff                 fpsr: 0
      ret1: 2f                       fpe1: 0
        sp: faf00540                 fpe2: 0
       r31: 1063f                    fpe3: 0
       sar: 1c                       fpe4: 0
     pcoqh: 1026b                    fpe5: 0
     pcsqh: b80                      fpe6: 0
     pcoqt: 1026f                    fpe7: 0

This is not a new problem -- you can see this with all versions of GCC on this 
architecture

[Bug c/11726] compiling programs with -static -fPIC produces code that will not run

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11726



------- Additional Comments From pinskia at physics dot uc dot edu  2003-07-30 16:19 -------
Actually you only see it on platforms where the PIC register is set (or not set) by the loader. On 
i686-pc-linux-gnu, the PIC register is variable and is set by the code outputed by gcc, also in 
powerpc-apple-darwin6.6 the same thing happens.
I think this really a bug in the executable loader rather than gcc as you should be able to mix pic 
code and non-pic code just fine.

[Bug target/11726] compiling programs with -static -fPIC produces code that will not run

[pinskia at physics dot uc dot edu]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11726


pinskia at physics dot uc dot edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target

[Bug target/11726] compiling programs with -static -fPIC produces code that will not run

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11726


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Target Milestone|3.4                         |---

[Bug target/11726] compiling programs with -static -fPIC produces code that will not run

[tausq at debian dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11726


tausq at debian dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED


------- Additional Comments From tausq at debian dot org  2003-09-02 22:41 -------
This is fixed now by making the linker translate LTP-relative relocations into 
DP-relative relocations when not producing shared-lib code.