This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: New gold plugin interface for getting --wrap symbols


On Fri, Dec 1, 2017 at 2:21 PM, Cary Coutant <ccoutant@gmail.com> wrote:
>>> There's a difference between the list of --wrap options passed to the
>>> linker (which is what this API returns), and a list of which symbols
>>> actually got wrapped.
>>
>> Can you clarify what cases would be different?
>
> The --wrap options are requests to wrap a symbol *if we see it*, so
> there may be symbols listed there that don't exist in the program.
>
>>> How is this useful compared to simply
>>> pattern-matching for symbols whose name begins with "__wrap" and
>>> "__real" (which will give you the symbols that were actually wrapped)?
>>
>> My concern is that this is a little hacky and would result in the plugin not
>> accurately reflecting the linker behavior. For ThinLTO we need to build an
>> accurate whole program graph, and want to reflect the wrapping that occurs
>> in the linker. If we pattern match but the user doesn't pass --wrap, for
>> example, that would be problematic.
>
> The __wrap_ and __real_ prefixes are in the namespace reserved for the
> system's use, so it shouldn't be a problem for valid programs.
>
> Still, I'm not objecting to the idea of querying for --wrap options --
> just pointing out the differences.
>
> I wonder if, as an alternative implementation, it might be reasonable
> to have the linker simply forward certain "interesting" options from
> its command line to the plugin as LDPT_OPTION entries in the transfer
> vector (as if they had also been written as --plugin-opt options). Or,
> since that might affect older plugins, we could make a new tag and
> pass them as LDPT_LINKER_OPTION entries.

This is interesting but I am afraid we may run the risk of writing
another option parser for the plugin.  I haven't thought about how to
do this.

>
>> As a side note, a follow-on patch is planned to get similar info to the
>> plugin for --defsym, for which pattern matching on symbol names won't
>> suffice.
>
> Yes, that will probably need a new interface. There's no similar issue
> here, though, since --defsym options always define the symbol. Since
> we record the origin of symbol definitions in the symbol table, I
> don't think you'd need or want to see the actual options -- you may
> just want a new field in ld_plugin_symbol, or a new API to query that
> attribute for each symbol.
>
> In addition to --defsym options, I'd think you'd also care about
> symbol assignments in scripts.
>
> -cary


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]