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

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

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

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