This is the mail archive of the
mailing list for the binutils project.
Re: New gold plugin interface for getting --wrap symbols
- From: Cary Coutant <ccoutant at gmail dot com>
- To: Teresa Johnson <tejohnson at google dot com>
- Cc: Sriraman Tallam <tmsriram at google dot com>, binutils <binutils at sourceware dot org>, Xinliang David Li <davidxl at google dot com>
- Date: Fri, 1 Dec 2017 14:21:19 -0800
- Subject: Re: New gold plugin interface for getting --wrap symbols
- Authentication-results: sourceware.org; auth=none
- References: <CAAs8Hmzq+11BitwNknrA8o6GNPXiWK+7asWU8rBaFRcsMs16_Q@mail.gmail.com> <CAAs8HmxjaR087175sZRAa19VUz6xca4j+oE8riH2uf0qRhStUA@mail.gmail.com> <CAJimCsHX_iis4cAMku73t=3n90wAhz+4mz4-FFd6+bA=qmMTqQ@mail.gmail.com> <CAAe5K+VjoCMNxSc+cKNxX+KO2nY+u9OZHERUhSZD6BTm6X-dLQ@mail.gmail.com>
>> 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.
> 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
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.