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

Alex Brachet via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 5 20:05:35 PDT 2022


abrachet added a comment.

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

> It is more like: "we do not care much about which st_size to use, but I prefer the way with little complexity".

I've updated this patch with a more permanent solution. I think how it is now, the complexity is not a large concern. WDYT?

> This patch tries to change the status quo with a bit more complexity, so I'd challenge it with the justification.
> Your llvm-ifs argument in the comment would make a better summary, but see below I have a minor concern with regard to copy relocations.
> In addition, asan instruments global variables so the ABI is different anyway. I do not see a very justification that unifying the two cases.

I think in this case it is important that llvm-ifs report the same abi when building with either gcc or clang. These abi checking tools would already report an abi difference between instrumented binaries because of the addition of the __asan_* symbols.

>> In what cases do you imagine it would be useful to quickly see whether an area has been enlarged?
>
> Mixing instrumented and uninstrumented global variables are error-prone, so knowing whether some have actually different IR sizes helps debugging if a program breaks.
> Also imagine the scenario that asan improves to place some non-zero data into the trailing redzone, then this approach will actually break copy relocations.

This is true. But I don't think the potential for future work should block this. That would be a large overhaul to asan, it could easily remove the 4 lines that emit the explicit_size metadata tag when it's semantics change.


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

https://reviews.llvm.org/D123010



More information about the llvm-commits mailing list