Re: [PATCH] aarch64/gdbserver: fix floating point registers display

[Andrew Pinski <pinskia@gmail.com>]

On Wed, Aug 20, 2014 at 11:54 PM, catalin.udma@freescale.com
<catalin.udma@freescale.com> wrote:
> Thank you all for your comments.
> As a follow-up, should I re-submit my patch without changing
> cpsr size in regformats/aarch64.dat? ... While  the current cpsr
> size de-synchronization would be fixed by reverting the patch
> we are discussing about?

If we revert the patch is someone going to fix big-endian support then
since that is the original why it was requested.

Thanks,
Andrew

>
> Regards,
> Catalin
>
>> -----Original Message-----
>> From: Pedro Alves [mailto:palves@redhat.com]
>> Sent: Wednesday, August 20, 2014 8:36 PM
>> To: Richard Earnshaw; Yao Qi
>> Cc: Philippe Waroquiers; Udma Catalin-Dan-B32721; gdb-
>> patches@sourceware.org
>> Subject: Re: [PATCH] aarch64/gdbserver: fix floating point registers
>> display
>>
>> On 08/13/2014 03:42 PM, Richard Earnshaw wrote:
>> > On 13/08/14 13:39, Yao Qi wrote:
>> >> On 08/13/2014 08:25 PM, Philippe Waroquiers wrote:
>> >>> The 'it' in 'fix it' is ambiguous to me.
>> >>> Does the 'it' mean:
>> >>>      fix aarch64-core.xml to change cpsr to 32 bits ?
>> >>
>> >> That was what I meant, however ....
>> >>
>> >>> or does that confirm the initial proposal i.e.
>> >>>      fix e.g. aarch64.dat to change cpsr to 64 bits ?
>> >>
>> >> ... I find a patch changed cpsr to 64 bit in last Dec.
>> >>
>> >>  [PATCH] AARCH64: Change cpsr type to be 64bit.
>> >>  https://sourceware.org/ml/gdb-patches/2013-12/msg00720.html
>> >>
>> >> and looks aarch64.dat was not updated together in this patch.
>> >>
>> >> I am sure that aarch64.dat and aarch64-core.xml are not in sync,
>> >> but I don't know which way to go, sorry.
>> >>
>> >
>> > Changing the XML doesn't sound like the right way forward, the XML can
>> > be embedded into other components as part of the register description
>> > interface.
>> >
>> > Hmm, I can't see where anyone ever formally approved that change.  In
>> > fact, Mark K commented at the time:
>> >
>> > "Basing GDB's fundamentals on a particular OS's ptrace(2)
>> > implementation is a bad idea."
>> >
>> > So it seems to me that that change was indeed incorrect and should
>> > probably be reverted (at least in its current incarnation).
>>
>> I agree, and I'm surprised to learn the patch went in.  :-/
>>
>> Thanks,
>> Pedro Alves
>