Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: David Daney <david.daney@cavium.com>
To: binutils <binutils@sourceware.org>,
	rdsandiford@googlemail.com, Alan Modra <amodra@gmail.com>
Cc: linux-mips <linux-mips@linux-mips.org>,
	Manuel Lauss <manuel.lauss@googlemail.com>,
	Debian MIPS <debian-mips@lists.debian.org>
Subject: Re: [Patch]: Fix ld pr11138 FAILures on mips*.
Date: Tue, 06 Dec 2011 14:13:07 -0800	[thread overview]
Message-ID: <4EDE9373.4070707@cavium.com> (raw)
In-Reply-To: <8762ht2yft.fsf@firetop.home>

On 12/06/2011 01:16 PM, Richard Sandiford wrote:
> Alan Modra<amodra@gmail.com>  writes:
>> On Mon, Dec 05, 2011 at 04:49:35PM -0800, David Daney wrote:
>>> The root cause of this is that the mips linker synthesizes a special
>>> symbol "__RLD_MAP", and then sets MIPS_RLD_MAP to point to it.  When
>>> a version script is present, this symbol gets versioned along with
>>> all the rest, and when it is time to take its address, the symbol
>>> can no longer be found as it has had version information appended to
>>> its name.
>>
>> Why not just change
>>
>> 	&&  (strcmp (name, "__rld_map") == 0
>> 	      || strcmp (name, "__RLD_MAP") == 0))
>>
>> to
>>
>> 	&&  (strncmp (name, "__rld_map", 9) == 0
>> 	      || strncmp (name, "__RLD_MAP", 9) == 0))
>>
>> in _bfd_mips_elf_finish_dynamic_symbol?  Perhaps the same for other
>> syms there too?
>
> Showing my ignorance here,

I don't buy it, you are probably the most knowledgeable about this.

> but is that the usual behaviour for this kind
> of thing?  I wouldn't have expected versions to apply to internally-created
> symbols.

Yes, that is what I was trying to accomplish.

>
> There again, is this symbol (as opposed to the DT_MIPS_RLD_MAP tag)
> actually part of the ABI?  I can't find any reference to it in the
> original psABI, the SGI ELF64 spec, gdb or glibc.  If it's just an
> internal thing, maybe we could get rid of it altogether, or at least
> make it bind locally rather than globally.
>

That is an option too I suppose.  I would say that it is part of a de 
facto ABI if nothing else.  The question of weather anybody uses it it a 
different question.  I thought boehm-gc may have used it, but I cannot 
find it there now.

I don't know for sure why the symbol was created, but it seems like it 
may just be for the side effect of having 
_bfd_mips_elf_finish_dynamic_symbol() called.  This lets us determine 
mips_elf_hash_table(info)->rld_value at a time when the output sections 
have already been laid out.

It might be possible to #define elf_backend_output_arch_local_syms and 
then handle calculation of the rld_value value there instead.

If this seems like a good approach, I can prepare and test a patch that 
does that.

David Daney

  reply	other threads:[~2011-12-06 22:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-06  0:49 [Patch]: Fix ld pr11138 FAILures on mips* David Daney
2011-12-06  5:40 ` Alan Modra
2011-12-06 20:20   ` David Daney
2011-12-06 23:43     ` Alan Modra
2011-12-06 21:16   ` Richard Sandiford
2011-12-06 22:13     ` David Daney [this message]
2011-12-08 20:34       ` Richard Sandiford
2011-12-08 20:53         ` David Daney
2011-12-07  0:07     ` 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=4EDE9373.4070707@cavium.com \
    --to=david.daney@cavium.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=debian-mips@lists.debian.org \
    --cc=linux-mips@linux-mips.org \
    --cc=manuel.lauss@googlemail.com \
    --cc=rdsandiford@googlemail.com \
    /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