| Message ID | 1587391275-12748-1-git-send-email-frederic.konrad@adacore.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v1] target/m68k: fix gdb for m68xxx | expand |
Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : > From: KONRAD Frederic <frederic.konrad@adacore.com> > > Currently "cf-core.xml" is sent to GDB when using any m68k flavor. Thing is > it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then expects > a coldfire FPU instead of the default m68881 FPU. > > This is not OK because the m68881 floats registers are 96 bits wide so it > crashes GDB with the following error message: > > (gdb) target remote localhost:7960 > Remote debugging using localhost:7960 > warning: Register "fp0" has an unsupported size (96 bits) > warning: Register "fp1" has an unsupported size (96 bits) > ... > Remote 'g' packet reply is too long (expected 148 bytes, got 180 bytes): \ > 00000000000[...]0000 > > With this patch: qemu-system-m68k -M none -cpu m68020 -s -S > > (gdb) tar rem :1234 > Remote debugging using :1234 > warning: No executable has been specified and target does not support > determining executable automatically. Try using the "file" command. > 0x00000000 in ?? () > (gdb) p $fp0 > $1 = nan(0xffffffffffffffff) > > Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> > --- > configure | 2 +- > gdb-xml/m68k-core.xml | 29 +++++++++++++++++++++++++++++ > target/m68k/cpu.c | 30 +++++++++++++++++++++++++----- > 3 files changed, 55 insertions(+), 6 deletions(-) > create mode 100644 gdb-xml/m68k-core.xml > > diff --git a/configure b/configure > index 23b5e93..2b07b85 100755 > --- a/configure > +++ b/configure > @@ -7825,7 +7825,7 @@ case "$target_name" in > ;; > m68k) > bflt="yes" > - gdb_xml_files="cf-core.xml cf-fp.xml m68k-fp.xml" > + gdb_xml_files="cf-core.xml cf-fp.xml m68k-core.xml m68k-fp.xml" > TARGET_SYSTBL_ABI=common > ;; > microblaze|microblazeel) > diff --git a/gdb-xml/m68k-core.xml b/gdb-xml/m68k-core.xml > new file mode 100644 > index 0000000..5b092d2 > --- /dev/null > +++ b/gdb-xml/m68k-core.xml > @@ -0,0 +1,29 @@ > +<?xml version="1.0"?> > +<!-- Copyright (C) 2008 Free Software Foundation, Inc. > + > + Copying and distribution of this file, with or without modification, > + are permitted in any medium without royalty provided the copyright > + notice and this notice are preserved. --> > +<!DOCTYPE feature SYSTEM "gdb-target.dtd"> > +<feature name="org.gnu.gdb.m68k.core"> So I guess you should also update feature name in gdb-xml/m68k-fp.xml ? Thanks, Laurent
Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : > From: KONRAD Frederic <frederic.konrad@adacore.com> > > Currently "cf-core.xml" is sent to GDB when using any m68k flavor. Thing is > it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then expects > a coldfire FPU instead of the default m68881 FPU. I checked in gdb sources and there is no cf definition. Moreover if I change only the cf to m68k in QEMU it seems to work in both cases: diff --git a/gdb-xml/cf-core.xml b/gdb-xml/cf-core.xml index b90af3042c..5b092d26de 100644 --- a/gdb-xml/cf-core.xml +++ b/gdb-xml/cf-core.xml @@ -5,7 +5,7 @@ are permitted in any medium without royalty provided the copyright notice and this notice are preserved. --> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> -<feature name="org.gnu.gdb.coldfire.core"> +<feature name="org.gnu.gdb.m68k.core"> <reg name="d0" bitsize="32"/> <reg name="d1" bitsize="32"/> <reg name="d2" bitsize="32"/> diff --git a/gdb-xml/m68k-fp.xml b/gdb-xml/m68k-fp.xml index 64290d1630..0ef74f7488 100644 --- a/gdb-xml/m68k-fp.xml +++ b/gdb-xml/m68k-fp.xml @@ -5,7 +5,7 @@ are permitted in any medium without royalty provided the copyright notice and this notice are preserved. --> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> -<feature name="org.gnu.gdb.coldfire.fp"> +<feature name="org.gnu.gdb.m68k.fp"> <reg name="fp0" bitsize="96" type="float" group="float"/> <reg name="fp1" bitsize="96" type="float" group="float"/> <reg name="fp2" bitsize="96" type="float" group="float"/> As I have not checked the gdb sources for that, I'd like to have your opinion. Thanks, Laurent
frederic.konrad@adacore.com writes: > From: KONRAD Frederic <frederic.konrad@adacore.com> > > Currently "cf-core.xml" is sent to GDB when using any m68k flavor. Thing is > it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then expects > a coldfire FPU instead of the default m68881 FPU. > > This is not OK because the m68881 floats registers are 96 bits wide so it > crashes GDB with the following error message: > > (gdb) target remote localhost:7960 > Remote debugging using localhost:7960 > warning: Register "fp0" has an unsupported size (96 bits) > warning: Register "fp1" has an unsupported size (96 bits) > ... > Remote 'g' packet reply is too long (expected 148 bytes, got 180 bytes): \ > 00000000000[...]0000 > > With this patch: qemu-system-m68k -M none -cpu m68020 -s -S > > (gdb) tar rem :1234 > Remote debugging using :1234 > warning: No executable has been specified and target does not support > determining executable automatically. Try using the "file" command. > 0x00000000 in ?? () > (gdb) p $fp0 > $1 = nan(0xffffffffffffffff) > > Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> Well it solves the connection issue - but the FP values are still hopelessly broken, from float_convs: from single: f32(-0x1.1874b200000000000000p+103:0xf30c3a59) in gdb fp0 <invalid float value> (raw 0x8c3a5900000000004066) > --- > configure | 2 +- > gdb-xml/m68k-core.xml | 29 +++++++++++++++++++++++++++++ > target/m68k/cpu.c | 30 +++++++++++++++++++++++++----- > 3 files changed, 55 insertions(+), 6 deletions(-) > create mode 100644 gdb-xml/m68k-core.xml > > diff --git a/configure b/configure > index 23b5e93..2b07b85 100755 > --- a/configure > +++ b/configure > @@ -7825,7 +7825,7 @@ case "$target_name" in > ;; > m68k) > bflt="yes" > - gdb_xml_files="cf-core.xml cf-fp.xml m68k-fp.xml" > + gdb_xml_files="cf-core.xml cf-fp.xml m68k-core.xml m68k-fp.xml" > TARGET_SYSTBL_ABI=common > ;; > microblaze|microblazeel) > diff --git a/gdb-xml/m68k-core.xml b/gdb-xml/m68k-core.xml > new file mode 100644 > index 0000000..5b092d2 > --- /dev/null > +++ b/gdb-xml/m68k-core.xml > @@ -0,0 +1,29 @@ > +<?xml version="1.0"?> > +<!-- Copyright (C) 2008 Free Software Foundation, Inc. > + > + Copying and distribution of this file, with or without modification, > + are permitted in any medium without royalty provided the copyright > + notice and this notice are preserved. --> > +<!DOCTYPE feature SYSTEM "gdb-target.dtd"> > +<feature name="org.gnu.gdb.m68k.core"> > + <reg name="d0" bitsize="32"/> > + <reg name="d1" bitsize="32"/> > + <reg name="d2" bitsize="32"/> > + <reg name="d3" bitsize="32"/> > + <reg name="d4" bitsize="32"/> > + <reg name="d5" bitsize="32"/> > + <reg name="d6" bitsize="32"/> > + <reg name="d7" bitsize="32"/> > + <reg name="a0" bitsize="32" type="data_ptr"/> > + <reg name="a1" bitsize="32" type="data_ptr"/> > + <reg name="a2" bitsize="32" type="data_ptr"/> > + <reg name="a3" bitsize="32" type="data_ptr"/> > + <reg name="a4" bitsize="32" type="data_ptr"/> > + <reg name="a5" bitsize="32" type="data_ptr"/> > + <reg name="fp" bitsize="32" type="data_ptr"/> > + <reg name="sp" bitsize="32" type="data_ptr"/> > + > + <reg name="ps" bitsize="32"/> > + <reg name="pc" bitsize="32" type="code_ptr"/> > + > +</feature> > diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c > index 9445fcd..976e624 100644 > --- a/target/m68k/cpu.c > +++ b/target/m68k/cpu.c > @@ -297,6 +297,21 @@ static void m68k_cpu_class_init(ObjectClass *c, void *data) > dc->vmsd = &vmstate_m68k_cpu; > } > > +static void m68k_cpu_class_init_m68k_core(ObjectClass *c, void *data) > +{ > + CPUClass *cc = CPU_CLASS(c); > + > + cc->gdb_core_xml_file = "m68k-core.xml"; > +} > + > +#define DEFINE_M68K_CPU_TYPE_WITH_CLASS(cpu_model, initfn, classinit) \ > + { \ > + .name = M68K_CPU_TYPE_NAME(cpu_model), \ > + .instance_init = initfn, \ > + .parent = TYPE_M68K_CPU, \ > + .class_init = classinit, \ > + } > + > #define DEFINE_M68K_CPU_TYPE(cpu_model, initfn) \ > { \ > .name = M68K_CPU_TYPE_NAME(cpu_model), \ > @@ -314,11 +329,16 @@ static const TypeInfo m68k_cpus_type_infos[] = { > .class_size = sizeof(M68kCPUClass), > .class_init = m68k_cpu_class_init, > }, > - DEFINE_M68K_CPU_TYPE("m68000", m68000_cpu_initfn), > - DEFINE_M68K_CPU_TYPE("m68020", m68020_cpu_initfn), > - DEFINE_M68K_CPU_TYPE("m68030", m68030_cpu_initfn), > - DEFINE_M68K_CPU_TYPE("m68040", m68040_cpu_initfn), > - DEFINE_M68K_CPU_TYPE("m68060", m68060_cpu_initfn), > + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68000", m68000_cpu_initfn, > + m68k_cpu_class_init_m68k_core), > + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68020", m68020_cpu_initfn, > + m68k_cpu_class_init_m68k_core), > + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68030", m68030_cpu_initfn, > + m68k_cpu_class_init_m68k_core), > + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68040", m68040_cpu_initfn, > + m68k_cpu_class_init_m68k_core), > + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68060", m68060_cpu_initfn, > + m68k_cpu_class_init_m68k_core), > DEFINE_M68K_CPU_TYPE("m5206", m5206_cpu_initfn), > DEFINE_M68K_CPU_TYPE("m5208", m5208_cpu_initfn), > DEFINE_M68K_CPU_TYPE("cfv4e", cfv4e_cpu_initfn),
Le 4/20/20 à 6:13 PM, Alex Bennée a écrit : > > frederic.konrad@adacore.com writes: > >> From: KONRAD Frederic <frederic.konrad@adacore.com> >> >> Currently "cf-core.xml" is sent to GDB when using any m68k flavor. Thing is >> it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then expects >> a coldfire FPU instead of the default m68881 FPU. >> >> This is not OK because the m68881 floats registers are 96 bits wide so it >> crashes GDB with the following error message: >> >> (gdb) target remote localhost:7960 >> Remote debugging using localhost:7960 >> warning: Register "fp0" has an unsupported size (96 bits) >> warning: Register "fp1" has an unsupported size (96 bits) >> ... >> Remote 'g' packet reply is too long (expected 148 bytes, got 180 bytes): \ >> 00000000000[...]0000 >> >> With this patch: qemu-system-m68k -M none -cpu m68020 -s -S >> >> (gdb) tar rem :1234 >> Remote debugging using :1234 >> warning: No executable has been specified and target does not support >> determining executable automatically. Try using the "file" command. >> 0x00000000 in ?? () >> (gdb) p $fp0 >> $1 = nan(0xffffffffffffffff) >> >> Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> > > Well it solves the connection issue - but the FP values are still > hopelessly broken, from float_convs: > > from single: f32(-0x1.1874b200000000000000p+103:0xf30c3a59) > > in gdb > > fp0 <invalid float value> (raw 0x8c3a5900000000004066) Hi Alex, do you have a reproducer? With this simple example: ========================= .global _start .text _start: lea val, %a0 fmoves (%a0),%fp0 fmoves 4(%a0), %fp1 end: bra end .align 0x4 val: .float 0.12345678 .float 3.141592653589793 $ m68k-linux-gnu-gcc -g -Wl,-Ttext=0 main.S -mcpu=68020 -nostdlib -o main.elf $ m68k-linux-gnu-objdump -d main.elf main.elf: file format elf32-m68k Disassembly of section .text: 00000000 <_start>: 0: 41fa 0012 lea %pc@(14 <val>),%a0 4: f210 4400 fmoves %a0@,%fp0 8: f228 4480 0004 fmoves %a0@(4),%fp1 0000000e <end>: e: 6000 fffe braw e <end> ... 00000014 <val>: 14: 3dfc .short 0x3dfc 16: d6e9 4049 addaw %a1@(16457),%a3 1a: 0fdb bset %d7,%a3@+ I can run the executable in 5.0-rc3 + the patch: ================================================ $ xxx/qemu-for-upstream.git/m68k-softmmu/qemu-system-m68k --kernel main.elf \ -cpu m68020 -s -S -nographic And a GDB 8.3 I just built: =========================== $ xxx/bin/m68k-elf-gdb main.elf GNU gdb (GDB) 8.3 Copyright (C) 2019 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 "--host=x86_64-pc-linux-gnu --target=m68k-elf". 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"... Reading symbols from main.elf... (gdb) tar rem :1234 Remote debugging using :1234 _start () at main.S:5 5 lea val, %a0 (gdb) b end Breakpoint 1 at 0xe: file main.S, line 9. (gdb) c Continuing. Breakpoint 1, end () at main.S:9 9 bra end (gdb) info registers all d0 0x0 0 d1 0x0 0 d2 0x0 0 d3 0x0 0 d4 0x0 0 d5 0x0 0 d6 0x0 0 d7 0x0 0 a0 0x14 0x14 <val> a1 0x0 0x0 <_start> a2 0x0 0x0 <_start> a3 0x0 0x0 <_start> a4 0x0 0x0 <_start> a5 0x0 0x0 <_start> fp 0x0 0x0 <_start> sp 0x0 0x0 <_start> ps 0x2700 9984 pc 0xe 0xe <end> fp0 0.123456783592700958252 (raw 0x3ffb0000fcd6e90000000000) fp1 3.14159274101257324219 (raw 0x40000000c90fdb0000000000) fp2 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp3 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp4 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp5 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp6 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp7 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fpcontrol 0x0 0 fpstatus 0x0 0 fpiaddr 0x0 0x0 <_start> The value doesn't seems to much broken, the monitor gives me: (qemu) info registers D0 = 00000000 A0 = 00000014 F0 = 3ffb fcd6e90000000000 ( 0.123457) D1 = 00000000 A1 = 00000000 F1 = 4000 c90fdb0000000000 ( 3.14159) D2 = 00000000 A2 = 00000000 F2 = 7fff ffffffffffffffff ( nan) D3 = 00000000 A3 = 00000000 F3 = 7fff ffffffffffffffff ( nan) D4 = 00000000 A4 = 00000000 F4 = 7fff ffffffffffffffff ( nan) D5 = 00000000 A5 = 00000000 F5 = 7fff ffffffffffffffff ( nan) D6 = 00000000 A6 = 00000000 F6 = 7fff ffffffffffffffff ( nan) D7 = 00000000 A7 = 00000000 F7 = 7fff ffffffffffffffff ( nan) Did I miss anything? Cheers, Fred > >> --- >> configure | 2 +- >> gdb-xml/m68k-core.xml | 29 +++++++++++++++++++++++++++++ >> target/m68k/cpu.c | 30 +++++++++++++++++++++++++----- >> 3 files changed, 55 insertions(+), 6 deletions(-) >> create mode 100644 gdb-xml/m68k-core.xml >> >> diff --git a/configure b/configure >> index 23b5e93..2b07b85 100755 >> --- a/configure >> +++ b/configure >> @@ -7825,7 +7825,7 @@ case "$target_name" in >> ;; >> m68k) >> bflt="yes" >> - gdb_xml_files="cf-core.xml cf-fp.xml m68k-fp.xml" >> + gdb_xml_files="cf-core.xml cf-fp.xml m68k-core.xml m68k-fp.xml" >> TARGET_SYSTBL_ABI=common >> ;; >> microblaze|microblazeel) >> diff --git a/gdb-xml/m68k-core.xml b/gdb-xml/m68k-core.xml >> new file mode 100644 >> index 0000000..5b092d2 >> --- /dev/null >> +++ b/gdb-xml/m68k-core.xml >> @@ -0,0 +1,29 @@ >> +<?xml version="1.0"?> >> +<!-- Copyright (C) 2008 Free Software Foundation, Inc. >> + >> + Copying and distribution of this file, with or without modification, >> + are permitted in any medium without royalty provided the copyright >> + notice and this notice are preserved. --> >> +<!DOCTYPE feature SYSTEM "gdb-target.dtd"> >> +<feature name="org.gnu.gdb.m68k.core"> >> + <reg name="d0" bitsize="32"/> >> + <reg name="d1" bitsize="32"/> >> + <reg name="d2" bitsize="32"/> >> + <reg name="d3" bitsize="32"/> >> + <reg name="d4" bitsize="32"/> >> + <reg name="d5" bitsize="32"/> >> + <reg name="d6" bitsize="32"/> >> + <reg name="d7" bitsize="32"/> >> + <reg name="a0" bitsize="32" type="data_ptr"/> >> + <reg name="a1" bitsize="32" type="data_ptr"/> >> + <reg name="a2" bitsize="32" type="data_ptr"/> >> + <reg name="a3" bitsize="32" type="data_ptr"/> >> + <reg name="a4" bitsize="32" type="data_ptr"/> >> + <reg name="a5" bitsize="32" type="data_ptr"/> >> + <reg name="fp" bitsize="32" type="data_ptr"/> >> + <reg name="sp" bitsize="32" type="data_ptr"/> >> + >> + <reg name="ps" bitsize="32"/> >> + <reg name="pc" bitsize="32" type="code_ptr"/> >> + >> +</feature> >> diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c >> index 9445fcd..976e624 100644 >> --- a/target/m68k/cpu.c >> +++ b/target/m68k/cpu.c >> @@ -297,6 +297,21 @@ static void m68k_cpu_class_init(ObjectClass *c, void *data) >> dc->vmsd = &vmstate_m68k_cpu; >> } >> >> +static void m68k_cpu_class_init_m68k_core(ObjectClass *c, void *data) >> +{ >> + CPUClass *cc = CPU_CLASS(c); >> + >> + cc->gdb_core_xml_file = "m68k-core.xml"; >> +} >> + >> +#define DEFINE_M68K_CPU_TYPE_WITH_CLASS(cpu_model, initfn, classinit) \ >> + { \ >> + .name = M68K_CPU_TYPE_NAME(cpu_model), \ >> + .instance_init = initfn, \ >> + .parent = TYPE_M68K_CPU, \ >> + .class_init = classinit, \ >> + } >> + >> #define DEFINE_M68K_CPU_TYPE(cpu_model, initfn) \ >> { \ >> .name = M68K_CPU_TYPE_NAME(cpu_model), \ >> @@ -314,11 +329,16 @@ static const TypeInfo m68k_cpus_type_infos[] = { >> .class_size = sizeof(M68kCPUClass), >> .class_init = m68k_cpu_class_init, >> }, >> - DEFINE_M68K_CPU_TYPE("m68000", m68000_cpu_initfn), >> - DEFINE_M68K_CPU_TYPE("m68020", m68020_cpu_initfn), >> - DEFINE_M68K_CPU_TYPE("m68030", m68030_cpu_initfn), >> - DEFINE_M68K_CPU_TYPE("m68040", m68040_cpu_initfn), >> - DEFINE_M68K_CPU_TYPE("m68060", m68060_cpu_initfn), >> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68000", m68000_cpu_initfn, >> + m68k_cpu_class_init_m68k_core), >> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68020", m68020_cpu_initfn, >> + m68k_cpu_class_init_m68k_core), >> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68030", m68030_cpu_initfn, >> + m68k_cpu_class_init_m68k_core), >> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68040", m68040_cpu_initfn, >> + m68k_cpu_class_init_m68k_core), >> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68060", m68060_cpu_initfn, >> + m68k_cpu_class_init_m68k_core), >> DEFINE_M68K_CPU_TYPE("m5206", m5206_cpu_initfn), >> DEFINE_M68K_CPU_TYPE("m5208", m5208_cpu_initfn), >> DEFINE_M68K_CPU_TYPE("cfv4e", cfv4e_cpu_initfn), > >
Le 4/20/20 à 5:46 PM, Laurent Vivier a écrit : > Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : >> From: KONRAD Frederic <frederic.konrad@adacore.com> >> >> Currently "cf-core.xml" is sent to GDB when using any m68k flavor. Thing is >> it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then expects >> a coldfire FPU instead of the default m68881 FPU. > > > I checked in gdb sources and there is no cf definition. > > Moreover if I change only the cf to m68k in QEMU it seems to work in > both cases: > > diff --git a/gdb-xml/cf-core.xml b/gdb-xml/cf-core.xml > index b90af3042c..5b092d26de 100644 > --- a/gdb-xml/cf-core.xml > +++ b/gdb-xml/cf-core.xml > @@ -5,7 +5,7 @@ > are permitted in any medium without royalty provided the copyright > notice and this notice are preserved. --> > <!DOCTYPE feature SYSTEM "gdb-target.dtd"> > -<feature name="org.gnu.gdb.coldfire.core"> > +<feature name="org.gnu.gdb.m68k.core"> > <reg name="d0" bitsize="32"/> > <reg name="d1" bitsize="32"/> > <reg name="d2" bitsize="32"/> Doesn't that break gdb with coldfire? > diff --git a/gdb-xml/m68k-fp.xml b/gdb-xml/m68k-fp.xml > index 64290d1630..0ef74f7488 100644 > --- a/gdb-xml/m68k-fp.xml > +++ b/gdb-xml/m68k-fp.xml > @@ -5,7 +5,7 @@ > are permitted in any medium without royalty provided the copyright > notice and this notice are preserved. --> > <!DOCTYPE feature SYSTEM "gdb-target.dtd"> > -<feature name="org.gnu.gdb.coldfire.fp"> > +<feature name="org.gnu.gdb.m68k.fp"> > <reg name="fp0" bitsize="96" type="float" group="float"/> > <reg name="fp1" bitsize="96" type="float" group="float"/> > <reg name="fp2" bitsize="96" type="float" group="float"/> > > As I have not checked the gdb sources for that, I'd like to have your > opinion. In the GDB 8.3 sources: m68k-tdep.c:1091: feature = tdesc_find_feature (info.target_desc, "org.gnu.gdb.m68k.core"); if (feature == NULL) { feature = tdesc_find_feature (info.target_desc, "org.gnu.gdb.coldfire.core"); if (feature != NULL) flavour = m68k_coldfire_flavour; } Hence the change I suggested. Little later it has also: feature = tdesc_find_feature (info.target_desc, "org.gnu.gdb.coldfire.fp"); if (feature != NULL) { valid_p = 1; for (i = M68K_FP0_REGNUM; i <= M68K_FPI_REGNUM; i++) valid_p &= tdesc_numbered_register (feature, tdesc_data, i, m68k_register_names[i]); if (!valid_p) { tdesc_data_cleanup (tdesc_data); return NULL; } } else has_fp = 0; Which is why I didn't made the change you suggested about the m68k-fp.xml but I just tried with this additional change and it doesn't seem to hurt. Cheers, Fred > > Thanks, > Laurent >
Le 20/04/2020 à 21:08, KONRAD Frederic a écrit : > > > Le 4/20/20 à 5:46 PM, Laurent Vivier a écrit : >> Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : >>> From: KONRAD Frederic <frederic.konrad@adacore.com> >>> >>> Currently "cf-core.xml" is sent to GDB when using any m68k flavor. >>> Thing is >>> it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then >>> expects >>> a coldfire FPU instead of the default m68881 FPU. >> >> >> I checked in gdb sources and there is no cf definition. >> >> Moreover if I change only the cf to m68k in QEMU it seems to work in >> both cases: >> >> diff --git a/gdb-xml/cf-core.xml b/gdb-xml/cf-core.xml >> index b90af3042c..5b092d26de 100644 >> --- a/gdb-xml/cf-core.xml >> +++ b/gdb-xml/cf-core.xml >> @@ -5,7 +5,7 @@ >> are permitted in any medium without royalty provided the copyright >> notice and this notice are preserved. --> >> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> >> -<feature name="org.gnu.gdb.coldfire.core"> >> +<feature name="org.gnu.gdb.m68k.core"> >> <reg name="d0" bitsize="32"/> >> <reg name="d1" bitsize="32"/> >> <reg name="d2" bitsize="32"/> > > Doesn't that break gdb with coldfire? No, it seems to work, but I didn't test this really carefully. So perhaps we can only change the feature name in the two existing xml files and it will work for all the cases? (and renaming cf-core.xml to m68k-core.xml). The core files are the same for cf and m68k, so according to the sample code you show, if it finds "org.gnu.gdb.m68k.core" if will use for both. I think the only bug we have is the feature name is not good in m68k-fp.xml, and fixing that should be enough. Thanks, Laurent
Le 20/04/2020 à 21:08, KONRAD Frederic a écrit : > > > Le 4/20/20 à 5:46 PM, Laurent Vivier a écrit : >> Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : >>> From: KONRAD Frederic <frederic.konrad@adacore.com> >>> >>> Currently "cf-core.xml" is sent to GDB when using any m68k flavor. >>> Thing is >>> it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then >>> expects >>> a coldfire FPU instead of the default m68881 FPU. >> >> >> I checked in gdb sources and there is no cf definition. >> >> Moreover if I change only the cf to m68k in QEMU it seems to work in >> both cases: >> >> diff --git a/gdb-xml/cf-core.xml b/gdb-xml/cf-core.xml >> index b90af3042c..5b092d26de 100644 >> --- a/gdb-xml/cf-core.xml >> +++ b/gdb-xml/cf-core.xml >> @@ -5,7 +5,7 @@ >> are permitted in any medium without royalty provided the copyright >> notice and this notice are preserved. --> >> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> >> -<feature name="org.gnu.gdb.coldfire.core"> >> +<feature name="org.gnu.gdb.m68k.core"> >> <reg name="d0" bitsize="32"/> >> <reg name="d1" bitsize="32"/> >> <reg name="d2" bitsize="32"/> > > Doesn't that break gdb with coldfire? > >> diff --git a/gdb-xml/m68k-fp.xml b/gdb-xml/m68k-fp.xml >> index 64290d1630..0ef74f7488 100644 >> --- a/gdb-xml/m68k-fp.xml >> +++ b/gdb-xml/m68k-fp.xml >> @@ -5,7 +5,7 @@ >> are permitted in any medium without royalty provided the copyright >> notice and this notice are preserved. --> >> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> >> -<feature name="org.gnu.gdb.coldfire.fp"> >> +<feature name="org.gnu.gdb.m68k.fp"> >> <reg name="fp0" bitsize="96" type="float" group="float"/> >> <reg name="fp1" bitsize="96" type="float" group="float"/> >> <reg name="fp2" bitsize="96" type="float" group="float"/> >> >> As I have not checked the gdb sources for that, I'd like to have your >> opinion. > > In the GDB 8.3 sources: m68k-tdep.c:1091: > > feature = tdesc_find_feature (info.target_desc, > "org.gnu.gdb.m68k.core"); > if (feature == NULL) > { > feature = tdesc_find_feature (info.target_desc, > "org.gnu.gdb.coldfire.core"); > if (feature != NULL) > flavour = m68k_coldfire_flavour; > } > > Hence the change I suggested. Little later it has also: > > feature = tdesc_find_feature (info.target_desc, > "org.gnu.gdb.coldfire.fp"); > if (feature != NULL) > { > valid_p = 1; > for (i = M68K_FP0_REGNUM; i <= M68K_FPI_REGNUM; i++) > valid_p &= tdesc_numbered_register (feature, tdesc_data, i, > m68k_register_names[i]); > if (!valid_p) > { > tdesc_data_cleanup (tdesc_data); > return NULL; > } > } > else > has_fp = 0; > > Which is why I didn't made the change you suggested about the > m68k-fp.xml but I > just tried with this additional change and it doesn't seem to hurt. Thank you for your analysis, it seems a simpler patch works with coldfire and m68k. diff --git a/configure b/configure index 23b5e93752..b3be6d9c4b 100755 --- a/configure +++ b/configure @@ -7825,7 +7825,7 @@ case "$target_name" in ;; m68k) bflt="yes" - gdb_xml_files="cf-core.xml cf-fp.xml m68k-fp.xml" + gdb_xml_files="m68k-core.xml cf-fp.xml m68k-fp.xml" TARGET_SYSTBL_ABI=common ;; microblaze|microblazeel) diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c index 9445fcd6df..4e942a0a8e 100644 --- a/target/m68k/cpu.c +++ b/target/m68k/cpu.c @@ -292,7 +292,7 @@ static void m68k_cpu_class_init(ObjectClass *c, void *data) cc->tcg_initialize = m68k_tcg_init; cc->gdb_num_core_regs = 18; - cc->gdb_core_xml_file = "cf-core.xml"; + cc->gdb_core_xml_file = "m68k-core.xml"; dc->vmsd = &vmstate_m68k_cpu; } diff --git a/gdb-xml/cf-core.xml b/gdb-xml/m68k-core.xml similarity index 96% rename from gdb-xml/cf-core.xml rename to gdb-xml/m68k-core.xml index b90af3042c..5b092d26de 100644 --- a/gdb-xml/cf-core.xml +++ b/gdb-xml/m68k-core.xml @@ -5,7 +5,7 @@ are permitted in any medium without royalty provided the copyright notice and this notice are preserved. --> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> -<feature name="org.gnu.gdb.coldfire.core"> +<feature name="org.gnu.gdb.m68k.core"> <reg name="d0" bitsize="32"/> <reg name="d1" bitsize="32"/> <reg name="d2" bitsize="32"/> diff --git a/gdb-xml/m68k-fp.xml b/gdb-xml/m68k-fp.xml index 64290d1630..0ef74f7488 100644 --- a/gdb-xml/m68k-fp.xml +++ b/gdb-xml/m68k-fp.xml @@ -5,7 +5,7 @@ are permitted in any medium without royalty provided the copyright notice and this notice are preserved. --> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> -<feature name="org.gnu.gdb.coldfire.fp"> +<feature name="org.gnu.gdb.m68k.fp"> <reg name="fp0" bitsize="96" type="float" group="float"/> <reg name="fp1" bitsize="96" type="float" group="float"/> <reg name="fp2" bitsize="96" type="float" group="float"/> I have tested with both architectures: * -M q800: (gdb) info float fp0 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp1 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp2 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp3 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp4 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp5 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp6 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fp7 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) fpcontrol 0x0 0 fpstatus 0x0 0 fpiaddr 0x0 0x0 (gdb) info registers d0 0x0 0 d1 0x2 2 d2 0x462a0 287392 d3 0x40 64 d4 0x0 0 d5 0x0 0 d6 0x0 0 d7 0x0 0 a0 0x3e0000 0x3e0000 a1 0x3e351c 0x3e351c a2 0x3e351c 0x3e351c a3 0x3e0000 0x3e0000 a4 0x46390 0x46390 a5 0x2eed7e 0x2eed7e fp 0x2c65c 0x2c65c sp 0x3e1fa4 0x3e1fa4 ps 0x2000 8192 pc 0x2f00 0x2f00 fpcontrol 0x0 0 fpstatus 0x0 0 fpiaddr 0x0 0x0 * -cpu cfv4e (gdb) info registers d0 0x0 0 d1 0x401c0b40 1075579712 d2 0x0 0 d3 0x0 0 d4 0x0 0 d5 0x0 0 d6 0x0 0 d7 0x0 0 a0 0x4015c008 0x4015c008 a1 0x40151092 0x40151092 a2 0x401146c8 0x401146c8 a3 0x4016b189 0x4016b189 a4 0x400ac60a 0x400ac60a a5 0x40017078 0x40017078 fp 0x4015cff8 0x4015cff8 sp 0x4015cfcc 0x4015cfcc ps 0x2000 8192 pc 0x40010a2a 0x40010a2a fpcontrol 0x0 0 fpstatus 0x0 0 fpiaddr 0x0 0x0 (gdb) info float fp0 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) fp1 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) fp2 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) fp3 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) fp4 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) fp5 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) fp6 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) fp7 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) fpcontrol 0x0 0 fpstatus 0x0 0 fpiaddr 0x0 0x0 All with a native GDB from debian/sid (GNU gdb (Debian 9.1-3) 9.1). Thanks, Laurent
Le 4/20/20 à 10:43 PM, Laurent Vivier a écrit : > Le 20/04/2020 à 21:08, KONRAD Frederic a écrit : >> >> >> Le 4/20/20 à 5:46 PM, Laurent Vivier a écrit : >>> Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : >>>> From: KONRAD Frederic <frederic.konrad@adacore.com> >>>> >>>> Currently "cf-core.xml" is sent to GDB when using any m68k flavor. >>>> Thing is >>>> it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then >>>> expects >>>> a coldfire FPU instead of the default m68881 FPU. >>> >>> >>> I checked in gdb sources and there is no cf definition. >>> >>> Moreover if I change only the cf to m68k in QEMU it seems to work in >>> both cases: >>> >>> diff --git a/gdb-xml/cf-core.xml b/gdb-xml/cf-core.xml >>> index b90af3042c..5b092d26de 100644 >>> --- a/gdb-xml/cf-core.xml >>> +++ b/gdb-xml/cf-core.xml >>> @@ -5,7 +5,7 @@ >>> are permitted in any medium without royalty provided the copyright >>> notice and this notice are preserved. --> >>> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> >>> -<feature name="org.gnu.gdb.coldfire.core"> >>> +<feature name="org.gnu.gdb.m68k.core"> >>> <reg name="d0" bitsize="32"/> >>> <reg name="d1" bitsize="32"/> >>> <reg name="d2" bitsize="32"/> >> >> Doesn't that break gdb with coldfire? >> >>> diff --git a/gdb-xml/m68k-fp.xml b/gdb-xml/m68k-fp.xml >>> index 64290d1630..0ef74f7488 100644 >>> --- a/gdb-xml/m68k-fp.xml >>> +++ b/gdb-xml/m68k-fp.xml >>> @@ -5,7 +5,7 @@ >>> are permitted in any medium without royalty provided the copyright >>> notice and this notice are preserved. --> >>> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> >>> -<feature name="org.gnu.gdb.coldfire.fp"> >>> +<feature name="org.gnu.gdb.m68k.fp"> >>> <reg name="fp0" bitsize="96" type="float" group="float"/> >>> <reg name="fp1" bitsize="96" type="float" group="float"/> >>> <reg name="fp2" bitsize="96" type="float" group="float"/> >>> >>> As I have not checked the gdb sources for that, I'd like to have your >>> opinion. >> >> In the GDB 8.3 sources: m68k-tdep.c:1091: >> >> feature = tdesc_find_feature (info.target_desc, >> "org.gnu.gdb.m68k.core"); >> if (feature == NULL) >> { >> feature = tdesc_find_feature (info.target_desc, >> "org.gnu.gdb.coldfire.core"); >> if (feature != NULL) >> flavour = m68k_coldfire_flavour; >> } >> >> Hence the change I suggested. Little later it has also: >> >> feature = tdesc_find_feature (info.target_desc, >> "org.gnu.gdb.coldfire.fp"); >> if (feature != NULL) >> { >> valid_p = 1; >> for (i = M68K_FP0_REGNUM; i <= M68K_FPI_REGNUM; i++) >> valid_p &= tdesc_numbered_register (feature, tdesc_data, i, >> m68k_register_names[i]); >> if (!valid_p) >> { >> tdesc_data_cleanup (tdesc_data); >> return NULL; >> } >> } >> else >> has_fp = 0; >> >> Which is why I didn't made the change you suggested about the >> m68k-fp.xml but I >> just tried with this additional change and it doesn't seem to hurt. > > Thank you for your analysis, it seems a simpler patch works with > coldfire and m68k. Hi Laurent, Arg sorry I though I said that in an other email but apparently I forgot to hit the send button. The issue with this simpler patch is that GDB will not set: flavour = m68k_coldfire_flavour when we are running coldfire emulation, and that might break the ABI within GDB. According to the comments there, float are returned within D0 for ColdFire and not the other one. That's why I cared to keep them separate ie: send the right "feature name" for the right cpu we are modelling. > > diff --git a/configure b/configure > index 23b5e93752..b3be6d9c4b 100755 > --- a/configure > +++ b/configure > @@ -7825,7 +7825,7 @@ case "$target_name" in > ;; > m68k) > bflt="yes" > - gdb_xml_files="cf-core.xml cf-fp.xml m68k-fp.xml" > + gdb_xml_files="m68k-core.xml cf-fp.xml m68k-fp.xml" > TARGET_SYSTBL_ABI=common > ;; > microblaze|microblazeel) > diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c > index 9445fcd6df..4e942a0a8e 100644 > --- a/target/m68k/cpu.c > +++ b/target/m68k/cpu.c > @@ -292,7 +292,7 @@ static void m68k_cpu_class_init(ObjectClass *c, void > *data) > cc->tcg_initialize = m68k_tcg_init; > > cc->gdb_num_core_regs = 18; > - cc->gdb_core_xml_file = "cf-core.xml"; > + cc->gdb_core_xml_file = "m68k-core.xml"; > > dc->vmsd = &vmstate_m68k_cpu; > } > diff --git a/gdb-xml/cf-core.xml b/gdb-xml/m68k-core.xml > similarity index 96% > rename from gdb-xml/cf-core.xml > rename to gdb-xml/m68k-core.xml > index b90af3042c..5b092d26de 100644 > --- a/gdb-xml/cf-core.xml > +++ b/gdb-xml/m68k-core.xml > @@ -5,7 +5,7 @@ > are permitted in any medium without royalty provided the copyright > notice and this notice are preserved. --> > <!DOCTYPE feature SYSTEM "gdb-target.dtd"> > -<feature name="org.gnu.gdb.coldfire.core"> > +<feature name="org.gnu.gdb.m68k.core"> > <reg name="d0" bitsize="32"/> > <reg name="d1" bitsize="32"/> > <reg name="d2" bitsize="32"/> > diff --git a/gdb-xml/m68k-fp.xml b/gdb-xml/m68k-fp.xml > index 64290d1630..0ef74f7488 100644 > --- a/gdb-xml/m68k-fp.xml > +++ b/gdb-xml/m68k-fp.xml > @@ -5,7 +5,7 @@ > are permitted in any medium without royalty provided the copyright > notice and this notice are preserved. --> > <!DOCTYPE feature SYSTEM "gdb-target.dtd"> > -<feature name="org.gnu.gdb.coldfire.fp"> > +<feature name="org.gnu.gdb.m68k.fp"> > <reg name="fp0" bitsize="96" type="float" group="float"/> > <reg name="fp1" bitsize="96" type="float" group="float"/> > <reg name="fp2" bitsize="96" type="float" group="float"/> > > I have tested with both architectures: > > * -M q800: > > (gdb) info float > fp0 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) > fp1 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) > fp2 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) > fp3 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) > fp4 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) > fp5 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) > fp6 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) > fp7 nan(0xffffffffffffffff) (raw 0x7fff0000ffffffffffffffff) > fpcontrol 0x0 0 > fpstatus 0x0 0 > fpiaddr 0x0 0x0 > (gdb) info registers > d0 0x0 0 > d1 0x2 2 > d2 0x462a0 287392 > d3 0x40 64 > d4 0x0 0 > d5 0x0 0 > d6 0x0 0 > d7 0x0 0 > a0 0x3e0000 0x3e0000 > a1 0x3e351c 0x3e351c > a2 0x3e351c 0x3e351c > a3 0x3e0000 0x3e0000 > a4 0x46390 0x46390 > a5 0x2eed7e 0x2eed7e > fp 0x2c65c 0x2c65c > sp 0x3e1fa4 0x3e1fa4 > ps 0x2000 8192 > pc 0x2f00 0x2f00 > fpcontrol 0x0 0 > fpstatus 0x0 0 > fpiaddr 0x0 0x0 > > * -cpu cfv4e > > (gdb) info registers > d0 0x0 0 > d1 0x401c0b40 1075579712 > d2 0x0 0 > d3 0x0 0 > d4 0x0 0 > d5 0x0 0 > d6 0x0 0 > d7 0x0 0 > a0 0x4015c008 0x4015c008 > a1 0x40151092 0x40151092 > a2 0x401146c8 0x401146c8 > a3 0x4016b189 0x4016b189 > a4 0x400ac60a 0x400ac60a > a5 0x40017078 0x40017078 > fp 0x4015cff8 0x4015cff8 > sp 0x4015cfcc 0x4015cfcc > ps 0x2000 8192 > pc 0x40010a2a 0x40010a2a > fpcontrol 0x0 0 > fpstatus 0x0 0 > fpiaddr 0x0 0x0 > (gdb) info float > fp0 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) > fp1 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) > fp2 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) > fp3 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) > fp4 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) > fp5 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) > fp6 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) > fp7 nan(0xfffffffffffff) (raw 0x7fffffffffffffff) > fpcontrol 0x0 0 > fpstatus 0x0 0 > fpiaddr 0x0 0x0 > > > All with a native GDB from debian/sid (GNU gdb (Debian 9.1-3) 9.1). > > Thanks, > Laurent >
Le 21/04/2020 à 11:47, KONRAD Frederic a écrit : > > > Le 4/20/20 à 10:43 PM, Laurent Vivier a écrit : >> Le 20/04/2020 à 21:08, KONRAD Frederic a écrit : >>> >>> >>> Le 4/20/20 à 5:46 PM, Laurent Vivier a écrit : >>>> Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : >>>>> From: KONRAD Frederic <frederic.konrad@adacore.com> >>>>> >>>>> Currently "cf-core.xml" is sent to GDB when using any m68k flavor. >>>>> Thing is >>>>> it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then >>>>> expects >>>>> a coldfire FPU instead of the default m68881 FPU. >>>> >>>> >>>> I checked in gdb sources and there is no cf definition. >>>> >>>> Moreover if I change only the cf to m68k in QEMU it seems to work in >>>> both cases: >>>> >>>> diff --git a/gdb-xml/cf-core.xml b/gdb-xml/cf-core.xml >>>> index b90af3042c..5b092d26de 100644 >>>> --- a/gdb-xml/cf-core.xml >>>> +++ b/gdb-xml/cf-core.xml >>>> @@ -5,7 +5,7 @@ >>>> are permitted in any medium without royalty provided the >>>> copyright >>>> notice and this notice are preserved. --> >>>> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> >>>> -<feature name="org.gnu.gdb.coldfire.core"> >>>> +<feature name="org.gnu.gdb.m68k.core"> >>>> <reg name="d0" bitsize="32"/> >>>> <reg name="d1" bitsize="32"/> >>>> <reg name="d2" bitsize="32"/> >>> >>> Doesn't that break gdb with coldfire? >>> >>>> diff --git a/gdb-xml/m68k-fp.xml b/gdb-xml/m68k-fp.xml >>>> index 64290d1630..0ef74f7488 100644 >>>> --- a/gdb-xml/m68k-fp.xml >>>> +++ b/gdb-xml/m68k-fp.xml >>>> @@ -5,7 +5,7 @@ >>>> are permitted in any medium without royalty provided the >>>> copyright >>>> notice and this notice are preserved. --> >>>> <!DOCTYPE feature SYSTEM "gdb-target.dtd"> >>>> -<feature name="org.gnu.gdb.coldfire.fp"> >>>> +<feature name="org.gnu.gdb.m68k.fp"> >>>> <reg name="fp0" bitsize="96" type="float" group="float"/> >>>> <reg name="fp1" bitsize="96" type="float" group="float"/> >>>> <reg name="fp2" bitsize="96" type="float" group="float"/> >>>> >>>> As I have not checked the gdb sources for that, I'd like to have your >>>> opinion. >>> >>> In the GDB 8.3 sources: m68k-tdep.c:1091: >>> >>> feature = tdesc_find_feature (info.target_desc, >>> "org.gnu.gdb.m68k.core"); >>> if (feature == NULL) >>> { >>> feature = tdesc_find_feature (info.target_desc, >>> "org.gnu.gdb.coldfire.core"); >>> if (feature != NULL) >>> flavour = m68k_coldfire_flavour; >>> } >>> >>> Hence the change I suggested. Little later it has also: >>> >>> feature = tdesc_find_feature (info.target_desc, >>> "org.gnu.gdb.coldfire.fp"); >>> if (feature != NULL) >>> { >>> valid_p = 1; >>> for (i = M68K_FP0_REGNUM; i <= M68K_FPI_REGNUM; i++) >>> valid_p &= tdesc_numbered_register (feature, tdesc_data, i, >>> m68k_register_names[i]); >>> if (!valid_p) >>> { >>> tdesc_data_cleanup (tdesc_data); >>> return NULL; >>> } >>> } >>> else >>> has_fp = 0; >>> >>> Which is why I didn't made the change you suggested about the >>> m68k-fp.xml but I >>> just tried with this additional change and it doesn't seem to hurt. >> >> Thank you for your analysis, it seems a simpler patch works with >> coldfire and m68k. > > Hi Laurent, > > Arg sorry I though I said that in an other email but apparently I forgot > to hit > the send button. The issue with this simpler patch is that GDB will not > set: > > flavour = m68k_coldfire_flavour > > when we are running coldfire emulation, and that might break the ABI > within GDB. > According to the comments there, float are returned within D0 for > ColdFire and > not the other one. That's why I cared to keep them separate ie: send > the right > "feature name" for the right cpu we are modelling. Yes, you are right. I've added some traces in GDB to check the result. I trace the features pointer, the flavour, etc. Here what I have with your patch: coldfire: org.gnu.gdb.m68k.core (nil) org.gnu.gdb.coldfire.core 0x10e6bf0 org.gnu.gdb.coldfire.fp 0x1197a70 tdep->fpregs_present 1 dep->flavour m68k_coldfire_flavour floatformats_ieee_double set_gdbarch_decr_pc_after_break 2 tdep->float_return 0 m68k: org.gnu.gdb.m68k.core 0x1c21310 org.gnu.gdb.coldfire.fp 0x1b65d10 tdep->fpregs_present 1 tdep->flavour m68k_no_flavour floatformats_m68881_ext tdep->float_return 1 All the values are ok, but I try change "org.gnu.gdb.coldfire.fp" to "org.gnu.gdb.m68k.fp" in gdb-xml/m68k-fp.xml and I think it breaks something because tdep->fpregs_present turns to be 0: m68k: org.gnu.gdb.m68k.core 0x2796b60 org.gnu.gdb.coldfire.fp (nil) tdep->fpregs_present 0 tdep->flavour m68k_no_flavour floatformats_m68881_ext I also tried my patch and as you said it doesn't set the good floatformat for coldfire (and not the good value for fpregs_present for m68k): coldfire: org.gnu.gdb.m68k.core 0xbdb320 org.gnu.gdb.coldfire.fp 0xbd38d0 tdep->fpregs_present 1 tdep->flavour m68k_no_flavour floatformats_m68881_ext tdep->float_return 1 m68k: org.gnu.gdb.m68k.core 0x1e2cb60 org.gnu.gdb.coldfire.fp (nil) tdep->fpregs_present 0 tdep->flavour m68k_no_flavour floatformats_m68881_ext Thanks, Laurent
Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : > From: KONRAD Frederic <frederic.konrad@adacore.com> > > Currently "cf-core.xml" is sent to GDB when using any m68k flavor. Thing is > it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then expects > a coldfire FPU instead of the default m68881 FPU. > > This is not OK because the m68881 floats registers are 96 bits wide so it > crashes GDB with the following error message: > > (gdb) target remote localhost:7960 > Remote debugging using localhost:7960 > warning: Register "fp0" has an unsupported size (96 bits) > warning: Register "fp1" has an unsupported size (96 bits) > ... > Remote 'g' packet reply is too long (expected 148 bytes, got 180 bytes): \ > 00000000000[...]0000 > > With this patch: qemu-system-m68k -M none -cpu m68020 -s -S > > (gdb) tar rem :1234 > Remote debugging using :1234 > warning: No executable has been specified and target does not support > determining executable automatically. Try using the "file" command. > 0x00000000 in ?? () > (gdb) p $fp0 > $1 = nan(0xffffffffffffffff) > > Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> > --- > configure | 2 +- > gdb-xml/m68k-core.xml | 29 +++++++++++++++++++++++++++++ > target/m68k/cpu.c | 30 +++++++++++++++++++++++++----- > 3 files changed, 55 insertions(+), 6 deletions(-) > create mode 100644 gdb-xml/m68k-core.xml > > diff --git a/configure b/configure > index 23b5e93..2b07b85 100755 > --- a/configure > +++ b/configure > @@ -7825,7 +7825,7 @@ case "$target_name" in > ;; > m68k) > bflt="yes" > - gdb_xml_files="cf-core.xml cf-fp.xml m68k-fp.xml" > + gdb_xml_files="cf-core.xml cf-fp.xml m68k-core.xml m68k-fp.xml" > TARGET_SYSTBL_ABI=common > ;; > microblaze|microblazeel) > diff --git a/gdb-xml/m68k-core.xml b/gdb-xml/m68k-core.xml > new file mode 100644 > index 0000000..5b092d2 > --- /dev/null > +++ b/gdb-xml/m68k-core.xml > @@ -0,0 +1,29 @@ > +<?xml version="1.0"?> > +<!-- Copyright (C) 2008 Free Software Foundation, Inc. > + > + Copying and distribution of this file, with or without modification, > + are permitted in any medium without royalty provided the copyright > + notice and this notice are preserved. --> > +<!DOCTYPE feature SYSTEM "gdb-target.dtd"> > +<feature name="org.gnu.gdb.m68k.core"> > + <reg name="d0" bitsize="32"/> > + <reg name="d1" bitsize="32"/> > + <reg name="d2" bitsize="32"/> > + <reg name="d3" bitsize="32"/> > + <reg name="d4" bitsize="32"/> > + <reg name="d5" bitsize="32"/> > + <reg name="d6" bitsize="32"/> > + <reg name="d7" bitsize="32"/> > + <reg name="a0" bitsize="32" type="data_ptr"/> > + <reg name="a1" bitsize="32" type="data_ptr"/> > + <reg name="a2" bitsize="32" type="data_ptr"/> > + <reg name="a3" bitsize="32" type="data_ptr"/> > + <reg name="a4" bitsize="32" type="data_ptr"/> > + <reg name="a5" bitsize="32" type="data_ptr"/> > + <reg name="fp" bitsize="32" type="data_ptr"/> > + <reg name="sp" bitsize="32" type="data_ptr"/> > + > + <reg name="ps" bitsize="32"/> > + <reg name="pc" bitsize="32" type="code_ptr"/> > + > +</feature> > diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c > index 9445fcd..976e624 100644 > --- a/target/m68k/cpu.c > +++ b/target/m68k/cpu.c > @@ -297,6 +297,21 @@ static void m68k_cpu_class_init(ObjectClass *c, void *data) > dc->vmsd = &vmstate_m68k_cpu; > } > > +static void m68k_cpu_class_init_m68k_core(ObjectClass *c, void *data) > +{ > + CPUClass *cc = CPU_CLASS(c); > + > + cc->gdb_core_xml_file = "m68k-core.xml"; > +} Could you also add a m68k_cpu_class_init_cf_core() and move the cf-core.xml into it? > + > +#define DEFINE_M68K_CPU_TYPE_WITH_CLASS(cpu_model, initfn, classinit) \ > + { \ > + .name = M68K_CPU_TYPE_NAME(cpu_model), \ > + .instance_init = initfn, \ > + .parent = TYPE_M68K_CPU, \ > + .class_init = classinit, \ > + } > + I would prefer to have two macros with no class parameter, something like DEFINE_M68K_CPU_TYPE_M68K() and DEFINE_M68K_CPU_TYPE_CF(). > #define DEFINE_M68K_CPU_TYPE(cpu_model, initfn) \ > { \ > .name = M68K_CPU_TYPE_NAME(cpu_model), \ > @@ -314,11 +329,16 @@ static const TypeInfo m68k_cpus_type_infos[] = { > .class_size = sizeof(M68kCPUClass), > .class_init = m68k_cpu_class_init, > }, > - DEFINE_M68K_CPU_TYPE("m68000", m68000_cpu_initfn), > - DEFINE_M68K_CPU_TYPE("m68020", m68020_cpu_initfn), > - DEFINE_M68K_CPU_TYPE("m68030", m68030_cpu_initfn), > - DEFINE_M68K_CPU_TYPE("m68040", m68040_cpu_initfn), > - DEFINE_M68K_CPU_TYPE("m68060", m68060_cpu_initfn), > + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68000", m68000_cpu_initfn, > + m68k_cpu_class_init_m68k_core), > + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68020", m68020_cpu_initfn, > + m68k_cpu_class_init_m68k_core), > + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68030", m68030_cpu_initfn, > + m68k_cpu_class_init_m68k_core), > + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68040", m68040_cpu_initfn, > + m68k_cpu_class_init_m68k_core), > + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68060", m68060_cpu_initfn, > + m68k_cpu_class_init_m68k_core), > DEFINE_M68K_CPU_TYPE("m5206", m5206_cpu_initfn), > DEFINE_M68K_CPU_TYPE("m5208", m5208_cpu_initfn), > DEFINE_M68K_CPU_TYPE("cfv4e", cfv4e_cpu_initfn), > I think we can also have something like DEFINE_M68K_CPU_TYPE_M68K(m68000) or DEFINE_M68K_CPU_TYPE_CF(m5206) and deduce initfn function name from the macro parameter. Thanks, Laurent
Le 4/27/20 à 9:53 AM, Laurent Vivier a écrit : > Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : >> From: KONRAD Frederic <frederic.konrad@adacore.com> >> >> Currently "cf-core.xml" is sent to GDB when using any m68k flavor. Thing is >> it uses the "org.gnu.gdb.coldfire.core" feature name and gdb 8.3 then expects >> a coldfire FPU instead of the default m68881 FPU. >> >> This is not OK because the m68881 floats registers are 96 bits wide so it >> crashes GDB with the following error message: >> >> (gdb) target remote localhost:7960 >> Remote debugging using localhost:7960 >> warning: Register "fp0" has an unsupported size (96 bits) >> warning: Register "fp1" has an unsupported size (96 bits) >> ... >> Remote 'g' packet reply is too long (expected 148 bytes, got 180 bytes): \ >> 00000000000[...]0000 >> >> With this patch: qemu-system-m68k -M none -cpu m68020 -s -S >> >> (gdb) tar rem :1234 >> Remote debugging using :1234 >> warning: No executable has been specified and target does not support >> determining executable automatically. Try using the "file" command. >> 0x00000000 in ?? () >> (gdb) p $fp0 >> $1 = nan(0xffffffffffffffff) >> >> Signed-off-by: KONRAD Frederic <frederic.konrad@adacore.com> >> --- >> configure | 2 +- >> gdb-xml/m68k-core.xml | 29 +++++++++++++++++++++++++++++ >> target/m68k/cpu.c | 30 +++++++++++++++++++++++++----- >> 3 files changed, 55 insertions(+), 6 deletions(-) >> create mode 100644 gdb-xml/m68k-core.xml >> >> diff --git a/configure b/configure >> index 23b5e93..2b07b85 100755 >> --- a/configure >> +++ b/configure >> @@ -7825,7 +7825,7 @@ case "$target_name" in >> ;; >> m68k) >> bflt="yes" >> - gdb_xml_files="cf-core.xml cf-fp.xml m68k-fp.xml" >> + gdb_xml_files="cf-core.xml cf-fp.xml m68k-core.xml m68k-fp.xml" >> TARGET_SYSTBL_ABI=common >> ;; >> microblaze|microblazeel) >> diff --git a/gdb-xml/m68k-core.xml b/gdb-xml/m68k-core.xml >> new file mode 100644 >> index 0000000..5b092d2 >> --- /dev/null >> +++ b/gdb-xml/m68k-core.xml >> @@ -0,0 +1,29 @@ >> +<?xml version="1.0"?> >> +<!-- Copyright (C) 2008 Free Software Foundation, Inc. >> + >> + Copying and distribution of this file, with or without modification, >> + are permitted in any medium without royalty provided the copyright >> + notice and this notice are preserved. --> >> +<!DOCTYPE feature SYSTEM "gdb-target.dtd"> >> +<feature name="org.gnu.gdb.m68k.core"> >> + <reg name="d0" bitsize="32"/> >> + <reg name="d1" bitsize="32"/> >> + <reg name="d2" bitsize="32"/> >> + <reg name="d3" bitsize="32"/> >> + <reg name="d4" bitsize="32"/> >> + <reg name="d5" bitsize="32"/> >> + <reg name="d6" bitsize="32"/> >> + <reg name="d7" bitsize="32"/> >> + <reg name="a0" bitsize="32" type="data_ptr"/> >> + <reg name="a1" bitsize="32" type="data_ptr"/> >> + <reg name="a2" bitsize="32" type="data_ptr"/> >> + <reg name="a3" bitsize="32" type="data_ptr"/> >> + <reg name="a4" bitsize="32" type="data_ptr"/> >> + <reg name="a5" bitsize="32" type="data_ptr"/> >> + <reg name="fp" bitsize="32" type="data_ptr"/> >> + <reg name="sp" bitsize="32" type="data_ptr"/> >> + >> + <reg name="ps" bitsize="32"/> >> + <reg name="pc" bitsize="32" type="code_ptr"/> >> + >> +</feature> >> diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c >> index 9445fcd..976e624 100644 >> --- a/target/m68k/cpu.c >> +++ b/target/m68k/cpu.c >> @@ -297,6 +297,21 @@ static void m68k_cpu_class_init(ObjectClass *c, void *data) >> dc->vmsd = &vmstate_m68k_cpu; >> } >> >> +static void m68k_cpu_class_init_m68k_core(ObjectClass *c, void *data) >> +{ >> + CPUClass *cc = CPU_CLASS(c); >> + >> + cc->gdb_core_xml_file = "m68k-core.xml"; >> +} > > Could you also add a m68k_cpu_class_init_cf_core() and move the > cf-core.xml into it? Yes I can do that: - DEFINE_M68K_CPU_TYPE_M68K will use m68k_cpu_class_init_m68k_core. - DEFINE_M68K_CPU_TYPE_CF will use m68k_cpu_class_init_cf_core. - drop xxx_WITH_CLASS behind. > >> + >> +#define DEFINE_M68K_CPU_TYPE_WITH_CLASS(cpu_model, initfn, classinit) \ >> + { \ >> + .name = M68K_CPU_TYPE_NAME(cpu_model), \ >> + .instance_init = initfn, \ >> + .parent = TYPE_M68K_CPU, \ >> + .class_init = classinit, \ >> + } >> + > > I would prefer to have two macros with no class parameter, something > like DEFINE_M68K_CPU_TYPE_M68K() and DEFINE_M68K_CPU_TYPE_CF(). > >> #define DEFINE_M68K_CPU_TYPE(cpu_model, initfn) \ >> { \ >> .name = M68K_CPU_TYPE_NAME(cpu_model), \ >> @@ -314,11 +329,16 @@ static const TypeInfo m68k_cpus_type_infos[] = { >> .class_size = sizeof(M68kCPUClass), >> .class_init = m68k_cpu_class_init, >> }, >> - DEFINE_M68K_CPU_TYPE("m68000", m68000_cpu_initfn), >> - DEFINE_M68K_CPU_TYPE("m68020", m68020_cpu_initfn), >> - DEFINE_M68K_CPU_TYPE("m68030", m68030_cpu_initfn), >> - DEFINE_M68K_CPU_TYPE("m68040", m68040_cpu_initfn), >> - DEFINE_M68K_CPU_TYPE("m68060", m68060_cpu_initfn), >> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68000", m68000_cpu_initfn, >> + m68k_cpu_class_init_m68k_core), >> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68020", m68020_cpu_initfn, >> + m68k_cpu_class_init_m68k_core), >> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68030", m68030_cpu_initfn, >> + m68k_cpu_class_init_m68k_core), >> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68040", m68040_cpu_initfn, >> + m68k_cpu_class_init_m68k_core), >> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68060", m68060_cpu_initfn, >> + m68k_cpu_class_init_m68k_core), >> DEFINE_M68K_CPU_TYPE("m5206", m5206_cpu_initfn), >> DEFINE_M68K_CPU_TYPE("m5208", m5208_cpu_initfn), >> DEFINE_M68K_CPU_TYPE("cfv4e", cfv4e_cpu_initfn), But what about the "any" which is out of context here? DEFINE_M68K_CPU_TYPE("any", any_cpu_initfn), Should it be TYPE_M68K or TYPE_CF in which case which xml will it take? I guess we can take TYPE_CF so it doesn't change from what is done today. >> > > I think we can also have something like > DEFINE_M68K_CPU_TYPE_M68K(m68000) or DEFINE_M68K_CPU_TYPE_CF(m5206) and > deduce initfn function name from the macro parameter. > Why not. Fred > Thanks, > Laurent >
Le 28/04/2020 à 15:19, KONRAD Frederic a écrit : > > > Le 4/27/20 à 9:53 AM, Laurent Vivier a écrit : >> Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : >>> From: KONRAD Frederic <frederic.konrad@adacore.com> ... >> I would prefer to have two macros with no class parameter, something >> like DEFINE_M68K_CPU_TYPE_M68K() and DEFINE_M68K_CPU_TYPE_CF(). >> >>> #define DEFINE_M68K_CPU_TYPE(cpu_model, initfn) \ >>> { \ >>> .name = M68K_CPU_TYPE_NAME(cpu_model), \ >>> @@ -314,11 +329,16 @@ static const TypeInfo m68k_cpus_type_infos[] = { >>> .class_size = sizeof(M68kCPUClass), >>> .class_init = m68k_cpu_class_init, >>> }, >>> - DEFINE_M68K_CPU_TYPE("m68000", m68000_cpu_initfn), >>> - DEFINE_M68K_CPU_TYPE("m68020", m68020_cpu_initfn), >>> - DEFINE_M68K_CPU_TYPE("m68030", m68030_cpu_initfn), >>> - DEFINE_M68K_CPU_TYPE("m68040", m68040_cpu_initfn), >>> - DEFINE_M68K_CPU_TYPE("m68060", m68060_cpu_initfn), >>> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68000", m68000_cpu_initfn, >>> + m68k_cpu_class_init_m68k_core), >>> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68020", m68020_cpu_initfn, >>> + m68k_cpu_class_init_m68k_core), >>> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68030", m68030_cpu_initfn, >>> + m68k_cpu_class_init_m68k_core), >>> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68040", m68040_cpu_initfn, >>> + m68k_cpu_class_init_m68k_core), >>> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68060", m68060_cpu_initfn, >>> + m68k_cpu_class_init_m68k_core), >>> DEFINE_M68K_CPU_TYPE("m5206", m5206_cpu_initfn), >>> DEFINE_M68K_CPU_TYPE("m5208", m5208_cpu_initfn), >>> DEFINE_M68K_CPU_TYPE("cfv4e", cfv4e_cpu_initfn), > > But what about the "any" which is out of context here? > > DEFINE_M68K_CPU_TYPE("any", any_cpu_initfn), > > Should it be TYPE_M68K or TYPE_CF in which case which xml will it take? > I guess > we can take TYPE_CF so it doesn't change from what is done today. > Yes, "any" has been introduced with coldfire CPUs and defines CF_FPU, so it uses 64bit float registers. Thanks, Laurent
Le 4/28/20 à 4:13 PM, Laurent Vivier a écrit : > Le 28/04/2020 à 15:19, KONRAD Frederic a écrit : >> >> >> Le 4/27/20 à 9:53 AM, Laurent Vivier a écrit : >>> Le 20/04/2020 à 16:01, frederic.konrad@adacore.com a écrit : >>>> From: KONRAD Frederic <frederic.konrad@adacore.com> > ... >>> I would prefer to have two macros with no class parameter, something >>> like DEFINE_M68K_CPU_TYPE_M68K() and DEFINE_M68K_CPU_TYPE_CF(). >>> >>>> #define DEFINE_M68K_CPU_TYPE(cpu_model, initfn) \ >>>> { \ >>>> .name = M68K_CPU_TYPE_NAME(cpu_model), \ >>>> @@ -314,11 +329,16 @@ static const TypeInfo m68k_cpus_type_infos[] = { >>>> .class_size = sizeof(M68kCPUClass), >>>> .class_init = m68k_cpu_class_init, >>>> }, >>>> - DEFINE_M68K_CPU_TYPE("m68000", m68000_cpu_initfn), >>>> - DEFINE_M68K_CPU_TYPE("m68020", m68020_cpu_initfn), >>>> - DEFINE_M68K_CPU_TYPE("m68030", m68030_cpu_initfn), >>>> - DEFINE_M68K_CPU_TYPE("m68040", m68040_cpu_initfn), >>>> - DEFINE_M68K_CPU_TYPE("m68060", m68060_cpu_initfn), >>>> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68000", m68000_cpu_initfn, >>>> + m68k_cpu_class_init_m68k_core), >>>> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68020", m68020_cpu_initfn, >>>> + m68k_cpu_class_init_m68k_core), >>>> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68030", m68030_cpu_initfn, >>>> + m68k_cpu_class_init_m68k_core), >>>> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68040", m68040_cpu_initfn, >>>> + m68k_cpu_class_init_m68k_core), >>>> + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68060", m68060_cpu_initfn, >>>> + m68k_cpu_class_init_m68k_core), >>>> DEFINE_M68K_CPU_TYPE("m5206", m5206_cpu_initfn), >>>> DEFINE_M68K_CPU_TYPE("m5208", m5208_cpu_initfn), >>>> DEFINE_M68K_CPU_TYPE("cfv4e", cfv4e_cpu_initfn), >> >> But what about the "any" which is out of context here? >> >> DEFINE_M68K_CPU_TYPE("any", any_cpu_initfn), >> >> Should it be TYPE_M68K or TYPE_CF in which case which xml will it take? >> I guess >> we can take TYPE_CF so it doesn't change from what is done today. >> > > Yes, "any" has been introduced with coldfire CPUs and defines CF_FPU, so > it uses 64bit float registers. > > Thanks, > Laurent > Ok done, will send a v2 with an other fix I've for mc68881.
diff --git a/configure b/configure index 23b5e93..2b07b85 100755 --- a/configure +++ b/configure @@ -7825,7 +7825,7 @@ case "$target_name" in ;; m68k) bflt="yes" - gdb_xml_files="cf-core.xml cf-fp.xml m68k-fp.xml" + gdb_xml_files="cf-core.xml cf-fp.xml m68k-core.xml m68k-fp.xml" TARGET_SYSTBL_ABI=common ;; microblaze|microblazeel) diff --git a/gdb-xml/m68k-core.xml b/gdb-xml/m68k-core.xml new file mode 100644 index 0000000..5b092d2 --- /dev/null +++ b/gdb-xml/m68k-core.xml @@ -0,0 +1,29 @@ +<?xml version="1.0"?> +<!-- Copyright (C) 2008 Free Software Foundation, Inc. + + Copying and distribution of this file, with or without modification, + are permitted in any medium without royalty provided the copyright + notice and this notice are preserved. --> +<!DOCTYPE feature SYSTEM "gdb-target.dtd"> +<feature name="org.gnu.gdb.m68k.core"> + <reg name="d0" bitsize="32"/> + <reg name="d1" bitsize="32"/> + <reg name="d2" bitsize="32"/> + <reg name="d3" bitsize="32"/> + <reg name="d4" bitsize="32"/> + <reg name="d5" bitsize="32"/> + <reg name="d6" bitsize="32"/> + <reg name="d7" bitsize="32"/> + <reg name="a0" bitsize="32" type="data_ptr"/> + <reg name="a1" bitsize="32" type="data_ptr"/> + <reg name="a2" bitsize="32" type="data_ptr"/> + <reg name="a3" bitsize="32" type="data_ptr"/> + <reg name="a4" bitsize="32" type="data_ptr"/> + <reg name="a5" bitsize="32" type="data_ptr"/> + <reg name="fp" bitsize="32" type="data_ptr"/> + <reg name="sp" bitsize="32" type="data_ptr"/> + + <reg name="ps" bitsize="32"/> + <reg name="pc" bitsize="32" type="code_ptr"/> + +</feature> diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c index 9445fcd..976e624 100644 --- a/target/m68k/cpu.c +++ b/target/m68k/cpu.c @@ -297,6 +297,21 @@ static void m68k_cpu_class_init(ObjectClass *c, void *data) dc->vmsd = &vmstate_m68k_cpu; } +static void m68k_cpu_class_init_m68k_core(ObjectClass *c, void *data) +{ + CPUClass *cc = CPU_CLASS(c); + + cc->gdb_core_xml_file = "m68k-core.xml"; +} + +#define DEFINE_M68K_CPU_TYPE_WITH_CLASS(cpu_model, initfn, classinit) \ + { \ + .name = M68K_CPU_TYPE_NAME(cpu_model), \ + .instance_init = initfn, \ + .parent = TYPE_M68K_CPU, \ + .class_init = classinit, \ + } + #define DEFINE_M68K_CPU_TYPE(cpu_model, initfn) \ { \ .name = M68K_CPU_TYPE_NAME(cpu_model), \ @@ -314,11 +329,16 @@ static const TypeInfo m68k_cpus_type_infos[] = { .class_size = sizeof(M68kCPUClass), .class_init = m68k_cpu_class_init, }, - DEFINE_M68K_CPU_TYPE("m68000", m68000_cpu_initfn), - DEFINE_M68K_CPU_TYPE("m68020", m68020_cpu_initfn), - DEFINE_M68K_CPU_TYPE("m68030", m68030_cpu_initfn), - DEFINE_M68K_CPU_TYPE("m68040", m68040_cpu_initfn), - DEFINE_M68K_CPU_TYPE("m68060", m68060_cpu_initfn), + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68000", m68000_cpu_initfn, + m68k_cpu_class_init_m68k_core), + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68020", m68020_cpu_initfn, + m68k_cpu_class_init_m68k_core), + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68030", m68030_cpu_initfn, + m68k_cpu_class_init_m68k_core), + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68040", m68040_cpu_initfn, + m68k_cpu_class_init_m68k_core), + DEFINE_M68K_CPU_TYPE_WITH_CLASS("m68060", m68060_cpu_initfn, + m68k_cpu_class_init_m68k_core), DEFINE_M68K_CPU_TYPE("m5206", m5206_cpu_initfn), DEFINE_M68K_CPU_TYPE("m5208", m5208_cpu_initfn), DEFINE_M68K_CPU_TYPE("cfv4e", cfv4e_cpu_initfn),