Re: [PATCH v3 0/8] gdbserver improvements for AArch64 SVE support

[Pedro Alves <pedro@palves.net>]

On 2023-02-06 8:05 p.m., Simon Marchi via Gdb-patches wrote:
> 
>> Ah!  I had also suggested to you something like that at the Cauldron (when we were in line
>> for lunch.  :-D  However, IIRC, I had suggested that we should be able to cache the tdesc by filename.
>>
>> Let me explain -- when we fetch a target description, we actually tell the server
>> to retrieve a tdesc _by a given filename_.  By default, we ask for target.xml, like this:
>>
>>  qXfer:features:read:target.xml
>>
>> but then, the retrieved target.xml file may "xi:include" some other file, like for example these do:
>>
>>  gdb/features/s390-linux64.xml:14:  <xi:include href="s390-core64.xml"/>
>>  gdb/features/s390-linux64.xml:15:  <xi:include href="s390-acr.xml"/>
>>  gdb/features/s390-linux64.xml:16:  <xi:include href="s390-fpr.xml"/>
>>
>> (try grepping for xi:include in the gdb/features/ dir for a lot more hits.)
>>
>> and so when processing each of those xi:include's, gdb sends another qXfer:features:read packet,
>> with the corresponding included filename, like e.g., 
>>
>>   qXfer:features:read:s390-core64.xml
>>
>> Here's what the manual says:
>>
>>  @item qXfer:features:read:@var{annex}:@var{offset},@var{length}
>>  @anchor{qXfer target description read}
>>  Access the @dfn{target description}.  @xref{Target Descriptions}.  The
>>  annex specifies which XML document to access.  The main description is
>>  always loaded from the @samp{target.xml} annex.
>>
>> So basically I am suggesting that instead a new ID mechanism, we should be able to
>> use the preexisting annex/filename concept as key.  That means that the stop reply and
>> the thread listing would include a new "tdesc=foo.xml" attribute, instead of this
>> ID that then is defined to map to "target-id-%u.xml", which is basically admitting
>> that tdesc filenames exist anyhow.
> 
> Just for completeness, how do you envision that working for SVE?
> GDBserver would make up unique names for each configuration, like
> "target-vq-%d.xml"?

The string is free form, up to the server to decide what to use for names.  Could 
be that, or "aarch64-linux-sve-vq-%d.xml" or whatever.  Of course, for ports that
wouldn't generate the tdescs on the fly, you'd want to use the same name as the
real existing xml files that are embedded into gdbserver.

> 
> If caching using filenames as keys, what is the scope of that namespace?
> Per remote connection, per inferior?  I think it wouldn't work per
> remote connection, because fetching "target.xml" for two different
> inferiors could give two different answers.

Right, I think we'd make it per-inferior, at least by default, for backwards compatibility.

But we can also think about the server telling gdb about the scope if we want, with qSupported
or some such.  And then if the stub tells gdb that the scope is connection, the stub would also
tell gdb about the architecture of the main thread (in stop reply and thread listings),
say, "the-right-secondary-arch.xml" so gdb would retrieve "qXfer:features:read:the-right-secondary-arch.xml",
for that inferior, and not "qXfer:features:read:target.xml".  Basically, gdb only fetches
"target.xml" when it doesn't know better.

> 
> Tangentially, I'm wondering if querying qXfer:features:read (mostly
> fetching "target.xml" is going to become thread-sensitive.  In other
> words, if GDB set the general thread to a thread with vq == A, gets
> target.xml, then sets the general thread to a thread with vq == B, then
> gets target.xml, is it going to get two different target descriptions?
> I think that it would make sense to do so *.  

I am not so sure about that making sense.

As target.xml is documented as the main tdesc, it would continue that way,
with "main" meaning the tdesc that the initial thread has when the process
is first started.

> Therefore, caching
> target.xml per-inferior wouldn't be reliable either.  And if included
> files could vary per thread, you'd have to make sure to give them unique
> names.

With the numerical ID idea, you have to know which ID to read for the thread,
before you read it.  You don't just go and read the desc with ID 0 thinking that
0 is a different ID depending on thread, right?  So it's no different -- the stop
reply would say "tdesc=whatever-secondary-arch.xml", and GDB would fetch that xml
file if not cached yet, and use the cached version otherwise.

> 
> * I think that since we're going towards thread-specific tdescs, the
>   process-wide tdesc is going to become an obsolete concept, maybe just
>   kept for backwards compatibility for when an old GDB not aware of
>   per-thread tdescs talks to a new GDBserver aware of it, or vice versa.
> 
> Simon
>