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

[H.J. Lu]

On Tue, Feb 1, 2011 at 3:11 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
> 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.
>

Well, part of linking is implemented in BFD. BFD may use the plugin
dummy information.

-- 
H.J.