Bug 11726 - compiling programs with -static -fPIC produces code that will not run
Summary: compiling programs with -static -fPIC produces code that will not run
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 3.4.0
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2003-07-30 15:56 UTC by Randolph Chung
Modified: 2005-07-23 22:49 UTC (History)
1 user (show)

See Also:
Host: hppa-unknown-linux
Target: hppa-unknown-linux
Build: hppa-unknown-linux
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Randolph Chung 2003-07-30 15:56:02 UTC
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
Comment 1 Andrew Pinski 2003-07-30 16:19:25 UTC
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.
Comment 2 Randolph Chung 2003-09-02 22:41:28 UTC
This is fixed now by making the linker translate LTP-relative relocations into 
DP-relative relocations when not producing shared-lib code.