Re: [PATCHv3] gdb: resolve class name via DW_AT_signature in cooked index

[Tom Tromey <tom@tromey.com>]

>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:

>> (a) If a DIE has no name, but does have a signature, then give the
>> DIE a fake name (the empty string), and create an index entry
>> for the DIE.  Also keep a record that the cooked_index_entry
>> for this DIE has a deferred name.

Simon> Just wondering, if we end up not patching the entry for some reason,
Simon> will an entry with an empty name cause problems / match things it's not
Simon> supposed to match?  Like will the child of that nameless entry be
Simon> considered to be part of the top-level namespace or something like that?

Simon> If it happens that we have an entry with an unresolved name, perhaps we
Simon> should consider this entry invalid and just skip anything that would
Simon> require it.

Simon>    So yeah, I wonder if it wouldn't be better to leave the name as
Simon>    nullptr, that would force us to add some nullptr checks to realize
Simon>    that the entry doesn't have a valid name, and we would skip it.

I would much prefer a new cooked_index_flag_enum value over allowing
NULL pointers.

Simon>  - the complaint runs on a thread pool worker, but no
Simon>    complaint_interceptor is installed in those threads, so
Simon>    complaint_internal writes straight to gdb_stderr from a worker
Simon>    thread, outside the collect-and-re-emit-on-the-main-thread machinery.
Simon>    Besides the raw thread-safety issue, the message can land at an
Simon>    arbitrary point in the main thread's output.  Using the
Simon>    complaint interceptor would fix both.

Complaints are worthless IMO.

If this is user-actionable or interesting in any way, it's better to
warn.  If it isn't user-actionable, then it can just be ignored.

Simon>  - The comment on cooked_index_entry::name says that it always points
Simon>    into mapped DWARF sections, which is not true anymore.  The comment
Simon>    could talk about the "" case (or nullptr if we decided to go that
Simon>    route).

I think it's actually wrong already since cooked_index_shard::finalize
can synthesize names.  It's really the lifetime of the pointer that is
important, not the storage location; and the important invariant is that
there's never a case where the string is freed but the entry is live.

Tom