[llvm-dev] [DebugInfo][DWARFv5] should -gdwarf-5 imply usage of .debug_names?

[Eric Christopher via llvm-dev]

On Fri, Feb 17, 2017 at 11:33 AM Victor Leschuk <vleschuk at accesssoftek.com>
wrote:

> 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
> specific.
>
> 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.

-eric


>
> -eric
>
> 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,
> Victor
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
> --
> Best Regards,
> Victor
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170217/ed158778/attachment-0001.html>