RE: Information regarding -fPIC support for Interix gcc

[Mayank Kumar <mayank at microsoft dot com>]

Further to this email, I did some more investigation, here is some more detailed information about what I am doing:-

1: Compiled a shared library(tcl8.4.14) using -fPIC on gcc4.3.0 for interix(was able to compile gcc 4.3.0 for interix)
2: The assembly generated for a particular region of code which causes a jmp to an invalid location, obtained using gcc -S -fPIC is as follows:-
        movl    -20(%ebp), %eax
        sall    $2, %eax
        movl    L32@GOTOFF(%ebx,%eax), %eax
        addl    %ebx, %eax
        jmp     *%eax
        .section        .rdata,"r"
        .balign 4
L32:
        .long   L30@GOTOFF

3:the assembly generated while executing the binary linked with the shared library
0x100889dc <Tcl_ConvertCountedElement+246>:     mov    0xffffffec(%ebp),%eax
0x100889df <Tcl_ConvertCountedElement+249>:     shl    $0x2,%eax
0x100889e2 <Tcl_ConvertCountedElement+252>:     mov    0xffffbd14(%eax,%ebx,1),%eax
0x100889e9 <Tcl_ConvertCountedElement+259>:     add    %ebx,%eax
0x100889eb <Tcl_ConvertCountedElement+261>:     jmp    *%eax

4:Similar code compiled and run on a FreeBsd box using gcc shared library and fPIC produces the following assembly:-
0x2810a1a8 <Tcl_ConvertCountedElement+244>:     mov    0xffffffec(%ebp),%eax
0x2810a1ab <Tcl_ConvertCountedElement+247>:     shl    $0x2,%eax
0x2810a1ae <Tcl_ConvertCountedElement+250>:     mov    0xffff4f14(%eax,%ebx,1),%eax
0x2810a1b5 <Tcl_ConvertCountedElement+257>:     add    %ebx,%eax
0x2810a1b7 <Tcl_ConvertCountedElement+259>:     jmp    *%eax

5:So corresponding to
-------movl    L32@GOTOFF(%ebx,%eax), %eax,
The assembly generated on interix is
------- mov    0xffffbd14(%eax,%ebx,1),%eax
Whereas on bsd box, it is
------- mov    0xffff4f14(%eax,%ebx,1),%eax

Here the offset ffffbd14 in case of interix is wrong which is causing the jmp *eax to jump to a different function.

Now my questions are:-
1: What does L32@GOTOFF mean ? Is it at offset L32 in GOTOFF table ?
2: Shld the value of L32@GOTOFF remain same for all machines for which the same library/binary is compiled?
3: Does the above mean that the GLOBAL_OFFSET_TABLE is not being populated correctly ? If that is so, why would this be interix specific?
4: I can see these offset's with objdump -D also, so I concluded that this could not be a linker or loader issue but a compiler issue only. Which part of gcc code should I refer for this issue?
5:Lastly, should I raise a bug in gcc Bugzilla to track this and assign it to myself or what is the procedure to track this ?

Any other help or pointers in this regard shld be useful in investigating further.

NOTE: I could repro this issue with gcc4.3.0 compiler and linker/loader/assembler same as the one that ships with Interix.

Thanks
Mayank


-----Original Message-----
From: Ian Lance Taylor [mailto:iant@google.com]
Sent: Friday, March 23, 2007 9:36 PM
To: Mayank Kumar
Cc: gcc@gcc.gnu.org
Subject: Re: Information regarding -fPIC support for Interix gcc

Mayank Kumar <mayank@microsoft.com> writes:

> Ok, since I didn't get any pointers in this area.
> I have a more generic question now to everybody:-
>
>  I am new to gcc development as well as its architecture. I am looking forward to fix the -fPIC issue for Interix. As of now I found that a shared library compiled with fPIC crashes due to some wrong assembly instructions(a jmp instruction) embedded into a function call which cause it to jump unconditionally to a different function altogether whereas the c code has no such jumps or function calls.
> Can some body point me to the part of source code that I should look into for this. I mean:-

These are all rather difficult questions to answer succintly.  gcc is
a large code base.  It is not organized in a way which makes it simple
to answer this sort of question.

> 1: the part which is responsible for generating this code from c code.

If by "this code" you mean inserting a jmp instruction, there are many
possibilities.  The first one you should look at is that at least on
some x86 platforms gcc intentionally calls __i686.get_pc_thunk.bx as
part of setting the PIC register.  This looks a different function but
it is just a tiny helper routine.

> 2: the part of the gcc code where -fPIC is being handled.

It is handled in a number of places.  Search for flag_pic.  For i386
in particular the most exciting place is probably
legitimize_pic_address.

> 3: any other pointers to investigating this would be helpful.

Reading the gcc internal's manual?

Ian