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

[Simon Marchi <simark@simark.ca>]

On 9/14/26 9:23 AM, Andrew Burgess wrote:
>>> I would much prefer a new cooked_index_flag_enum value over allowing
>>> NULL pointers.
>>
>> Why?  Just wondering.
> 
> Also, in this case, the point is that we end up creating the
> cooked_index_entry before we know the name, so what value should the
> name pointer hold?
> 
> My V1 patch tried to find the name before the entry was created, but Tom
> correctly pointed out that this was not thread safe, and would fail to
> find the name in some cases.
> 
> My V2 used the empty string in order to avoid NULL pointers, but empty
> name strings cannot usually (outside of this patch) be created, and as
> Simon pointed out, if these empty strings "escape" into the rest of GDB
> then problems arise.
> 
> So V3 switched to NULL pointers as something that is fairly obviously an
> "unset" string.
> 
> I haven't looked into it, but I'm sure I could add an enum flag, but
> this would still leave the question of what value to give NAME until
> it's actually filled in.

That's why I was wondering, but really I am not opposed to a flag, I
just wanted to know the rationale.  We have 1 bit free in
cooked_index_flag, so it wouldn't take up any more space.  It's just
that having a flag that says "this entry has no name and is therefore
invalid" seems redundant with the name being nullptr.

Instead of leaving them nullptr, another option would be delete those
cooked_index_entries from the vectors, if we never plan to do anything
with them.  We would have to delete the name-less entries, and any child
entry that refers to them, not sure how to do that efficiently though.

Simon