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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ldbug.tgz
Type: application/octet-stream
Size: 458 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20060201/1e040f2a/attachment.obj>
-------------- next part --------------
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