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

James Henderson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 19 03:21:05 PDT 2019


jhenderson added a comment.

@chrisjackson and I work in the same team for Sony on the PlayStation toolchain, but our required semantics looks to be similar to the published ones in the Kiel documentation he mentioned.

Regardless, I realised something on Friday that means that a switch is essentially a requirement. You cannot be guaranteed to have references to all three symbols in your source code. A typical usage might look something like this:

  extern uint8_t *_binary_start; // actually the symbol name from the binary input object
  extern uint8_t *_binary_end;
  
  for (uint8_t C = _binary_start; C != _binary_end; ++C) {
    // do something with C
  }

You can certainly decorate those two symbols with a visibility attribute, as you suggested before. However, what you can't do is specify a visibility for them if they aren't referenced:

  __attribute__((visibility("hidden")))
  extern uint8_t *_binary_start; // referenced
  __attribute__((visibility("hidden")))
  extern uint8_t *_binary_end; // referenced
  __attribute__((visibility("hidden")))
  extern uint64_t _binary_size; // unreferenced

The above will result in the first two symbols being marked STV_HIDDEN, but the third symbol will not appear in the object file, as it is unreferenced (and introducing an artificial reference may or may not work depending on compiler optimizations etc). This means that when the binary input object gets linked together with this object, there will be nothing overriding the STV_DEFAULT visibility of the third symbol, meaning it gets exported. There is nothing apart from changing the visibility of the symbols in that object that can prevent this. As a result, I think a --symbol-visibility switch as described above in llvm-objcopy would be very useful. A --redefine-visibility switch could also be useful potentially, but is a little trickier to use, since it would require potentially being specified two or three times, whereas a --symbol-visibility switch would only need specifying once (and could also be used to change the default visibility of --add-symbol specified symbols, simplifying users' command-lines).


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

https://reviews.llvm.org/D65893





More information about the llvm-commits mailing list