This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Information regarding -fPIC support for Interix gcc
- From: Ian Lance Taylor <iant at google dot com>
- To: Mayank Kumar <mayank at microsoft dot com>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: 02 Apr 2007 11:58:18 -0700
- Subject: Re: Information regarding -fPIC support for Interix gcc
- References: <76EBE649FB0E0E4DA883B5840459059F143A3ECD29@AA-EXMSG-C412.southpacific.corp.microsoft.com> <20070322164930.GR5208@synopsys.com> <76EBE649FB0E0E4DA883B5840459059F143A3ECDBB@AA-EXMSG-C412.southpacific.corp.microsoft.com> <200703222054.26300.paul@codesourcery.com> <76EBE649FB0E0E4DA883B5840459059F143A3ECE71@AA-EXMSG-C412.southpacific.corp.microsoft.com> <m3mz24aqs9.fsf@localhost.localdomain> <76EBE649FB0E0E4DA883B5840459059F143A4C282F@AA-EXMSG-C412.southpacific.corp.microsoft.com> <7da171fd0703310926i57be4952vebd74b9602180d71@mail.gmail.com> <76EBE649FB0E0E4DA883B5840459059F143A4C28F7@AA-EXMSG-C412.southpacific.corp.microsoft.com>
Mayank Kumar <mayank@microsoft.com> writes:
> 1: I am keen on understanding how does the offset of L32 from _GLOBAL_OFFSET_TABLE_ generated ? I mean if assembly is
>
> Movl L32@GOTOFF(%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.
The calculation for the R_386_GOTOFF relocation is specified in the
i386 ELF ABI Processor Supplement. It should be the value of the
symbol L32 minus the start of the GOT. The start of the GOT is
defined by the value of _GLOBAL_OFFSET_TABLE_, and need not be the
start of the .got section.
The idea is that R_386_GOTOFF gives a position independent offset. It
is then added to the address of the global offset table to get the
actual offset.
> 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.
Presumably the values in the table are wrong or the values computed by
the relocations are wrong. Step through the code instruction by
instruction to see what is happening.
There are no secrets here. You have all the information required to
figure this out. If you have specific questions we may be able to
ansewr them, but it's difficult to answer general questions like why
something doesn't work.
Ian