Re: [PATCH 4/8] Enable SVE for GDB

[Pedro Alves <palves@redhat.com>]

On 05/31/2018 05:13 PM, Alan Hayward wrote:
> 
> 
>> On 31 May 2018, at 15:59, Pedro Alves <palves@redhat.com> wrote:
>>
>> On 05/11/2018 11:52 AM, Alan Hayward wrote:
>>> --- a/gdb/aarch64-tdep.c
>>> +++ b/gdb/aarch64-tdep.c
>>> @@ -2873,6 +2873,26 @@ aarch64_read_description (long vq)
>>>   return tdesc;
>>> }
>>>
>>> +/* Return the VQ used when creating the target description TDESC.  */
>>> +
>>> +static long
>>> +aarch64_get_tdesc_vq (const struct target_desc *tdesc)
>>
>> Is this use of "long" significant?  I mean, is it assuming 64-bit?
>> I ask because longs are not 64-bit on x64 Windows, so it would
>> do the wrong thing when cross debugging.
> 
> In the kernel structure it’s a 16bit value.
> 
> However, the VG "register" in the regcache is a 64bit value. (It’s not
> a real system register, but helps a great deal to see it as one in gdb,
> and we need it as a dwarf register.) I made it 64bits to match the
> minimum size of all the other aarch64 registers.

OK, fine to make it 64-bit, but then the "do the wrong thing when
cross debugging" point applies.  "long" is 32-bit on some hosts.
I don't really know what values VG can take -- can they be
negative?  I.e., is sign extension expected?  You did not seem to address
this in your reply.  Why not use host-independent ULONGEST, for example?

> I did have it as 16bits at one point, but it went wrong when using it
> with dwarf as it expects all the dwarf registers to be the minimum
> register.
> 
> I chose to do the conversion from 16bits to 64bits at the point vg is
> read from the kernel. This makes the code easy as from then on as it’s
> always 64bits throughout.
> 
> Alternatively, I could have kept as 16bits up to the point it hits
> the regcache. But that leaves two different types around the code.

Thanks,
Pedro Alves