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

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

Hi Victor,

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.

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.

-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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170217/e9ade58c/attachment.html>

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>