[PATCH] D102973: [ELF] Suppress GRP_COMDAT deduplication if the signature symbol is STB_LOCAL

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 27 00:27:15 PDT 2021


peter.smith added a comment.

Just one thing I notieced In D103043 <https://reviews.llvm.org/D103043>

  Beside the comdat any deduplication feature, instrumentations use comdat to
  establish dependencies among a group of sections, to prevent section based
  linker garbage collection from discarding some members without discarding all.
  LangRef acknowledges this usage with the following wording:

Do you actually need a COMDAT group in all those circumstances, i.e. do you need one group to prevail if there are multiple groups present with the same signature? Is one way to think about this:

- I can permit multiple instances of the same group in the object, the one-definition rule does not need to hold for this group. In this case don't set GRP_COMDAT for the group, just use a non COMDAT group.
- I need one COMDAT group to prevail but only within a single object file (STB_LOCAL signature symbol). In this case the object producer (compiler etc.) uniques the group, emits just one non COMDAT group, we achieve the same effect.

In either case, is the ELF behaviour preventing something useful, broken, or just being inconvenient?

While I agree that ELF could have been written differently, we have what has been written and if we deviate from that we risk compatibility problems. Compatibility even to an imperfect spec does have value, I'd personally prefer to stick to what is written at least in the default case. Do we know what the binutils people think? I'd be a lot more comfortable if there is agreement between the tools. Failing that then there is the possibility of a command line option or even a GRP_MASKOS flag to signify that the group should be treated differently.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102973



More information about the llvm-commits mailing list