* m68k: gdbstub crashing setting float register on cfv4e cpu
@ 2020-04-14 16:31 Philippe Mathieu-Daudé
2020-04-14 16:56 ` Alex Bennée
0 siblings, 1 reply; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-04-14 16:31 UTC (permalink / raw)
To: Alex Bennée, Laurent Vivier
Cc: Thomas Huth, qemu-devel@nongnu.org Developers
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.
---[HOST]---
30279@1586881511.897231:gdbstub_io_command Received: P12=000000000000f03f
30279@1586881511.897293:gdbstub_io_reply Sent: OK
30279@1586881511.897593:gdbstub_io_got_ack Got ACK
30279@1586881511.897837:gdbstub_io_command Received: g
Aborted (core dumped)
(gdb) bt
#1 0x00007ffff514e895 in abort () at /lib64/libc.so.6
#2 0x00005555556a9548 in roundAndPackFloat64 (zSign=0 '\000', zExp=0,
zSig=0, status=0x7fffffff9b20) at fpu/softfloat.c:3756
#3 0x00005555556ad2bb in floatx80_to_float64 (a=...,
status=0x7fffffff9b20) at fpu/softfloat.c:5659
#4 0x000055555573a6c7 in cf_fpu_gdb_get_reg
(env=0x555555fb58d0, mem_buf=0x7fffffff9c7c
"\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377",
n=0) at target/m68k/helper.c:75
#5 0x00005555556bd866 in gdb_read_register
(cpu=0x555555fad250, mem_buf=0x7fffffff9c7c
"\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377\177\377\377\377\377\377\377\377",
reg=18) at gdbstub.c:896
#6 0x00005555556bf665 in handle_read_all_regs (gdb_ctx=0x7fffffff9c20,
user_ctx=0x0) at gdbstub.c:1813
#7 0x00005555556bead0 in process_string_cmd (s=0x5555564bb000,
user_ctx=0x0, data=0x5555564bb01c "g", cmds=0x555555bf5880
<read_all_regs_cmd_desc>, num_cmds=1) at gdbstub.c:1477
#8 0x00005555556beb45 in run_cmd_parser (s=0x5555564bb000,
data=0x5555564bb01c "g", cmd=0x555555bf5880 <read_all_regs_cmd_desc>) at
gdbstub.c:1493
#9 0x00005555556c093a in gdb_handle_packet (s=0x5555564bb000,
line_buf=0x5555564bb01c "g") at gdbstub.c:2596
#10 0x00005555556c15b7 in gdb_read_byte (s=0x5555564bb000, ch=55 '7') at
gdbstub.c:2932
#11 0x00005555556c17ea in gdb_chr_receive (opaque=0x5555564bb000,
buf=0x7fffffffbde0 "$g#67", '0' <repeats 12 times>,
"f03f#5f\347\372\340\366\377\177", size=5) at gdbstub.c:3170
#12 0x000055555595e986 in qemu_chr_be_write_impl (s=0x55555622eac0,
buf=0x7fffffffbde0 "$g#67", '0' <repeats 12 times>,
"f03f#5f\347\372\340\366\377\177", len=5) at chardev/char.c:183
#13 0x000055555595e9ea in qemu_chr_be_write (s=0x55555622eac0,
buf=0x7fffffffbde0 "$g#67", '0' <repeats 12 times>,
"f03f#5f\347\372\340\366\377\177", len=5) at chardev/char.c:195
#14 0x0000555555967734 in tcp_chr_read (chan=0x555555e21290,
cond=G_IO_IN, opaque=0x55555622eac0) at chardev/char-socket.c:525
#15 0x0000555555982fb4 in qio_channel_fd_source_dispatch
(source=0x555556493200, callback=0x555555967585 <tcp_chr_read>,
user_data=0x55555622eac0) at io/channel-watch.c:84
#16 0x00007ffff7c42ecd in g_main_context_dispatch () at
/lib64/libglib-2.0.so.0
#17 0x00005555559ec20c in glib_pollfds_poll () at util/main-loop.c:219
#18 0x00005555559ec286 in os_host_main_loop_wait (timeout=14976775) at
util/main-loop.c:242
#19 0x00005555559ec38b in main_loop_wait (nonblocking=0) at
util/main-loop.c:518
#20 0x00005555557163dd in qemu_main_loop () at softmmu/vl.c:1665
#21 0x0000555555988d21 in main (argc=7, argv=0x7fffffffd078,
envp=0x7fffffffd0b8) at softmmu/main.c:49
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: m68k: gdbstub crashing setting float register on cfv4e cpu
2020-04-14 16:31 m68k: gdbstub crashing setting float register on cfv4e cpu Philippe Mathieu-Daudé
@ 2020-04-14 16:56 ` Alex Bennée
2020-04-16 11:18 ` Laurent Vivier
0 siblings, 1 reply; 7+ messages in thread
From: Alex Bennée @ 2020-04-14 16:56 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Thomas Huth, Laurent Vivier, qemu-devel@nongnu.org Developers
Philippe Mathieu-Daudé <f4bug@amsat.org> 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
ATTACHED: m68k
GDB Exception: <class 'gdb.error'>
All tests complete: 1 failures
SHA1=15dd99a1991e0b3826fede3deffc1feba42278e6
And with:
/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 "-cpu cfv4e" --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
0x80000340 in _start ()
ATTACHED: m68k
Breakpoint 1 at 0x80001dda: file /home/alex/lsrc/qemu.git/tests/tcg/multiarch/sha1.c, line 137.
Program received signal SIGILL, Illegal instruction.
0x80019b70 in _dl_aux_init ()
FAIL: break @ 0x80019b70 <_dl_aux_init+4> ({void (SHA1_CTX *)} 0x80001dd6 <SHA1Init> 0 hits)
Single stepping until exit from function _dl_aux_init,
which has no line number information.
Program terminated with signal SIGILL, Illegal instruction.
The program no longer exists.
GDB Exception: <class 'gdb.error'>
All tests complete: 2 failures
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
--
Alex Bennée
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: m68k: gdbstub crashing setting float register on cfv4e cpu
2020-04-14 16:56 ` Alex Bennée
@ 2020-04-16 11:18 ` Laurent Vivier
2020-04-16 20:03 ` Pierre Muller
2020-04-20 13:53 ` KONRAD Frederic
0 siblings, 2 replies; 7+ messages in thread
From: Laurent Vivier @ 2020-04-16 11:18 UTC (permalink / raw)
To: Alex Bennée, Philippe Mathieu-Daudé
Cc: Thomas Huth, qemu-devel@nongnu.org Developers
Le 14/04/2020 à 18:56, Alex Bennée a écrit :
>
> Philippe Mathieu-Daudé <f4bug@amsat.org> 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).
Thanks,
Laurent
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: m68k: gdbstub crashing setting float register on cfv4e cpu
2020-04-16 11:18 ` Laurent Vivier
@ 2020-04-16 20:03 ` Pierre Muller
2020-04-16 20:09 ` Laurent Vivier
2020-04-20 13:53 ` KONRAD Frederic
1 sibling, 1 reply; 7+ messages in thread
From: Pierre Muller @ 2020-04-16 20:03 UTC (permalink / raw)
To: Laurent Vivier, Alex Bennée, Philippe Mathieu-Daudé
Cc: Thomas Huth, qemu-devel@nongnu.org Developers
Le 16/04/2020 à 13:18, Laurent Vivier a écrit :
> Le 14/04/2020 à 18:56, Alex Bennée a écrit :
>>
>> Philippe Mathieu-Daudé <f4bug@amsat.org> 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 ----
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: m68k: gdbstub crashing setting float register on cfv4e cpu
2020-04-16 20:03 ` Pierre Muller
@ 2020-04-16 20:09 ` Laurent Vivier
2020-04-16 20:37 ` Pierre Muller
0 siblings, 1 reply; 7+ messages in thread
From: Laurent Vivier @ 2020-04-16 20:09 UTC (permalink / raw)
To: Pierre Muller, Alex Bennée, Philippe Mathieu-Daudé
Cc: Thomas Huth, qemu-devel@nongnu.org Developers
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é <f4bug@amsat.org> 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?
Thanks,
Laurent
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: m68k: gdbstub crashing setting float register on cfv4e cpu
2020-04-16 20:09 ` Laurent Vivier
@ 2020-04-16 20:37 ` Pierre Muller
0 siblings, 0 replies; 7+ messages in thread
From: Pierre Muller @ 2020-04-16 20:37 UTC (permalink / raw)
To: Laurent Vivier, Alex Bennée, Philippe Mathieu-Daudé
Cc: Thomas Huth, qemu-devel@nongnu.org Developers
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é <f4bug@amsat.org> 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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: m68k: gdbstub crashing setting float register on cfv4e cpu
2020-04-16 11:18 ` Laurent Vivier
2020-04-16 20:03 ` Pierre Muller
@ 2020-04-20 13:53 ` KONRAD Frederic
1 sibling, 0 replies; 7+ messages in thread
From: KONRAD Frederic @ 2020-04-20 13:53 UTC (permalink / raw)
To: Laurent Vivier, Alex Bennée, Philippe Mathieu-Daudé
Cc: Thomas Huth, qemu-devel@nongnu.org Developers, pierre
Le 4/16/20 à 1:18 PM, Laurent Vivier a écrit :
> Le 14/04/2020 à 18:56, Alex Bennée a écrit :
>>
>> Philippe Mathieu-Daudé <f4bug@amsat.org> 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.
We worked on that recently, actually the registers are supported in GDB but QEMU
doesn't send the right register description to GDB.
I've a local patch for that, will send it to the list.
>
> To be able to debug remotely m68k I use gdb from etch-m68k in a chroot
> (or from real hardware).
>
> Thanks,
> Laurent
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-04-20 13:58 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-14 16:31 m68k: gdbstub crashing setting float register on cfv4e cpu Philippe Mathieu-Daudé
2020-04-14 16:56 ` Alex Bennée
2020-04-16 11:18 ` Laurent Vivier
2020-04-16 20:03 ` Pierre Muller
2020-04-16 20:09 ` Laurent Vivier
2020-04-16 20:37 ` Pierre Muller
2020-04-20 13:53 ` KONRAD Frederic
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.