[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


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?
>
> 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).
>
> -eric
>
> 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
>     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 <mailto: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/77f18ba5/attachment.html>


More information about the llvm-dev mailing list