[cfe-dev] Getting clang to give dwarf info for macro expansions?
David Blaikie
dblaikie at gmail.com
Tue Nov 11 09:30:57 PST 2014
On Tue, Nov 11, 2014 at 9:22 AM, Robinson, Paul <
Paul_Robinson at playstation.sony.com> wrote:
> > From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu]
> On Behalf Of David Blaikie
> > > On Mon, Nov 10, 2014 at 3:41 PM, Christian Convey <
> christian.convey at gmail.com> wrote:
> > > Thanks David. I'm certainly no dwarf expert, but I was wondering if
> > > we could just have something like this:
> > >
> > > foo.c:6:1
> > > (various machine instructions)
> > > bar.h:20
> > > (some machine instruction resulting from a macro call at, for example,
> > > line 7 of foo.c)
> > > foo.c:8:1
> > > (more machine instructions)
> >
> > Yeah, I haven't experimented with that - it's something that could be
> tried
> > (not high enough on my list) but I suspect would be confusing to users,
> > because they'd have no context as to where in the actual function they
> were
> > (if the macro was used twice, which macro instantiation were they in,
> etc).
>
> If your debugger is showing the equivalent of disassembly with interspersed
> source, that's not a problem. The macro definition shows up twice, each
> case
> attached to the instructions for that use of the macro. It's not
> intrinsically
> much different from multiple inlined calls to the same function.
>
Well the major difference is that with inlined call information you can use
"bt" to see the context (which call site the inlined subroutine came from).
>
> >
> > > Anyway, I'm not proposing a modification. I was just curious if there
> > > was some existing way to get better insight into the object code
> > > associated with macro-generated source.
> >
> > I believe the short answer is: no, there is no existing way to get better
> > insight into code from macros. (but I could be wrong)
>
> I suppose you could preprocess the source, filter out the #line directives,
> and then build/debug the preprocessed source, but that's probably more work
> for less gain than you really want.
> --paulr
>
> >
> > - David
>
>
> On Mon, Nov 10, 2014 at 6:35 PM, David Blaikie <dblaikie at gmail.com> wrote:
> > DWARF doesn't really have a way to describe multiple source locations
> for a
> > single instruction, so far as I know.
> >
> > I imagine we could add something like DW_TAG_inlined_subroutine (though
> it
> > wouldn't be quite as simple, since they're not necessarily strictly
> nested),
> > and/or the new two-level line tables that're being proposed/worked on.
> >
> > DWARF does have a macro section, but I believe this is just to describe
> the
> > original macro templates (so you can use them in debugger expressions,
> etc)
> > not to provide source fidelity for macro uses.
> >
> > - David
> >
> > On Sun, Nov 9, 2014 at 1:53 PM, Christian Convey
> > <christian.convey at gmail.com> wrote:
> >>
> >> Does anyone know if/how I can get clang to generate dwarf information
> >> that lets me trace / debug *into* macro-generated code?
> >>
> >> It seems that when a C program invokes a macro, all of the source code
> >> produced by that macro invocation is attributed to the line at which
> >> the macro is called. I've seen this in both dwarfdump and gdb, as
> >> described below. (The exception seems to be when a macro expansion
> >> causes the definition of a new function. That new function shows up
> >> in the dwarf info as one might hope.)
> >>
> >> What I'd ideally like is for tracing tools to clearly describe which
> >> branches within macro-generated code were taken. When all of the
> >> source code generated by a macro invocation is attributed to the macro
> >> *call* site by the dwarf information, that level of precision seems
> >> impossible.
> >>
> >> For example, suppose I have this code:
> >> >>>> foo.c
> >> #define FOO \
> >> if (x == 3) { \
> >> return 1; \
> >> }
> >>
> >> int bar(int x) {
> >> FOO
> >> return 0;
> >> }
> >> <<<<<
> >>
> >> And I compile it with this command:
> >> clang -c -g -Xclang -dwarf-column-info foo.c
> >>
> >> And I look at the dwarf information using the command:
> >> objdump -dgls foo.o
> >>
> >> I get this:
> >> ...
> >> Disassembly of section .text:
> >>
> >> 0000000000000000 <bar>:
> >> bar():
> >> /tmp/foo.c:6
> >> 0: 55 push %rbp
> >> 1: 48 89 e5 mov %rsp,%rbp
> >> 4: 89 7d f8 mov %edi,-0x8(%rbp)
> >> /tmp/foo.c:7
> >> 7: 81 7d f8 03 00 00 00 cmpl $0x3,-0x8(%rbp)
> >> e: 0f 85 0c 00 00 00 jne 20 <bar+0x20>
> >> 14: c7 45 fc 01 00 00 00 movl $0x1,-0x4(%rbp)
> >> 1b: e9 07 00 00 00 jmpq 27 <bar+0x27>
> >> /tmp/foo.c:8
> >> 20: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp)
> >> /tmp/foo.c:9
> >> 27: 8b 45 fc mov -0x4(%rbp),%eax
> >> 2a: 5d pop %rbp
> >> 2b: c3 retq
> >> ...
> >>
> >> Note that all of the reported source locations are in lines 6-9;
> >> nothing is attributed to lines 1-3.
> >>
> >> To double-check that I really can't get detailed trace information
> >> from macro-generated code, I added a main() function and stepped
> >> through the code with gdb. Here's what I got:
> >>
> >> (gdb) list
> >> 4 }
> >> 5
> >> 6 int bar(int x) {
> >> 7 FOO
> >> 8 return 0;
> >> 9 }
> >> 10
> >> 11 int main(int argc, const char* argv[] )
> >> 12 {
> >> 13 return bar( argc );
> >> (gdb) break main
> >> Breakpoint 1 at 0x4004d6: file foo.c, line 13.
> >> (gdb) run
> >> Starting program: /tmp/a.out
> >>
> >> Breakpoint 1, main (argc=1, argv=0x7fffffffdf98) at foo.c:13
> >> 13 return bar( argc );
> >> (gdb) step
> >> bar (x=1) at foo.c:7
> >> 7 FOO
> >> (gdb) step
> >> 8 return 0;
> >> (gdb) step
> >> 9 }
> >> (gdb) step
> >> __libc_start_main (main=0x4004c0 <main>, argc=1, argv=0x7fffffffdf98,
> >> init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
> >> stack_end=0x7fffffffdf88) at libc-start.c:321
> >> 321 libc-start.c: No such file or directory.
> >> (gdb)
> >> _______________________________________________
> >> cfe-dev mailing list
> >> cfe-dev at cs.uiuc.edu
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141111/1f2fcde2/attachment.html>
More information about the cfe-dev
mailing list