Hi Murali/Everybody 1: I am keen on understanding how does the offset of L32 from _GLOBAL_OFFSET_TABLE_ generated ? I mean if assembly is
Movl [EMAIL PROTECTED](%ebx,%eax),%eax then how does is gets converted to mov 0xffffbd14(%eax,%ebx,1),%eax. I guessed that L32 is at start of .rodata section which is the only section of its type. So in my opinion it should have been Address of .got section - address of .rodata section. But I am not getting the generated offset seen in objdump as the same as I calculate from the above method on a FreeBSD box. Can anyone help here ? On interix, the offset is being calculated as .got - .rodata only, so is there anything wrong in this? I am assuming that this is the only thing that could be going wrong. 2: Murali, Interix generated pecoff binaries have _GLOBAL_OFFSET_TABLE_ defined. We also have .got section/.plt section etc which are present in a pic compiled code, hence your patch may fix the problem in an alternate way but may not be the correct fix for Interix. Yes , you are right that the generated assembly is for a switch case and is actually a jump table. 3: Also, after further investigation, I found that Interix compiled shared libraries with fPIC flag only cause a crash when there is a jump table being created for a switch case. I compiled the same shared library which was crashing with ---fPIC and -fno-jump-table on 4.3 and it worked great. So are there any jump table experts out there who could help me investigate what is going wrong in there? I have attached objdump -D output and gcc -S output for the shared library(repro code which is basically a small dummy library). --Ass contains objdump -D output --lib1.s contains gcc -S output Look at the jump table generated for switch case inside func1_1? This causes the crash because the control jumps to invalid location thru jmp*%eax. Thanks Mayank -----Original Message----- From: Murali Vemulapati [mailto:[EMAIL PROTECTED] Sent: Saturday, March 31, 2007 9:57 PM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Information regarding -fPIC support for Interix gcc 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 >
ass
Description: ass
lib1.s
Description: lib1.s
