ld fails to relocate relative to local symbols?

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

ld fails to relocate relative to local symbols?

Paul Lalonde
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have an application that uses ELF to encode it's binary data (for  
assorted reasons, the binary data need relocation and linkage - ELF  
already supports this well and has many tools).
In the process of emitting the data, it's frequently useful to  
relocate against a local symbol (yes, I know I could add them to a  
dictionary and do a second pass on my data to resolve them myself).  
However, if I add a local symbol to the symbol table, and then  a  
relocation relative to it ld seg faults when I try to link it.  If I  
change it to a global symbol all is well. (ld -r test.o seg faults as  
well)
Is is the expected behaviour (well, not the seg fault, but at least  
not handling relocation relative to a local symbol)?

My environment is fedora core 4 on AMD64.  I'm running  
binutils-2.15.94.0.2.2.  The relocation type is R_X86_64_64.

Thanks,
     Paul

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFD3/5tr7+oA6AsvAkRArZ7AKCkRkP+gDnix3pzX0tNVW1MVjASbwCgl5to
Lwak/yF/mR7w5rmGGJsLvds=
=GCiH
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: ld fails to relocate relative to local symbols?

H.J. Lu-27
On Tue, Jan 31, 2006 at 04:18:53PM -0800, Paul Lalonde wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have an application that uses ELF to encode it's binary data (for  
> assorted reasons, the binary data need relocation and linkage - ELF  
> already supports this well and has many tools).
> In the process of emitting the data, it's frequently useful to  
> relocate against a local symbol (yes, I know I could add them to a  
> dictionary and do a second pass on my data to resolve them myself).  
> However, if I add a local symbol to the symbol table, and then  a  
> relocation relative to it ld seg faults when I try to link it.  If I  
> change it to a global symbol all is well. (ld -r test.o seg faults as  
> well)
> Is is the expected behaviour (well, not the seg fault, but at least  
> not handling relocation relative to a local symbol)?
>

Please open a bug report at

http://www.sourceware.org/bugzilla/

with a small testcase.


H.J.
Reply | Threaded
Open this post in threaded view
|

Re: ld fails to relocate relative to local symbols?

Daniel Jacobowitz-2
In reply to this post by Paul Lalonde
On Tue, Jan 31, 2006 at 04:18:53PM -0800, Paul Lalonde wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I have an application that uses ELF to encode it's binary data (for  
> assorted reasons, the binary data need relocation and linkage - ELF  
> already supports this well and has many tools).
> In the process of emitting the data, it's frequently useful to  
> relocate against a local symbol (yes, I know I could add them to a  
> dictionary and do a second pass on my data to resolve them myself).  
> However, if I add a local symbol to the symbol table, and then  a  
> relocation relative to it ld seg faults when I try to link it.  If I  
> change it to a global symbol all is well. (ld -r test.o seg faults as  
> well)
> Is is the expected behaviour (well, not the seg fault, but at least  
> not handling relocation relative to a local symbol)?

Of course not.  You need to be more specific - preferably with a small,
reproducible test case.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: ld fails to relocate relative to local symbols?

Paul Lalonde
I've just filed a bug, but for anyone who's keen on finding out how I  
broke it, here's a tgz containing two .o's for AMD64.
ld -r success.o succeeds, ld -r fail.o fails.  The files differ in  
exactly one byte, the change of symbol "mystring" from STB_GLOBAL to  
STB_LOCAL.
It's most likely that I'm violating the ABI in some (not necessarily  
subtle) way, although the seg fault is disconcerting.

Paul

On 31-Jan-06, at 6:02 PM, Daniel Jacobowitz wrote:

> On Tue, Jan 31, 2006 at 04:18:53PM -0800, Paul Lalonde wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I have an application that uses ELF to encode it's binary data (for
>> assorted reasons, the binary data need relocation and linkage - ELF
>> already supports this well and has many tools).
>> In the process of emitting the data, it's frequently useful to
>> relocate against a local symbol (yes, I know I could add them to a
>> dictionary and do a second pass on my data to resolve them myself).
>> However, if I add a local symbol to the symbol table, and then  a
>> relocation relative to it ld seg faults when I try to link it.  If I
>> change it to a global symbol all is well. (ld -r test.o seg faults as
>> well)
>> Is is the expected behaviour (well, not the seg fault, but at least
>> not handling relocation relative to a local symbol)?
>
> Of course not.  You need to be more specific - preferably with a  
> small,
> reproducible test case.
>
> --
> Daniel Jacobowitz
> CodeSourcery


