[PATCH 4/8] Enable SVE for GDB

[Alan Hayward]

> On 31 May 2018, at 17:18, Pedro Alves <palves@redhat.com> wrote:
> 
> 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?

Right, I didn’t spot that. It can’t be negative, only 0 or a value
divisible by 2.
To match the register, I’m thinking uint64_t would be right then.


Alan.