This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Wrong object file generated with -fPIC option 2.17 ported to Interix

From: Nick Clifton <nickc at redhat dot com>
To: Mayank Kumar <mayank at microsoft dot com>
Cc: "binutils at sources dot redhat dot com" <binutils at sources dot redhat dot com>
Date: Fri, 21 Sep 2007 08:24:38 +0100
Subject: Re: Wrong object file generated with -fPIC option 2.17 ported to Interix
References: <76EBE649FB0E0E4DA883B5840459059F1F02C7EF21@AA-EXMSG-C412.southpacific.corp.microsoft.com>

Hi Mayank,

An object file generated using -fPIC option has undefined symbols like the following:-
  U L10@GOTOFF
  U L12@GOTOFF

I also found that this is happening in the assembly phase. I did the following:-
 gcc  -S -fPIC file.c
 as -o file.o file.s
The object file generated have all the above as undefined symbol.

Just to be clear - it is gcc that is generating the references to these symbols, not the assembler. If you look at "file.s" you should see them there.

> I want to know what part of assembler or bfd code resolves these

labels so that I can debug more to find out why these undefined

> symbols are getting generated.

The "@GOTOFF" part of the symbol is a directive to the assembler telling it how the relocation for the symbol's value should be generated. See the function lex_get() in gas/config/tc-i386.c

Cheers
  Nick

References:
- Wrong object file generated with -fPIC option 2.17 ported to Interix
  - From: Mayank Kumar

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]