ldbug.tgz (634 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ld fails to relocate relative to local symbols?

Daniel Jacobowitz-2
On Tue, Jan 31, 2006 at 06:09:18PM -0800, Paul Lalonde wrote:
> I've just filed a bug, but for anyone who's keen on finding out how I  
> broke it, here's a tgz containing two .o's for AMD64.
> ld -r success.o succeeds, ld -r fail.o fails.  The files differ in  
> exactly one byte, the change of symbol "mystring" from STB_GLOBAL to  
> STB_LOCAL.
> It's most likely that I'm violating the ABI in some (not necessarily  
> subtle) way, although the seg fault is disconcerting.

How are you creating these files, anyway?  Your own ELF library?
fail.o's incorrect: st_info on a symtab section is supposed to be one
greater than the index of the last local symbol.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: ld fails to relocate relative to local symbols?

Paul Lalonde
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks!  Fixed it.

Can you point me to the document that documents that one?

And yes, it is my own restricted ELF library - for assorted reasons  
we can't use a GPL one, and the alternatives are few.

Thanks again, and I'll close the bug, mea culpa.

Paul

On 31-Jan-06, at 7:43 PM, Daniel Jacobowitz wrote:

> On Tue, Jan 31, 2006 at 06:09:18PM -0800, Paul Lalonde wrote:
>> I've just filed a bug, but for anyone who's keen on finding out how I
>> broke it, here's a tgz containing two .o's for AMD64.
>> ld -r success.o succeeds, ld -r fail.o fails.  The files differ in
>> exactly one byte, the change of symbol "mystring" from STB_GLOBAL to
>> STB_LOCAL.
>> It's most likely that I'm violating the ABI in some (not necessarily
>> subtle) way, although the seg fault is disconcerting.
>
> How are you creating these files, anyway?  Your own ELF library?
> fail.o's incorrect: st_info on a symtab section is supposed to be one
> greater than the index of the last local symbol.
>
> --
> Daniel Jacobowitz
> CodeSourcery

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFD4C/7r7+oA6AsvAkRAt6AAJ9IrsGeH3K1WCWMz3qSX5WIq0nZXQCfdDds
fjX4O053gS91SEZBdVclmK0=
=/iaq
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: ld fails to relocate relative to local symbols?

Daniel Jacobowitz-2
On Tue, Jan 31, 2006 at 07:50:18PM -0800, Paul Lalonde wrote:
> Can you point me to the document that documents that one?

The ELF gABI (the g is for global); you can find a copy on SCO's web
site, they still maintain the master copies of these standards.

> And yes, it is my own restricted ELF library - for assorted reasons  
> we can't use a GPL one, and the alternatives are few.

FWIW:
  http://www.stud.uni-hannover.de/~michael/software/libelf-0.8.5.tar.gz

That's LGPL, not GPL.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

RE: ld fails to relocate relative to local symbols?

Dave Korn
On 01 February 2006 03:57, Daniel Jacobowitz wrote:

> On Tue, Jan 31, 2006 at 07:50:18PM -0800, Paul Lalonde wrote:
>> Can you point me to the document that documents that one?
>
> The ELF gABI (the g is for global); you can find a copy on SCO's web
> site, they still maintain the master copies of these standards.

  Umm, is that safe?  If I read their website and then implement an ELF library/abi-conformant widget/whatever, will they claim it's
now contaminated with their IP and I must license it from them?  Or have they made the spec public?

>> And yes, it is my own restricted ELF library - for assorted reasons we
>> can't use a GPL one, and the alternatives are few.
>
> FWIW:
>   http://www.stud.uni-hannover.de/~michael/software/libelf-0.8.5.tar.gz
>
> That's LGPL, not GPL.

  Actually it's neither GPL nor LGPL.  It's 404!  (If you strip the trailing filename from the url you get a redirect page to
http://www.mr511.de/software/).


    cheers,
      DaveK
--
Can't think of a witty .sigline today....

Reply | Threaded
Open this post in threaded view
|

Re: ld fails to relocate relative to local symbols?

Ian Lance Taylor
"Dave Korn" <[hidden email]> writes:

> On 01 February 2006 03:57, Daniel Jacobowitz wrote:
>
> > On Tue, Jan 31, 2006 at 07:50:18PM -0800, Paul Lalonde wrote:
> >> Can you point me to the document that documents that one?
> >
> > The ELF gABI (the g is for global); you can find a copy on SCO's web
> > site, they still maintain the master copies of these standards.
>
>   Umm, is that safe?  If I read their website and then implement an ELF library/abi-conformant widget/whatever, will they claim it's
> now contaminated with their IP and I must license it from them?  Or have they made the spec public?

In fact I think one of their claims was on a header file defining
standard constants, though I don't recall if it was ELF related
constants or not.

In any case, there is no meaningful alternative on the horizon.  We
all implement ELF now (except Apple), and ELF is based on specs for
which SCO now owns the rights (unless Novell does--I'm not sure what
the status is on that).  We could switch if we had to, but it would be
a pointless exercise to switch before we are forced.  At the present
rate it doesn't seem like SCO will be around for more than a couple
more years.

Ian