[cfe-commits] [PATCH] PR14097, no debug info for artificial/'nodebug' methods
samsonov at google.com
Wed Oct 17 09:39:29 PDT 2012
On Wed, Oct 17, 2012 at 7:57 AM, Eric Christopher <echristo at gmail.com>wrote:
> > Yes it looks like our patches are at cross-purposes.
> > I assume that your patch gets the desired effect because there is now a
> DIE that
> > points to the subprogram's generated code? That's not good for me,
> because if
> > there's a class method definition DIE, it insists on having a
> declaration DIE too.
> > I'm not sure whether the same is true for standalone functions.
> > I wonder if there is a way we could produce an artificial subprogram
> DIE, but then
> > have LLVM not actually emit it to the DWARF. That is, suppress the
> excess DWARF
> > in LLVM rather than in Clang. If lives long enough to build the address
> ranges (and
> > also .debug_line?) it would meet your needs, and then if it doesn't
> actually get emitted
> > to .debug_info, it would meet my needs.
What are your needs? Do you want to keep the .debug_info smaller, or this
be malformed and cause problems for you? I'm somewhat afraid that data in
.debug_line would not be enough for me. This depends on the way a tool maps
instruction address to compile unit. One of the way is:
1) get the compile unit DIE
2) get a DWARF line table for this DIE
3) parse the table and build address ranges for this compile unit.
This (step 3) is of course inefficient.
Currently LLVM's DebugInfo lib does the following:
1) get the compile unit DIE
2) get all subprogram DIEs for this CU
3) collects address ranges for these subprograms.
So, for such an approach, I need the debug_info entries for artificial
functions and methods.
generated by Clang. I even may need entries for functions with disabled
info. What I don't need is the debug info for bodies of these functions
(all the local variables
Probably the best way is to use .debug_ranges section and add
a single DW_AT_ranges into the compile unit DIE. In this way we'll be able
to get all the instruction address ranges for compile unit without scanning
additional DIEs (or using weird .debug_aranges section).
> I'm more than happy to revert r158009, I originally added it to reduce
> the amount of debug information since often people would not be trying
> to add break points or debug through an artificial function. Alexey's
> patch and motivation, however, lead me to believe that this was
> originally incorrect as we may want a backtrace with information and
> line numbers that includes artificial functions like global
> Either of you have an argument against reverting it?
I have not.
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits