Re: [PATCH v6 3/3] gdb: extend the [[N]]::foo syntax for files

[Guinevere Larsen <guinevere@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1586 bytes --]

On 4/20/26 12:13 PM, Andrew Burgess wrote:
> Guinevere Larsen<guinevere@redhat.com> writes:
>
>> This commit implements the missing support for [[N]]::'file.c'::var
>> syntax that was skipped on the previous commit.
>>
>> This is done by adding a new value to the global parser_state, so that
>> the classify_name function can restrict its search for file names to the
>> specified linker namespace.  It had to be done this way because if the
>> logic was contained on the newly added "block: block COLONCOLON
>> FILENAME" rule, we would not have the name to rerun the search.
> Did you consider adding the filename to the <whatever> type such that it
> was available within the rule to allow for the filename to be re-looked
> up?
>
> I'd be interested to know if this was tried, why this was worse than
> pushing parser state back to the lexer, which I always thought was not a
> great design.

My one worry with this is, what if there is a file foo in the default 
namespace, and a function 'foo' in namespace 1

Could we misidentify this as being a filename, and then we rerun the 
search inside the "block: block COLONCOLON FILENAME" and find nothing, 
and raise an error when the expression was valid?

I'm not familiar enough with our parser to know if this is the case, but 
if it is and I understand it correctly, I think this is a possible 
failure case... Although if you think this is a failure that is too 
niche, I can go that route, mark it as such on the code and commit 
message, and remove the linker namespace ID from the parser.

-- 
Cheers,
Guinevere Larsen
It/she

[-- Attachment #2: Type: text/html, Size: 2307 bytes --]