Re: m68k: gdbstub crashing setting float register on cfv4e cpu

[Pierre Muller]

Le 16/04/2020 à 22:09, Laurent Vivier a écrit :
> Le 16/04/2020 à 22:03, Pierre Muller a écrit :
>> Le 16/04/2020 à 13:18, Laurent Vivier a écrit :
>>> Le 14/04/2020 à 18:56, Alex Bennée a écrit :
>>>>
>>>> Philippe Mathieu-Daudé <address@hidden> writes:
>>>>
>>>>> gdbstub/m68k seems broken with floats, previous to refactor commit
>>>>> a010bdbe719 ("extend GByteArray to read register helpers").
>>>>>
>>>>> HEAD at 6fb1603aa2:
>>>>>
>>>>> $ qemu-system-m68k -s -S -cpu cfv4e
>>>>>
>>>>> ---[GUEST]---
>>>>>
>>>>> (gdb) set architecture m68k:cfv4e
>>>>> The target architecture is assumed to be m68k:cfv4e
>>>>> (gdb) target remote 172.17.0.1:1234
>>>>> Remote debugging using 172.17.0.1:1234
>>>>> (gdb) info float
>>>>> fp0            -nan(0xfffffffffff7f) (raw 0xffffffffffffff7f)
>>>>> fp1            -nan(0xfffffffffff7f) (raw 0xffffffffffffff7f)
>>>>> fp2            -nan(0xfffffffffff7f) (raw 0xffffffffffffff7f)
>>>>> fp3            -nan(0xfffffffffff7f) (raw 0xffffffffffffff7f)
>>>>> fp4            -nan(0xfffffffffff7f) (raw 0xffffffffffffff7f)
>>>>> fp5            -nan(0xfffffffffff7f) (raw 0xffffffffffffff7f)
>>>>> fp6            -nan(0xfffffffffff7f) (raw 0xffffffffffffff7f)
>>>>> fp7            -nan(0xfffffffffff7f) (raw 0xffffffffffffff7f)
>>>>> fpcontrol      0x0                 0
>>>>> fpstatus       0x0                 0
>>>>> fpiaddr        0x0                 0x0
>>>>> (gdb) set $fp0=1
>>>>> Remote communication error.  Target disconnected.: Connection reset by
>>>>> peer.
>>>>
>>>> With my sha1 debugging test case I get different results depending on
>>>> the cpu type:
>>>>
>>>>   /home/alex/lsrc/qemu.git/tests/guest-debug/run-test.py --gdb 
>>>> /home/alex/src/tools/binutils-gdb.git/builds/all/install/bin/gdb --qemu 
>>>> /home/alex/lsrc/qemu.git/builds/user.static/m68k-linux-user/qemu-m68k 
>>>> --qargs "" --bin tests/tcg/m68k-linux-user/sha1 --test
>> /home/alex/lsrc/qemu.git/tests/tcg/multiarch/gdbstub/sha1.py
>>>>   GNU gdb (GDB) 10.0.50.20200414-git
>>>>   Copyright (C) 2020 Free Software Foundation, Inc.
>>>>   License GPLv3+: GNU GPL version 3 or later 
>>>> <http://gnu.org/licenses/gpl.html>
>>>>   This is free software: you are free to change and redistribute it.
>>>>   There is NO WARRANTY, to the extent permitted by law.
>>>>   Type "show copying" and "show warranty" for details.
>>>>   This GDB was configured as "x86_64-pc-linux-gnu".
>>>>   Type "show configuration" for configuration details.
>>>>   For bug reporting instructions, please see:
>>>>   <http://www.gnu.org/software/gdb/bugs/>.
>>>>   Find the GDB manual and other documentation resources online at:
>>>>       <http://www.gnu.org/software/gdb/documentation/>.
>>>>
>>>>   For help, type "help".
>>>>   Type "apropos word" to search for commands related to "word"...
>>>>   Executed .gdbinit
>>>>   Reading symbols from tests/tcg/m68k-linux-user/sha1...
>>>>   Remote debugging using localhost:1234
>>>>   warning: Register "fp0" has an unsupported size (96 bits)
>>>>   warning: Register "fp1" has an unsupported size (96 bits)
>>>>   warning: Register "fp2" has an unsupported size (96 bits)
>>>>   warning: Register "fp3" has an unsupported size (96 bits)
>>>>   warning: Register "fp4" has an unsupported size (96 bits)
>>>>   warning: Register "fp5" has an unsupported size (96 bits)
>>>>   warning: Register "fp6" has an unsupported size (96 bits)
>>>>   warning: Register "fp7" has an unsupported size (96 bits)
>>>>   Remote 'g' packet reply is too long (expected 148 bytes, got 180 bytes):
>> 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000408009f000000000800003407fff0000ffffffffffffffff7fff0000ffffffffffffffff7fff0000ffffffffffffffff7fff0000ffffffffffffffff7fff0000ffffffffffffffff7fff0000ffffffffffffffff7fff0000ffffffffffffffff7fff0000ffffffffffffffff000000000000000000000000
>>>
>>> This is a bug in GDB that doesn't support 96bit float registers of 680x0
>>> but only 64bit registers of coldfire.
>>>
>>> There was a rework of GDB in the past that has broken that and no one
>>> noticed. I bisected and found the commit but it was really too complex
>>> and difficult to fix.
>>>
>>> To be able to debug remotely m68k I use gdb from etch-m68k in a chroot
>>> (or from real hardware).
>>
>>   I do have a fix for gdb-8.3 release: it works for me.
>> See patch below,
>>
>>   You could test it out on other versions,
>> changes to m68k-tdep.c are not that big in recent GDB releases.
>>   I use it with a locally modified qemu to try to support FPU
>> exceptions for m68k FPU.
>>   But I never found the time nor the enery to try to submit those
>> to qemu-devel, especially after viewing what happened to a similar
>> attempt for powerpc hardware fpu support.
>> See "[RFC PATCH v2] target/ppc: Enable hardfloat for PPC" thread, up to
>> https://lists.nongnu.org/archive/html/qemu-ppc/2020-03/msg00006.html
> 
> But why didn't you submit your patch to gdb?

  You are rtight, I should do so,
but I was wondering about this additional xml description,
to differenciate between coldfire (64-bit) and regular 68k co-processor that
supports 96-bit floating point type (in memory, 80 really used).

  The patch allows to accept both and looks into the bit-size to figure
out the correct size, but I don't know if this is the correct way..

Pierre