[PATCH] D123010: [WIP][asan] Emit .size directive for global object size before redzone

[Alex Brachet via Phabricator via llvm-commits]

abrachet added a comment.

In D123010#3425554 <https://reviews.llvm.org/D123010#3425554>, @MaskRay wrote:

> The enlarged st_size value gives users a quick way to know whether the area has been enlarged.

In what cases do you imagine it would be useful to quickly see whether an area has been enlarged? If anything this makes abi tracking mechanisms through nm, like what libcxx does, and we plan to do with compiler_rt with llvm-ifs more difficult because symbol sizes differ between clang and gcc. Granted compiler_rt is a bad example here because it cannot be itself sanitized, likewise libcxx doesn't track object sizes, however I think the point is still valid.

> This is insufficient justification to me. With compilation for executables moving from -fno-pic to -fpie, we cannot see copy relocations.
> Copy relocations really only happen with uncommon configurations now and decreasing st_size doesn't save many bytes any way. (Copy relocations can also be avoided with -fno-direct-access-external-data.)

Sure, I think regardless of rarity of the use-case it is objectively better to make copy relocations smaller for when they are used.

> I do not see why we need to match GCC's behavior here.

Matching GCC when their behavior is better seems like a worthy goal, especially if the cost to do so here isn't high. Do you expect the complexity of whatever solution this would end up with isn't worth the benefit?


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

https://reviews.llvm.org/D123010