On 3/31/07, Mayank Kumar <[EMAIL PROTECTED]> wrote:
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 ?
It means the offset of L32 from the symbol GLOBAL_OFFSET_TABLE. It looks like this refers to a switch table. It is indexing into a jump table and jmping to that label.
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?
The Global Offset Table (GOT) is generated by the linker. But this is specific to Elf binaries. The PECOFF ABI does not define a GOT. Nor does it support the relocation types R_386_GOTOFF and R_386_GOT32.
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.
Now that you have successfully built gcc 4.3.0 on interix, please try to apply my 4.3 patch and see if it generates correct code. The only difference in the patch would be to define TARGET_CYGMING to 1 in the file i386-interix.h.
Thanks Mayank
Thanks Murali
-----Original Message----- From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] 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 <[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
