[llvm] [ASAN] Add "sanitized_padded_global" llvm ir attribute to identify sanitizer instrumented globals (PR #68865)

via llvm-commits llvm-commits at lists.llvm.org
Wed Dec 20 01:15:57 PST 2023


skc7 wrote:





> (I will be out for about 2 weeks and my response time will be slow.)
> 
> Most object file formats don't have a symbol size field. Although ELF introduced `st_size`, it's scarcely utilized. Its primary use pertains to copy relocations, which are discouraged and gradually being phased out. The other, albeit minor, usage involves symbolization, where identifying whether `st_size` is zero can occasionally be helpful.
> 
> Consequently, I feel a bit nervous seeing a substantial reliance on `st_size`. I wonder whether you can avoid relying on this symbol field. I am not familiar with AMDGPU, but for other architectures, symbols are completely optional and can be freely stripped if they are not used for dynamic linking.
> 
> Here is an idea using a separate metadata section:
> 
> ```
> .quad sym[0].hash; .long sym[0].size; .quad sym[1].hash; .long sym[1].size; 
> ```
> 
> (You can even place `.quad sym[0].hash; .long sym[0].size` in a section `SHF_LINK_ORDER` linking to the global variable for linker garbage collection.)
> 
> The runtime can build a map correlating hashes to sizes, which can be used to answer variable size queries.

AMD language runtimes provide queries for the size of device global symbols and functions to copy data to and from device global variables. Currently, runtime gets the needed information form the ELF symbol sizes in the symbol table. So, in #70166 We have come up with approach of adding two symbols (at the same offset but with different sizes) for the same global, one symbol which reports actual global size and other symbol which reports instrumented size.

https://github.com/llvm/llvm-project/pull/68865


More information about the llvm-commits mailing list