[llvm-dev] [DebugInfo][DWARFv5] should -gdwarf-5 imply usage of .debug_names?
Eric Christopher via llvm-dev
llvm-dev at lists.llvm.org
Fri Feb 17 11:39:38 PST 2017
On Fri, Feb 17, 2017 at 11:33 AM Victor Leschuk <vleschuk at accesssoftek.com>
> Hello Eric,
> In my opinion all of accelerated access (pubnames, pubtypes, all of the
> accelerator tables) should be optionally emitted, including the new
> debug_names work. Basically we should let users produce the type of table
> based on the consumer of the data rather than anything else - and default
> to nothing because the tables are, as you gathered, rather consumer
> Currently clang produces .debug_pubnames and .debug_pubtypes when invoked
> with -g3, there is no -gpubnames (pubtypes, etc) switch as it is in gcc.
> Are you suggesting we use similar behavior as gcc, eg do not emit accel
> tables even with -g3 and add special options like -gpubnames and -gnames?
Yes. Exactly. There's already a ggnu-pubnames option which will produce
pubnames that match the gcc version used with gold for gdb_index.
> Right now, as far as I know, no debugger implements the version of
> debug_names recently standardized so there's an additional point to avoid
> using it for now.
> GNU readelf has support for .debug_names (not merged to master yet, but
> will be soon) and gdb is on its way (I am in touch with binutils-gdb
> developer on this).
Nifty. None of our tools do in the clang side, including emitting them.
> On Fri, Feb 17, 2017 at 6:00 AM Victor Leschuk via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
> Hello all,
> I am implementing support for .debug_names section (which is introduced
> in DWARFv5 standard as replacement for .debug_pubnames and
> .debug_pubtypes). The question is: should usage of DWARF version 5 force
> generation of .debug_names instead of .debug_pubnames or we can make it
> just default behavior and provide user with the interface (cmd switch)
> to use other DWARFv5 features but generate old .debug_pubnames and
> .debug_pubtypes? The thing is that there can be potential DWARF consumer
> which doesn't fully support new standard. When we are talking about
> attributes, etc it will just cause warnings, but unknown section is much
> more serious issue.
> Best Regards,
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> Best Regards,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev