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

[Cary Coutant <ccoutant at gmail dot 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
> 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