[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Information regarding -fPIC support for Interix gcc
From:       "Murali Vemulapati" <murali.vemulapati () gmail ! com>
Date:       2007-03-31 16:26:55
Message-ID: 7da171fd0703310926i57be4952vebd74b9602180d71 () mail ! gmail ! com
[Download RAW message or body]

On 3/31/07, Mayank Kumar <mayank@microsoft.com> 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    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 ?

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 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?

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: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
> 


[prev in list] [next in list] [prev in thread] [next in thread]