[llvm-dev] Obtaining the origin function for a local var after inlining
Adrian Prantl via llvm-dev
llvm-dev at lists.llvm.org
Mon Sep 17 16:56:13 PDT 2018
> On Sep 17, 2018, at 6:59 AM, Alexander Potapenko via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> (I think I've asked a similar question off-list a couple of times, but
> never got an answer)
>
> Hi folks,
>
> For [K]MSAN we need to figure out which inlined function a local var
> originally belonged to in the source file.
If you are looking at a llvm.dbg.declar/value/addr intrinsic, then the DILocation attached to the intrinsic indirectly points there:
DIScope *Scope = DILocation(dbg_intrinsic.getDebugLoc()).getScope();
while (!isa<DISubprogram>(Scope))
Scope = Scope->getScope();
auto *origFunction = cast<DIFunction>(Scope);
if you want to find the function that it was inlined *into* then you need to follow the inlinedAt link in the DILoation.
-- adrian
> E.g. when a local buffer %buf is declared in @bar(), but @bar() is
> inlined into @foo(), then there's a local %buf.i in @foo(), but we
> need to determine that the local came from @bar(). In the case of
> nested inline functions we need the deepest one.
>
> Is there any existing code for that? If not, which debug info
> constructs do we need to look up to get this information?
>
> https://llvm.org/docs/SourceLevelDebugging.html mentions
> @llvm.dbg.addr as the source of information about a local var, but the
> ToT Clang doesn't emit it. There're calls to @llvm.debug.declare in
> the IR, but it's said to be deprecated, so I'm not sure if it's ok to
> use it.
>
> Thanks in advance,
> --
> Alexander Potapenko
> Software Engineer
>
> Google Germany GmbH
> Erika-Mann-Straße, 33
> 80636 München
>
> Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
> Registergericht und -nummer: Hamburg, HRB 86891
> Sitz der Gesellschaft: Hamburg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
More information about the llvm-dev
mailing list