[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: m68k: gdbstub crashing setting float register on cfv4e cpu
From: |
Pierre Muller |
Subject: |
Re: m68k: gdbstub crashing setting float register on cfv4e cpu |
Date: |
Thu, 16 Apr 2020 22:03:07 +0200 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 |
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
Pierre Muller
muller@gcc123:~/gnu/gdb$ cat gdb-8.3-m68k-fpu-fix.patch
diff -rc gdb-8.3/gdb/m68k-tdep.c gdb-8.3-for-m68k/gdb/m68k-tdep.c
*** gdb-8.3/gdb/m68k-tdep.c 2019-02-27 04:51:50.000000000 +0000
--- gdb-8.3-for-m68k/gdb/m68k-tdep.c 2019-09-30 14:28:02.632962365 +0000
***************
*** 1124,1131 ****
--- 1124,1136 ----
feature = tdesc_find_feature (info.target_desc,
"org.gnu.gdb.coldfire.fp");
+ if (!feature)
+ feature = tdesc_find_feature (info.target_desc,
+ "org.gnu.gdb.m68k.fp");
if (feature != NULL)
{
+ int bitsize;
+
valid_p = 1;
for (i = M68K_FP0_REGNUM; i <= M68K_FPI_REGNUM; i++)
valid_p &= tdesc_numbered_register (feature, tdesc_data, i,
***************
*** 1135,1140 ****
--- 1140,1155 ----
tdesc_data_cleanup (tdesc_data);
return NULL;
}
+ bitsize = tdesc_register_bitsize (feature, "fp0");
+ if (bitsize == 64)
+ long_double_format = floatformats_ieee_double;
+ else if (bitsize == 96)
+ long_double_format = floatformats_m68881_ext;
+ else
+ {
+ tdesc_data_cleanup (tdesc_data);
+ return NULL;
+ }
}
else
has_fp = 0;
***************
*** 1181,1188 ****
tdep->fpregs_present = has_fp;
tdep->flavour = flavour;
- if (flavour == m68k_coldfire_flavour || flavour == m68k_fido_flavour)
- long_double_format = floatformats_ieee_double;
set_gdbarch_long_double_format (gdbarch, long_double_format);
set_gdbarch_long_double_bit (gdbarch, long_double_format[0]->totalsize);
--- 1196,1201 ----