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

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.