[PATCH] D97409: [dfsan] Record dfsan metadata in globals
George Balatsouras via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 25 16:18:10 PST 2021
gbalats added inline comments.
================
Comment at: llvm/lib/Transforms/Instrumentation/DataFlowSanitizer.cpp:1224
+ (void)Mod->getOrInsertGlobal(
+ "__dfsan_shadow_width_bits", PrimitiveShadowTy, [&] {
+ auto *GV = new GlobalVariable(
----------------
morehouse wrote:
> gbalats wrote:
> > morehouse wrote:
> > > If these globals have `PrimitiveShadowTy` type, will we have to declare multiple weak globals in the runtime (i.e. one that's int8 and one thats int16)?
> > >
> > > Why not make it an `int` or `size_t` to simplify the runtime side?
> > I'm not yet familiar with how the runtime integration works. Is there a reason why the runtime has to mirror these using exactly the same type instead of e.g. int32?
> >
> > The only reason to use `PrimitiveShadowTy` here, instead of `i8`, is to make testing easier so that by matching just one variable one can extract both the `i16` and `16` parts to use later in the test:
> >
> > ```
> > ; CHECK: @__dfsan_shadow_width_bits = weak_odr constant [[ST:i[0-9]+]] [[#SBITS:]], align {{[1-2]}}
> > ```
> >
> > Of course, you could use `i[[SBITS]]` instead of `[[ST]]` but it would be cumbersome. Alternatively, we could use a different global to extract the shadow type, though I'm not sure which one (it would have to be generated in all option combinations; perhaps one of the callback functions).
> If the linker does not give an explicit error, I believe it is still undefined behavior to link two symbols of the same name with different types.
>
> I would prefer using a single standard type across runtime/instrumentation and extracting the `SBITS` value in tests.
>
> Also, I don't see much use for `__dfsan_shadow_width_bytes` since it isn't used in tests and its value can be easily obtained in the runtime from `__dfsan_shadow_width_bits`.
Changed to i32. Updated tests to use SBITS instead.
Regarding the usefulness of the `__dfsan_shadow_width_bytes`, it is in fact used in tests. Right now it's hardcoded to 2 in several places, like alignments of some alloca/load/store instructions that operate on a shadow. These would be change to [[#SBYTES]].
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D97409/new/
https://reviews.llvm.org/D97409
More information about the llvm-commits
mailing list