This is the mail archive of the 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 Mon, Nov 27, 2017 at 10:31 PM, Cary Coutant <> wrote:

> >>      LLVM ThinLTO needs a gold plugin API to get the list of symbols
> that
> >> are wrapped using the --wrap option to avoid garbage collection of some
> of
> >> the associated functions like __wrap_symbol and __real_symbol.
> >>
> >>      This patch adds an interface, get_wrap_symbols, to get the count
> and
> >> the list of symbols that are wrapped.
> 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?

> 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.

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

> Assuming this is what you want...

I'll let Sri comment on the rest.


> +  std::vector<const char *> wrapped_symbols;
> +  uint64_t total = 0;
> +
> +  for (options::String_set::const_iterator
> +       it = parameters->options().wrap_begin();
> +       it != parameters->options().wrap_end(); ++it) {
> +    total++;
> +    wrapped_symbols.push_back(it->c_str());
> +  }
> total is redundant -- just use wrapped_symbols.size().
> Furthermore, if you add an extra member function to DEFINE_set that
> exposes the String_set::size() method, e.g.:
>   options::String_set::size_type
>   varname__##_size() const
>   { return this->varname__##_.value.size(); }
> ... you could avoid copying to and from the intermediate vector.
> (I *think* all of the various alternative implementations we might use
> for Unordered_set provide a constant-time size() method.)
> -cary

Teresa Johnson |  Software Engineer | |  408-460-2413

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