This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 4/8] Enable SVE for GDB
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