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

Alan Hayward
2018-05-31T16:27:00Z

> 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.