Re: [RFC] Changing gdbarch mid-execution

[Pedro Alves <palves@redhat.com>]

On 1/6/20 2:08 PM, Luis Machado wrote:
> Hi,
> 
> I have a situation at hand and i'm thinking about how to best solve it.
> 
> AArch64 SVE has the capability of changing the vector length mid-execution. This can be done at the thread level.
> 
> Native GDB already supports this by looking at the ptrace data. But doing this for a remote target requires changes to the RSP.
> 
> Instead of changing things just for this particular case, i'm considering having a more general mechanism for updating the architecture data whenever such change is noticed by whoever is controlling the inferior.
> 
> My idea is to get the mechanism started by using the stop reply to send a new notification, say, "arch-changed".
> 
> That should trigger GDB to re-fetch the architecture data and reinitialize it.
> 
> In the particular case of SVE, we only need to fetch the target description again, so we have the proper vector length and data types set.
> 
> Does this sound like a useful feature? Or should i go for the solution with less impact that will only take care of re-fetching the target description?

I'm not keep on the idea of potential constant re-fetching of arch data.
I'd think that "arch-changed=ARCH" with each arch having its own unique
name (can be opaque to GDB) so that GDB can cache the arch description,
and avoid refetching it over and over would be better.

Also, I don't think a state transition such a "arch changed" is the best.
I'd think making the stop reply say:

 "stopped on code running arch foo"

is better.

See this:

 https://www.sourceware.org/gdb/papers/multi-arch/real-multi-arch/

In which Cagney suggested something very similar:

 T00;...;Architecture=<arch>;...
     The T packet is used to report the reason the target stopped to GDB. That packet includes information such as the processor and that processors registers. The packet can be extended to include the architecture of the processor that halted. 


Though for the SVE case, I'm not sure a target description change is the
best model, where you end up with a different target description description
for each potential different vector length.  

An alternative could be for the target description to always describe the
largest possible vector file, or explicitly describe the VLE registers as variable
length, and then gdb would handle presenting the usable registers.  GDB should
be able to tell the size of the vector registers by looking at the VQ (or was
it VL?  Or whatever it is called) register.

In effect, we can see the current native support as a middle ground,
where aarch64_linux_nat_target::thread_architecture returns a different
gdbarch, there's no target description re-fetching, I believe.

Thanks,
Pedro Alves