[LLVMdev] Debug Info and DFSan

[David Blaikie]

On Tue, Oct 7, 2014 at 11:48 AM, Peter Collingbourne <peter at pcc.me.uk>
wrote:

> On Tue, Oct 07, 2014 at 10:04:30AM -0700, David Blaikie wrote:
> > Hi Peter,
> >
> > After discovering several bugs in ArgumentPromotion and
> > DeadArgumentElimination where llvm::Functions were replaced with similar
> > functions (with the same name) to transform their type in some way, I
> > started looking at all calls to llvm::Function::takeName to see if there
> > were any other debug info quality bugs in similar callers.
> >
> > One such caller is the DataFlowSanitizer, and I don't see any debug info
> > tests for this so I'm wondering what /should/ happen here.
> >
> > Is DFSan+DebugInfo something that matters? I assume so.
>
> It may be important in the future, but at the moment the dfsan runtime
> library
> does not make use of debug info. The debug info could still be useful for
> regular debugging tasks though.
>

Yeah - that'd be the baseline. I assume some people probably care about
being able to debug a dfsan binary. Not sure if your users have
specifically highlighted this situation or come across the bugs I'm
speculating about.


> > It looks like DFSan is creating wrappers (in/around
> > DataFlowSanitizer.cpp:680-700) - when it does this, should it update the
> > debug info for these functions? Or are these internal instrumentation
> > functions & nothing to do with the code the user wrote? I can't quite
> tell
> > from the code.
>
> The functions created by that part of the code replace the original
> functions,
> so they should inherit the debug info for those functions.
>

Yep, that won't happen for free - we have to stitch it back into the debug
info.


> But the code below that can also create wrapper functions which do not need
> debug info (lines 712-746). Wrappers normally show up for uninstrumented
> functions (e.g. main and many libc functions).
>
> > Could you provide any C/C++ source examples whis part of DFSan fires
> > reliably, so I could experiment with some examples and see how the debug
> > info looks?
>
> This is an example of a program that exercises the replacement function and
> wrapper features.
>
>
> --------------------------------------------------------------------------------
> #include <stddef.h>
> #include <string.h>
>
> size_t len(size_t (*strlen_ptr)(const char *), const char *str) {
>   return strlen_ptr(str);
> }
>
> int main(void) {
>   return len(strlen, "foo");
> }
>
> --------------------------------------------------------------------------------
>
> In this example, 'len' is rewritten to 'dfs$len', 'main' keeps its original
> name (the pass treats it as an uninstrumented function), and wrappers are
> created for 'main' and 'strlen' (the wrapper for 'main' is unused as the
> C runtime calls the regular 'main' function directly).
>

OK, so when you say wrappers are created - where does the name go? "main"
keeps the name? (it's important which way this transformation is done - if
the guts of main are moved to a new function and the name moved as well,
that's not the same as keeping the same function as far as debug info
metadata is concerned)


> I compile this with '-O0 -g'. A 'break main'/'run'/'break strlen'/'cont'
> gives a relevant stack trace:
>
> #0  __strlen_sse2_pminub () at
> ../sysdeps/x86_64/multiarch/strlen-sse2-pminub.S:33
> #1  0x00005555555587ff in __dfsw_strlen (s=0x55555556fe17 "foo",
> s_label=<optimized out>, ret_label=0x7fffffffddee)
>     at llvm/projects/compiler-rt/lib/dfsan/dfsan_custom.cc:203
> #2  0x000055555556bbdc in dfsw$strlen ()
> #3  0x000055555556bb51 in len (strlen_ptr=0x55555556bbc0 <dfsw$strlen>,
> str=0x55555556fe17 "foo") at strlen.c:5
> #4  0x000055555556bb96 in main ()
>
> In this stack trace, #2 is the compiler-generated wrapper function for
> strlen.
>
> It looks like the debug info for 'len' is preserved correctly, but I don't
> know why the debug info for 'main' is missing.
>

Yeah - not quite sure either. I'll poke around with it for a little bit.


>
> Thanks,
> --
> Peter
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141007/40eb8913/attachment.html>