Re: PATCH: PR ld/12277: Linker error: "final link failed: Nonrepresentable section on output"

[Dave Korn <dave dot korn dot cygwin at gmail dot com>]

On 01/02/2011 22:36, H.J. Lu wrote:
> On Tue, Feb 1, 2011 at 2:57 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>> On 01/02/2011 21:28, H.J. Lu wrote:
>>> On Tue, Feb 1, 2011 at 1:50 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>>>> On 01/02/2011 21:18, H.J. Lu wrote:
>>>>> It may work. But do you really need IRONLY_SUFFIX and
>>>>> IRONLY_SUFFIX_LEN?
>>>>  Perhaps not, but that's orthogonal; let's separate the two issues.  (Also,
>>>> it would still be nice if we could perhaps avoid changing bfd but find some
>>>> other way to recognize an IR dummy BFD when we see one; I'm not certain
>>>> whether that's possible yet though.)
>>>>
>>> Not really orthogonal.  Current way for checking IR dummy BFD is
>>> very expensive and unnecessary. It should be fixed first.
>>  As an alternative to adding a flag in BFD, we could equally just keep a hash
>> table of IR-only BFDs in ld/plugin.c and recognise them that way instead.
>> What do you think?
>>
> 
> It is still expensive. 

  You have a point, it can be called two or maybe three times per symbol.

> We should use a bit in BFD, which also makes that info available to BFD.

  Seems like layer-crossing to me.  This is the linker's plugin interface, not
BFD's; the information belongs to BFD's client application, not BFD.

  I need to see what we're doing with the BFD usrdata field.  A quick grep
suggests it points to the input statement, which if it can be relied on will
entirely obviate the need for either the suffix or an extra flag in BFD.

    cheers,
      DaveK