[llvm-dev] [DebugInfo][DWARFv5] should -gdwarf-5 imply usage of .debug_names?
Victor Leschuk via llvm-dev
llvm-dev at lists.llvm.org
Fri Feb 17 11:33:00 PST 2017
> 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
> 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).
> On Fri, Feb 17, 2017 at 6:00 AM Victor Leschuk via llvm-dev
> <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> Hello all,
> I am implementing support for .debug_names section (which is
> in DWARFv5 standard as replacement for .debug_pubnames and
> .debug_pubtypes). The question is: should usage of DWARF version 5
> 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
> 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 <mailto:llvm-dev at lists.llvm.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev