[PATCH] D74369: [AddressSanitizer] Ensure only AllocaInst is passed to dbg.declare

Reid Kleckner via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 10 17:06:44 PST 2020


rnk added a comment.

I can think of several cases where non-alloca values are passed to dbg.declare, so if you want to make the verifier change, there's much more work to do. It might be better just to make the backends handle these cases.

Here is the most common case, passing non-trivially copyable objects by value:

  struct Foo {
    Foo();
    Foo(const Foo &o);
    ~Foo();
    int x;
  };
  int receiveFoo(Foo o) { return o.x; }

In this case, the C++ ABI passes the argument by address. Arguably, in this case, clang should do what it does for references: store the pointer into a stack slot and adjust the DIExpression to indicate that the stack slot contains an address, not a value.

The next most common would be `byval`:

  struct Foo {
    int x;
    int ys[6];
  };
  int receiveFoo(Foo o) { return o.x; }

In this case, `o` is already in memory, and it would be unreasonable for clang to copy it into a local alloca, since it could be large. The verifier should probably allow dbg.declare to point to a byval argument, since they are just stack objects for most targets.

The next case would be inalloca, which is like byval, but there is a GEP in the way. Compile example 1 with `--target=i686-windows-msvc`, and it looks like so:

  define dso_local i32 @"?receiveFoo@@YAHUFoo@@@Z"(<{ %struct.Foo }>* inalloca %0) #0 !dbg !8 {
  entry:
    %o = getelementptr inbounds <{ %struct.Foo }>, <{ %struct.Foo }>* %0, i32 0, i32 0
    call void @llvm.dbg.declare(metadata %struct.Foo* %o, metadata !25, metadata !DIExpression()), !dbg !26

This needs to keep working, although I have tried to come up with alternative designs: https://github.com/rnk/llvm-project/blob/call-setup-docs/llvm/docs/CallSetup.md

The next case I can think of would be this, ASan.

Next, safestack, which I believe also replaces static allocas.


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

https://reviews.llvm.org/D74369





More information about the llvm-commits mailing list