public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Mayank Kumar <mayank@microsoft.com>
To: "binutils@sourceware.org" <binutils@sourceware.org>
Subject: Issues with gcc Assembler on Interix when generating PIC code
Date: Tue, 10 Apr 2007 19:45:00 -0000	[thread overview]
Message-ID: <76EBE649FB0E0E4DA883B5840459059F1445C770D5@AA-EXMSG-C412.southpacific.corp.microsoft.com> (raw)

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


             reply	other threads:[~2007-04-10 19:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-10 19:45 Mayank Kumar [this message]
2007-04-23  6:47 ` Alan Modra
2007-04-23 10:05   ` Mayank Kumar
2007-04-23 11:59     ` Alan Modra
2007-04-23 19:55     ` How to guarantee alignment for .comm and .lcomm defined variables Mayank Kumar
2007-04-24 13:57       ` Alan Modra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=76EBE649FB0E0E4DA883B5840459059F1445C770D5@AA-EXMSG-C412.southpacific.corp.microsoft.com \
    --to=mayank@microsoft.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).