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

[Simon Marchi <simark@simark.ca>]

On 2026-09-11 15:18, Tom Tromey wrote:
>>>>>> "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.

Why?  Just wondering.

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

I don't recall, are we allowed to use debug_printf functions in
non-main-threads?  I'd like if that kind of anomaly left a trace
somewhere, that you can look at without having to debug gdb itself.  Of
course the debug output will probably not look pretty if multiple
threads spew some simultaneously, but you can always disable background
threads just for this.

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

Makes sense yeah.

Simon