Re: [RFC] Proposal for a new DWARF name index section

[Tom Tromey <tromey@redhat.com>]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Dodji> * Only public names are indexed.  However, historically GDB has
Dodji> allowed users to inspect and break on private objects as well,
Dodji> without specifying a scope.

Jan> I think this requirement should be discussed more.

Jan> Still I find the goal is that the expression evaluation in debugger
Jan> should match the expression evaluation in compiler.

I agree with this principle, but the reason to include this information
in the index has to do with setting breakpoints, not with expression
evaluation.

I don't think breakpoint setting should necessarily follow language
rules.

It is not uncommon for a program to have a uniquely-named static
function.  It seems friendly to users to let them type "break func" in
any context.  And, it seems like this operation should not cause gdb to
go off and read all the debuginfo.

Anyway, that is my logic.  Which part of this do you disagree with?
Or, am I missing something else?

[...]
Jan> A fixup by http://dwarfstd.org/Issues.php looks as appropriate in
Jan> each case.

Yeah, for the minor things.  However...

Dodji> * Compilers are not required to emit index entries for inlined
Dodji> functions which have no concrete out-of-line instance.  This implies
Dodji> that a command like "break function", if it is to work for an
Dodji> inlined function, must read all the .debug_info sections even if it
Dodji> turns out that no such function exists anywhere.

... this is not minor.

And, if we agree about the private names problem, then that is not minor
either :)

Jan> 	C++ member functions with a definition in the class declaration are
Jan> 	definitions in every compilation unit containing the class
Jan> 	declaration, but if there is no concrete out-of-line instance there is
Jan> 	no need to have a .debug_pubnames entry for the member function.

Jan> "no need to have" (and you say "are not required") so GCC is free
Jan> to emit such index entries.  Excessive index entries hopefully
Jan> should not break debuggers.

Jan> GDB could check DW_AT_producer against known GCC versions to skip
Jan> the slow reading of '.debug_info's and rely just on
Jan> '.debug_pubnames' - to find out all the inlined instances of a
Jan> specified function.

That's gross, though.

There does not seem to be a big downside to introducing a new section
that does exactly what we want.  It is automatically backward
compatible.  It is (I believe) not difficult to implement.  And,
finally, we can make it reliable by fiat.

Tom