[PATCH] D65893: [llvm-objcopy] Allow the visibility of the start, end and size symbols created by --binary to be specified with --binary-symbol-visibility

[Chris Jackson via Phabricator via llvm-commits]

chrisjackson added a comment.

In D65893#1623031 <https://reviews.llvm.org/D65893#1623031>, @MaskRay wrote:

> In D65893#1622790 <https://reviews.llvm.org/D65893#1622790>, @chrisjackson wrote:
>
> > In D65893#1620711 <https://reviews.llvm.org/D65893#1620711>, @MaskRay wrote:
> >
> > > Quote gABI:
> > >
> > > > Second, if any reference to or definition of a name is a symbol with a non-default visibility attribute, the visibility attribute must be propagated to the resolving symbol in the linked object. If different visibility attributes are specified for distinct references to or definitions of a symbol, the most constraining visibility attribute must be propagated to the resolving symbol in the linked object. The attributes, ordered from least to most constraining, are: STV_PROTECTED, STV_HIDDEN and STV_INTERNAL.
> > >
> > > You can achieve the same with: `__attribute__((visibility("hidden"))) extern char _binary_a_start[];` So I'm not sure why another option is needed (I think my another concern is that the option name `--binary-symbol-visibility` can make people puzzled if they add/delete/change symbols). See D55682 <https://reviews.llvm.org/D55682>.
> >
> >
> > Three symbols per embedding in an object results in bloated output.
>
>
> I don't understand this point. How can the visibility change de-bloat the output?
>
> > Preventing this with many attribute statements seems like a clumsy approach.
>
> I don't understand this, either. Your are going to reference `_binary_a_start`, (`_binary_a_end` or `_binary_a_size`) - two undefined symbols. Restrict the undefined symbol with a visibility attribute, then the linked exe/dso will change the symbol bindings accordingly. What's the problem?
>
> > With regards to the confusing option, we can just decide on a better name.
>
> We can do that once we decide this option is useful.


Apologies, I misunderstood and phrased that poorly. Trying again, the desire for the option is because:

- For our use cases it is more convenient to change the symbol's visibility with an option than to have users alter their source code.
- As --add-symbol allows visibility to be specified, it seems reasonable to also allow the visibility of the generated symbols to be controllable too.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65893/new/

https://reviews.llvm.org/D65893