Hi Ian Thanks for replying. For Movl [EMAIL PROTECTED](%ebx,%eax),%eax --------> mov 0xffffbd14(%eax,%ebx,1),%eax
I verified that data contained in .rdata section is all wrong in my case with both my gcc3.3 compiler as well gcc4.3 compiler. This is why the jump happens to the wrong code which lies outside the function. Can you point me to the relevant section of gcc code which populates the .rdata section or calculates these values to be populated in there ? Thanks in advance . Mayank -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian Lance Taylor Sent: Tuesday, April 03, 2007 12:28 AM To: Mayank Kumar Cc: gcc@gcc.gnu.org Subject: Re: Information regarding -fPIC support for Interix gcc Mayank Kumar <[EMAIL PROTECTED]> writes: > 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. 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
