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 [EMAIL PROTECTED](%ebx,%eax), %eax
addl %ebx, %eax
jmp *%eax
.section .rdata,"r"
.balign 4
L32:
.long [EMAIL PROTECTED]
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 [EMAIL PROTECTED](%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 [EMAIL PROTECTED] mean ? Is it at offset L32 in GOTOFF table ?
2: Shld the value of [EMAIL PROTECTED] 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:[EMAIL PROTECTED]
Sent: Friday, March 23, 2007 9:36 PM
To: Mayank Kumar
Cc: [email protected]
Subject: Re: Information regarding -fPIC support for Interix gcc
Mayank Kumar <[EMAIL PROTECTED]> 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
