Issues with gcc Assembler on Interix when generating PIC code

Issues with gcc Assembler on Interix when generating PIC code

[Mayank Kumar]

Hi All
While testing fPIC support on interix ported gcc, I came across a bug. The bug appears only when the switch case generates a jump table in assembly. When this happens the fPIC compiled shared library crashes because the jump targets in the jump table are all wrong. After some debugging, I have been able to localize the bug. The issue is in the assembler. When I create a object file using the assembler(as test.s -o test.o), the contents of .rdata which contains the jump table is all wrong.

The assembly file:-
        .section        .rdata,"r"
        .balign 4
L8:
        .long   L2@GOTOFF
        .long   L3@GOTOFF
        .long   L4@GOTOFF
        .long   L5@GOTOFF
        .long   L6@GOTOFF
        .long   L7@GOTOFF

The object file generated by assembly(the contents of .rdata) Contents of section .rdata:
 0000 99000000 32000000 47000000 5c000000  ....2...G...\...
 0010 71000000 86000000                    q.......

Values of symbol L2-L7
00000099 t L2
00000032 t L3
00000047 t L4
0000005c t L5
00000071 t L6
00000086 t L7

Basically the assembly file shows, that the contents of .rdata are value of Labels relative to GOT but in the assembly phase since GOT is not defined, the contents of .rdata should have been all zeroes(as was the case for elf binaries on a bsd box) but for interix coff binaries, the contents are actually values of labels.

When this objects gets further linked to become a shared library, the GOT gets defined and hence the value Label-GOT(I mean L2-GOT or L3-GOT or L4-GOT) gets added to the contents of .rdata hence giving wrong jump targets for switch case.

I have fixed this temporarily in bfd_install_relocation but I know that this is not the place where the fix should be.

Now I could not figure out how this case is handled in elf binaries and where in the code ? If somebody can point me to the code where and how elf takes care of the above scenario , I could make a similar fix for coff binaries.
Any help here is appreciated,

Thanks
Mayank

Re: Issues with gcc Assembler on Interix when generating PIC code

[Alan Modra]

On Wed, Apr 11, 2007 at 03:44:49AM +0800, Mayank Kumar wrote:
> Now I could not figure out how this case is handled in elf binaries

See md_apply_fix.

      case BFD_RELOC_386_GOT32:
      case BFD_RELOC_X86_64_GOT32:
	value = 0; /* Fully resolved at runtime.  No addend.  */
	break;

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

RE: Issues with gcc Assembler on Interix when generating PIC code

[Mayank Kumar]

Hi Alan
Thanks for the information. At last somebody replied.
For my case in hand,

The assembly file:-
        .section        .rdata,"r"
        .balign 4
L8:
        .long   L2@GOTOFF
        .long   L3@GOTOFF
        .long   L4@GOTOFF
        .long   L5@GOTOFF
        .long   L6@GOTOFF
        .long   L7@GOTOFF

The relocation type is BFD_RELOC_386_GOTOFF and not BFD_RELOC_386_GOT32 and I don't see any case for this relocation type for elf as well in md_apply_fix. How is this handled ?


Thanks
Mayank

-----Original Message-----
From: binutils-owner@sourceware.org [mailto:binutils-owner@sourceware.org] On Behalf Of Alan Modra
Sent: Monday, April 23, 2007 5:25 AM
To: Mayank Kumar
Cc: binutils@sourceware.org
Subject: Re: Issues with gcc Assembler on Interix when generating PIC code

On Wed, Apr 11, 2007 at 03:44:49AM +0800, Mayank Kumar wrote:
> Now I could not figure out how this case is handled in elf binaries

See md_apply_fix.

      case BFD_RELOC_386_GOT32:
      case BFD_RELOC_X86_64_GOT32:
        value = 0; /* Fully resolved at runtime.  No addend.  */
        break;

--
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Issues with gcc Assembler on Interix when generating PIC code

[Alan Modra]

On Mon, Apr 23, 2007 at 04:32:23PM +0800, Mayank Kumar wrote:
> At last somebody replied.

A pity I answered a different question though.  :-(

> The relocation type is BFD_RELOC_386_GOTOFF and not BFD_RELOC_386_GOT32

OK..

1) tc_fix_adjustable ensures that the GOTOFF fixup keeps its symbol
   rather than being adjust to be against a section symbol.
2) MD_APPLY_SYM_VALUE stops the symbol value being added in to the
   value passed the md_apply_fix, so md_apply_fix always puts zero
   in the section contents.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

How to guarantee alignment for .comm and .lcomm defined variables

[Mayank Kumar]

Some platforms like interix and cygwin do not support the third argument to .comm/.lcomm which enables alignment of common variables defined in .bss section. Now i want to understand how we can guarantee that the object code generated would have these symbols aligned at lets say 16 byte boundary.
s_lcomm_internal takes a parameter needs_align and based on whether the third parameter was entered, records the largest alignment requested for .bss section. I did not see how guaranteeing the alignment of the .bss section for the largest alignment would also take care of the alignment requirement of symbols defined in .bss.

could somebody shed some light here?
How does other platforms implement the alignment for symbols defined in .bss section.

Thanks and regards
Mayank

Re: How to guarantee alignment for .comm and .lcomm defined variables

[Alan Modra]

.lcomm doesn't really create common symbols.  Instead you get a local
symbol in .bss that isn't any different from a local symbol allocated
in say, .data.  Allocation and alignment is done by the assembler.
Common symbols on the other hand are allocated (or merged with a
normal symbol) by the linker.  ELF common symbols have both size and
alignment.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre