Re: [RFC] Changing gdbarch mid-execution

CC-ing Alan as well.

On 1/22/20 2:03 PM, Luis Machado wrote:
> On 1/22/20 11:56 AM, Pedro Alves wrote:
>> 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.
> 
> I don't like the re-fetching either, so i'm trying to minimize that.
> 
> Part of the problem is that the vector length (VL) is per-thread, ...
> 
>>
>> 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.
>>
> 
> ... so the above, even though it works nicely for reporting the stop of 
> a single thread, it won't carry information about potential other 
> threads that stopped along with the one the caused the stop reply to be 
> sent, right? We would need to fetch updates from the other threads in 
> case they changed their VL during execution.
> 
>>
>> 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.
> 
> Right. A new target description comes along with new sizes for the 
> particular types and aggregates it defines.
> 
>>
>> 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.
> 
> The variable length description is technically more correct, but i think 
> we already opted for a different solution with multiple VL-based target 
> descriptions.
> 
> My idea is to not rely on register values and, instead, focus on sizes 
> of some aggregates the target description defines. That way we are not 
> forced to fetch any registers and can infer the vector length from the 
> sizes on the new target description.
> 
> Both native sides (GDB and gdbserver) and QEMU know how to detect VL 
> changes. It is just the communication of that change to GDB that we need 
> to sort out via RSP.
> 
>>
>> 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.
>>
> 
> There is no re-fetching in the sense that data doesn't get passed 
> around, but new target descriptions do get created dynamically 
> (aarch64_create_target_description) based on the new VL. The resulting 
> gdbarch then gets cached so we don't need to recreate that particular 
> variation.
> 
> My idea for a RSP-based target description update tries to mimic that as 
> follows...
> 
> - Remote end notices a target description / gdbarch change and notifies 
> GDB via a stop reply packet entry.
> 
> - GDB fetches the stop reply data and knows it has to query the remote 
> about what particular threads had their target descriptions updated. I 
> think this needs to be a new packet, maybe a qXfer one with a different 
> object. The qXfer packet would handle large lists of threads (thinking 
> about future use cases, GPU's etc).
> 
> - Remote sends a list of threads to GDB.
> 
> - GDB fetches the list of threads it needs to re-fetch the target 
> descriptions from and proceeds to query the remote about those 
> descriptions. I think we could cache the descriptions here, or have an 
> opaque description that gets passed down to the target-specific code as 
> you suggested.
> 
> - GDB finishes the update and caches (as much as possible) the gdbarch 
> per-thread/per-regcache.
> 
> When no target description change has taken place we have nothing to do 
> and no RSP overhead, so it wouldn't slow things down.
> 
> Does the above sound like an acceptable way forward?
> 
> Luis
>