[RFC] Fix for Go32-v2 native woes

[RFC] Fix for Go32-v2 native woes

[Pierre Muller]

  In an email to gdb list, 
I complained about go32 native GDB giving internal errors...

  The problem is that some code in i386-tdep.c is not compatible
with a target that supports no SSE registers.

  I finally managed to find a fix, but it is not straightforward:
  I had to add a new xml file in features/i386 directory
specific for go32v2 target, that does not read i386-sse.xml.
  I had to adapt the code in i386-tdep.c to support
missing feature_vector and to set tdesc to
tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
osabi was detected.

  This allows me to use CVS GDB on DJGPP again.

  I checked with a testsuite run on gcc-farm that nothing changed
for at least that other target (amd64-linux).

  Similar fixes might be required for other 'old'
i386 targets that do not support SSE registers.

  Comments welcome as usual!

Pierre Muller
Pascal language support maintainer for GDB



2010-04-06  Pierre Muller  <muller@ics.u-strasbg.fr>

	* i386-tdep.c: Add include features/i386/i386-go32v2.c.
	(i386_go32_init_abi): Set TDESC field to TDESC_I386_GO32V2.
	(i386_validate_tdesc_p): Do not require FEATURE_VECTOR.
	Adapt code accordingly.
	(i386_gdbarch_init): Set TDESC to TDESC_I386_GO32V2 if
	os abi is GDB_OSABI_GO32V2.
	(_initialize_i386_tdep): Call initialize_tdes_i386_go32v2 function.

	* features/Makefile (WHICH): Add new i386/i386-go32v2 entry.
	* features/i386/i386-go32v2.xml: New file. Without SSE regsiters.
	* features/i386/i386-go32v2.c: New generated file.
	* regformats/i386/i386-go32v2.dat: New generated file.

Index: src/gdb/i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.308
diff -u -p -r1.308 i386-tdep.c
--- src/gdb/i386-tdep.c	2 Apr 2010 05:09:29 -0000	1.308
+++ src/gdb/i386-tdep.c	6 Apr 2010 13:46:02 -0000
@@ -56,6 +56,7 @@
 #include <stdint.h>
 
 #include "features/i386/i386.c"
+#include "features/i386/i386-go32v2.c"
 
 /* Register names.  */
 
@@ -2761,6 +2762,9 @@ i386_go32_init_abi (struct gdbarch_info 
   tdep->num_xmm_regs = 0;
   set_gdbarch_num_regs (gdbarch, I386_NUM_GREGS + I387_NUM_REGS);
 
+  if (! tdesc_has_registers (info.target_desc))
+    tdep->tdesc = tdesc_i386_go32v2;
+
   /* Native compiler is GCC, which uses the SVR4 register numbering
      even in COFF and STABS.  See the comment in i386_gdbarch_init,
      before the calls to set_gdbarch_stab_reg_to_regnum and
@@ -6461,7 +6465,7 @@ i386_validate_tdesc_p (struct gdbarch_td
   /* Get SSE registers.  */
   feature_vector = tdesc_find_feature (tdesc, "org.gnu.gdb.i386.sse");
 
-  if (feature_core == NULL || feature_vector == NULL)
+  if (feature_core == NULL)
     return 0;
 
   valid_p = 1;
@@ -6472,10 +6476,14 @@ i386_validate_tdesc_p (struct gdbarch_td
 					tdep->register_names[i]);
 
   /* Need to include %mxcsr, so add one.  */
-  num_regs += tdep->num_xmm_regs + 1;
-  for (; i < num_regs; i++)
-    valid_p &= tdesc_numbered_register (feature_vector, tdesc_data, i,
-					tdep->register_names[i]);
+  if (feature_vector != NULL)
+    {
+      if (tdep->num_xmm_regs)
+	num_regs += tdep->num_xmm_regs + 1;
+      for (; i < num_regs; i++)
+	valid_p &= tdesc_numbered_register (feature_vector, tdesc_data, i,
+					    tdep->register_names[i]);
+    }
 
   return valid_p;
 }
@@ -6661,7 +6669,13 @@ i386_gdbarch_init (struct gdbarch_info i
   /* Get the x86 target description from INFO.  */
   tdesc = info.target_desc;
   if (! tdesc_has_registers (tdesc))
-    tdesc = tdesc_i386;
+    {
+      if (info.osabi == GDB_OSABI_GO32)
+	tdesc = tdesc_i386_go32v2;
+      else
+	tdesc = tdesc_i386;
+    }
+
   tdep->tdesc = tdesc;
 
   tdep->num_core_regs = I386_NUM_GREGS + I387_NUM_REGS;
@@ -6797,6 +6811,9 @@ is \"default\"."),
 
   /* Initialize the standard target descriptions.  */
   initialize_tdesc_i386 ();
+  /* Initialize the go32v2 target descriptions.  */
+  initialize_tdesc_i386_go32v2 ();
+
 
   /* Tell remote stub that we support XML target description.  */
   register_remote_support_xml ("i386");
Index: src/gdb/features/Makefile
===================================================================
RCS file: /cvs/src/src/gdb/features/Makefile,v
retrieving revision 1.17
diff -u -p -r1.17 Makefile
--- src/gdb/features/Makefile	8 Feb 2010 05:08:46 -0000	1.17
+++ src/gdb/features/Makefile	6 Apr 2010 13:46:03 -0000
@@ -31,7 +31,7 @@
 #   make GDB=/path/to/gdb XMLTOC="xml files" cfiles
 
 WHICH = arm-with-iwmmxt arm-with-vfpv2 arm-with-vfpv3 arm-with-neon \
-	i386/i386 i386/i386-linux \
+	i386/i386 i386/i386-go32v2 i386/i386-linux \
 	i386/amd64 i386/amd64-linux \
 	mips-linux mips64-linux \
 	rs6000/powerpc-32l rs6000/powerpc-altivec32l rs6000/powerpc-e500l \
@@ -42,6 +42,7 @@ WHICH = arm-with-iwmmxt arm-with-vfpv2 a
 # Record which registers should be sent to GDB by default after stop.
 arm-expedite = r11,sp,pc
 i386/i386-expedite = ebp,esp,eip
+i386/i386-go32v2-expedite = ebp,esp,eip
 i386/i386-linux-expedite = ebp,esp,eip
 i386/amd64-expedite = rbp,rsp,rip
 i386/amd64-linux-expedite = rbp,rsp,rip
Index: src/gdb/features/i386/i386-go32v2.c
===================================================================
RCS file: features/i386/i386-go32v2.c
diff -N features/i386/i386-go32v2.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ src/gdb/features/i386/i386-go32v2.c	6 Apr 2010 13:46:03 -0000
@@ -0,0 +1,73 @@
+/* THIS FILE IS GENERATED.  Original: i386-go32v2.xml */
+
+#include "defs.h"
+#include "osabi.h"
+#include "target-descriptions.h"
+
+struct target_desc *tdesc_i386_go32v2;
+static void
+initialize_tdesc_i386_go32v2 (void)
+{
+  struct target_desc *result = allocate_target_description ();
+  struct tdesc_feature *feature;
+  struct tdesc_type *field_type, *type;
+
+  set_tdesc_architecture (result, bfd_scan_arch ("i386"));
+
+  set_tdesc_osabi (result, osabi_from_tdesc_string ("DJGPP"));
+
+  feature = tdesc_create_feature (result, "org.gnu.gdb.i386.core");
+  field_type = tdesc_create_flags (feature, "i386_eflags", 4);
+  tdesc_add_flag (field_type, 0, "CF");
+  tdesc_add_flag (field_type, 1, "");
+  tdesc_add_flag (field_type, 2, "PF");
+  tdesc_add_flag (field_type, 4, "AF");
+  tdesc_add_flag (field_type, 6, "ZF");
+  tdesc_add_flag (field_type, 7, "SF");
+  tdesc_add_flag (field_type, 8, "TF");
+  tdesc_add_flag (field_type, 9, "IF");
+  tdesc_add_flag (field_type, 10, "DF");
+  tdesc_add_flag (field_type, 11, "OF");
+  tdesc_add_flag (field_type, 14, "NT");
+  tdesc_add_flag (field_type, 16, "RF");
+  tdesc_add_flag (field_type, 17, "VM");
+  tdesc_add_flag (field_type, 18, "AC");
+  tdesc_add_flag (field_type, 19, "VIF");
+  tdesc_add_flag (field_type, 20, "VIP");
+  tdesc_add_flag (field_type, 21, "ID");
+
+  tdesc_create_reg (feature, "eax", 0, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "ecx", 1, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "edx", 2, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "ebx", 3, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "esp", 4, 1, NULL, 32, "data_ptr");
+  tdesc_create_reg (feature, "ebp", 5, 1, NULL, 32, "data_ptr");
+  tdesc_create_reg (feature, "esi", 6, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "edi", 7, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "eip", 8, 1, NULL, 32, "code_ptr");
+  tdesc_create_reg (feature, "eflags", 9, 1, NULL, 32, "i386_eflags");
+  tdesc_create_reg (feature, "cs", 10, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "ss", 11, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "ds", 12, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "es", 13, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "fs", 14, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "gs", 15, 1, NULL, 32, "int32");
+  tdesc_create_reg (feature, "st0", 16, 1, NULL, 80, "i387_ext");
+  tdesc_create_reg (feature, "st1", 17, 1, NULL, 80, "i387_ext");
+  tdesc_create_reg (feature, "st2", 18, 1, NULL, 80, "i387_ext");
+  tdesc_create_reg (feature, "st3", 19, 1, NULL, 80, "i387_ext");
+  tdesc_create_reg (feature, "st4", 20, 1, NULL, 80, "i387_ext");
+  tdesc_create_reg (feature, "st5", 21, 1, NULL, 80, "i387_ext");
+  tdesc_create_reg (feature, "st6", 22, 1, NULL, 80, "i387_ext");
+  tdesc_create_reg (feature, "st7", 23, 1, NULL, 80, "i387_ext");
+  tdesc_create_reg (feature, "fctrl", 24, 1, "float", 32, "int");
+  tdesc_create_reg (feature, "fstat", 25, 1, "float", 32, "int");
+  tdesc_create_reg (feature, "ftag", 26, 1, "float", 32, "int");
+  tdesc_create_reg (feature, "fiseg", 27, 1, "float", 32, "int");
+  tdesc_create_reg (feature, "fioff", 28, 1, "float", 32, "int");
+  tdesc_create_reg (feature, "foseg", 29, 1, "float", 32, "int");
+  tdesc_create_reg (feature, "fooff", 30, 1, "float", 32, "int");
+  tdesc_create_reg (feature, "fop", 31, 1, "float", 32, "int");
+
+  tdesc_i386_go32v2 = result;
+}
Index: src/gdb/features/i386/i386-go32v2.xml
===================================================================
RCS file: features/i386/i386-go32v2.xml
diff -N features/i386/i386-go32v2.xml
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ src/gdb/features/i386/i386-go32v2.xml	6 Apr 2010 13:46:03 -0000
@@ -0,0 +1,15 @@
+<?xml version="1.0"?>
+<!-- Copyright (C) 2010 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.  -->
+
+<!-- I386 without SSE ifor go32v2 target.  -->
+
+<!DOCTYPE target SYSTEM "gdb-target.dtd">
+<target>
+  <architecture>i386</architecture>
+  <osabi>DJGPP</osabi>
+  <xi:include href="32bit-core.xml"/>
+</target>
Index: src/gdb/regformats/i386/i386-go32v2.dat
===================================================================
RCS file: regformats/i386/i386-go32v2.dat
diff -N regformats/i386/i386-go32v2.dat
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ src/gdb/regformats/i386/i386-go32v2.dat	6 Apr 2010 13:46:03 -0000
@@ -0,0 +1,36 @@
+# DO NOT EDIT: generated from i386/i386-go32v2.xml
+name:i386_go32v2
+xmltarget:i386-go32v2.xml
+expedite:ebp,esp,eip
+32:eax
+32:ecx
+32:edx
+32:ebx
+32:esp
+32:ebp
+32:esi
+32:edi
+32:eip
+32:eflags
+32:cs
+32:ss
+32:ds
+32:es
+32:fs
+32:gs
+80:st0
+80:st1
+80:st2
+80:st3
+80:st4
+80:st5
+80:st6
+80:st7
+32:fctrl
+32:fstat
+32:ftag
+32:fiseg
+32:fioff
+32:foseg
+32:fooff
+32:fop

  

> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
> part de Pierre Muller
> Envoyé : Tuesday, April 06, 2010 1:29 AM
> À : gdb@sourceware.org
> Objet : Go32-v2 native woes
> 
>   There are again internal-error problems
> with go32v2 native about registers that are
> not correct.
> 
>   Current CVS gives this:
> 
> Breakpoint 2 at 0xc485: file ../../src/gdb/cli/cli-cmds.c, line 223.
> (top-gdb) set prompt top>
> #Note top> is an older gdb that works fine.
> top> r ./gdb
> Starting program: e:/cygwin/usr/local/src/gdbcvs/djcvsbuild/gdb/gdb.exe
> ./gdb
> GNU gdb (GDB) 7.1.50.20100405-cvs
> Copyright (C) 2010 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=i586-pc-msdosdjgpp --target=djgpp".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> 
> Breakpoint 1, internal_error (
>     file=0xe6d70 "../../src/gdb/target-descriptions.c", line=1140,
>     string=0xe6d55 "%s: Assertion `%s' failed.") at
> ../../src/gdb/utils.c:1050
> 1050      va_start (ap, string);
> top> bt
> #0  internal_error (file=0xe6d70 "../../src/gdb/target-descriptions.c",
>     line=1140, string=0xe6d55 "%s: Assertion `%s' failed.")
>     at ../../src/gdb/utils.c:1050
> #1  0x000e8cf2 in tdesc_use_registers (gdbarch=0x46eda0,
> target_desc=0x3ed480,
>     early_data=0x46fd90) at ../../src/gdb/target-descriptions.c:1140
> #2  0x0013a17c in i386_gdbarch_init (info=..., arches=0x0)
>     at ../../src/gdb/i386-tdep.c:6699
> #3  0x0004dbd6 in gdbarch_find_by_info (info=...)
>     at ../../src/gdb/gdbarch.c:3979
> #4  0x00088785 in set_gdbarch_from_file (abfd=0x42c0a0)
>     at ../../src/gdb/arch-utils.c:552
> #5  0x00017c8b in exec_file_attach (filename=0x3eaeb8 "./gdb",
> from_tty=1)
>     at ../../src/gdb/exec.c:296
> #6  0x000256dd in catch_command_errors (command=0x179e7
> <exec_file_attach>,
>     arg=0x3eaeb8 "./gdb", from_tty=1, mask=6) at
> ../../src/gdb/exceptions.c:525
> #7  0x00002a2a in captured_main (data=0x3ea208) at
> ../../src/gdb/main.c:808
> #8  0x00025649 in catch_errors (func=0x1dfa <captured_main>,
>     func_args=0x3ea208, errstring=0x1b94 "", mask=6)
>     at ../../src/gdb/exceptions.c:510
> #9  0x00002d72 in gdb_main (args=0x3ea208) at ../../src/gdb/main.c:916
> #10 0x0000180d in main (argc=2, argv=0x3eaed8) at
> ../../src/gdb/gdb.c:33
> top> f 1
> #1  0x000e8cf2 in tdesc_use_registers (gdbarch=0x46eda0,
> target_desc=0x3ed480,
>     early_data=0x46fd90) at ../../src/gdb/target-descriptions.c:1140
> 1140      gdb_assert (VEC_length (tdesc_arch_reg, data->arch_regs) <=
> num_regs);
> 
> top> p num_regs
> $1 = 32
> top> p *data.arch_regs
> $2 = {num = 33, alloc = 36, vec = {{reg = 0x3ed6d8, type = 0x0}}}
> top>
> 
>   The additional reg in arch_regs seems to come from
> i386_validate_tdesc_p function:
>  /* Need to include %mxcsr, so add one.  */
>    num_regs += tdep->num_xmm_regs + 1;
> 
> Adding this condition
> if (tdep->num_xmm_regs)
> removes the problem above,
> but I get another error later:
> Breakpoint 1 at 0x479d: file ../../src/gdb/utils.c, line 1050.
> Breakpoint 2 at 0xc485: file ../../src/gdb/cli/cli-cmds.c, line 223.
> (top-gdb) start
> Temporary breakpoint 3 at 0x17d4: file ../../src/gdb/gdb.c, line 28.
> Starting program: e:/cygwin/usr/local/src/gdbcvs/djcvsbuild/gdb/gdb.exe
> 
> Temporary breakpoint 3, main (argc=1, argv=0x3eae78) at
> ../../src/gdb/gdb.c:28
> 28        memset (&args, 0, sizeof args);
> (top-gdb) inf reg
> eax            0x10     16
> ecx            0x0      0
> edx            0x100    256
> ebx            0x3f6    1014
> esp            0x3ea1f0 0x3ea1f0
> ebp            0x3ea220 0x3ea220
> esi            0x54     84
> edi            0x36a258 3580504
> eip            0x17d4   0x17d4 <main+28>
> eflags         0x3206   [ PF IF #12 #13 ]
> cs             0x28f    655
> ss             0x297    663
> ds             0x297    663
> es             0x297    663
> fs             0x2a7    679
> gs             0x2a7    679
> 
> Breakpoint 1, internal_error (file=0x1286ab "../../src/gdb/go32-nat.c",
>     line=546, string=0x128680 "Invalid register no. %d in
> fetch_register.")
>     at ../../src/gdb/utils.c:1050
> 1050      va_start (ap, string);
> 
>   GDB is trying to display register 32 which is normally "xmm0"
> and thus should not be displayed for go32v2.
> 
>   I was not able o fix that second problem :(
> 
> Pierre Muller
> Pascal language support maintainer for GDB
> and old-DOS lover ...

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> Date: Tue, 6 Apr 2010 16:15:05 +0200
> 
>   I finally managed to find a fix, but it is not straightforward:
>   I had to add a new xml file in features/i386 directory
> specific for go32v2 target, that does not read i386-sse.xml.
>   I had to adapt the code in i386-tdep.c to support
> missing feature_vector and to set tdesc to
> tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
> osabi was detected.
> 
>   This allows me to use CVS GDB on DJGPP again.
> 
>   I checked with a testsuite run on gcc-farm that nothing changed
> for at least that other target (amd64-linux).
> 
>   Similar fixes might be required for other 'old'
> i386 targets that do not support SSE registers.
> 
>   Comments welcome as usual!

Thanks.  But I really hope that a much more elegant solution could be
found.  A general layer of code such as i386-tdep.c should not include
any code that is specific to certain targets.

Why do we always read i386-sse.xml or assume that SSE is supported?
We should not assume any CPU features by default if there are CPUs out
there which we support that don't have them.

Re: [RFC] Fix for Go32-v2 native woes

[Mark Kettenis]

> Date: Tue, 06 Apr 2010 20:45:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > Date: Tue, 6 Apr 2010 16:15:05 +0200
> > 
> >   I finally managed to find a fix, but it is not straightforward:
> >   I had to add a new xml file in features/i386 directory
> > specific for go32v2 target, that does not read i386-sse.xml.
> >   I had to adapt the code in i386-tdep.c to support
> > missing feature_vector and to set tdesc to
> > tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
> > osabi was detected.
> > 
> >   This allows me to use CVS GDB on DJGPP again.
> > 
> >   I checked with a testsuite run on gcc-farm that nothing changed
> > for at least that other target (amd64-linux).
> > 
> >   Similar fixes might be required for other 'old'
> > i386 targets that do not support SSE registers.
> > 
> >   Comments welcome as usual!
> 
> Thanks.  But I really hope that a much more elegant solution could be
> found.  A general layer of code such as i386-tdep.c should not include
> any code that is specific to certain targets.
> 
> Why do we always read i386-sse.xml or assume that SSE is supported?
> We should not assume any CPU features by default if there are CPUs out
> there which we support that don't have them.

Because that basically was the situation before.  When SSE support was
addid we didn't really have a way to detect whether a target supported
SSE or not.

Does Go32 really have no support for the SSE registers?

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> Date: Tue, 6 Apr 2010 20:41:01 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: pierre.muller@ics-cnrs.unistra.fr, gdb-patches@sourceware.org
> 
> > Why do we always read i386-sse.xml or assume that SSE is supported?
> > We should not assume any CPU features by default if there are CPUs out
> > there which we support that don't have them.
> 
> Because that basically was the situation before.

I'm not sure I follow.  GDB 7 builds and works in the DJGPP port
without any trouble, even though SSE support was there before, wasn't
it?

> When SSE support was addid we didn't really have a way to detect
> whether a target supported SSE or not.

Well, then it should be part of the target configuration.

> Does Go32 really have no support for the SSE registers?

Yes, really.  The debug interface provided by DPMI (the interface for
running protected-mode programs on DOS, which is a real-mode OS) does
not support SSE.  And since no one is developing the DPMI spec or DPMI
ser5vices these days, SSE will never be supported by DJGPP.  In fact,
none of the special registers of the modern x86 CPUs (XMM etc.) will
ever be supported.

Therefore, the fact that SSE is not supported by DJGPP can be
established at compile time.

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> Date: Tue, 06 Apr 2010 20:45:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gdb-patches@sourceware.org
> 
> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
> > Date: Tue, 6 Apr 2010 16:15:05 +0200
> > 
> >   I finally managed to find a fix, but it is not straightforward:
> >   I had to add a new xml file in features/i386 directory
> > specific for go32v2 target, that does not read i386-sse.xml.
> >   I had to adapt the code in i386-tdep.c to support
> > missing feature_vector and to set tdesc to
> > tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
> > osabi was detected.
> > 
> >   This allows me to use CVS GDB on DJGPP again.
> > 
> >   I checked with a testsuite run on gcc-farm that nothing changed
> > for at least that other target (amd64-linux).
> > 
> >   Similar fixes might be required for other 'old'
> > i386 targets that do not support SSE registers.
> > 
> >   Comments welcome as usual!
> 
> Thanks.  But I really hope that a much more elegant solution could be
> found.  A general layer of code such as i386-tdep.c should not include
> any code that is specific to certain targets.

Btw, I think this solution cannot be acceptable for one more reason:
GDB should work even without libexpat linked in, and then XML files
cannot be read.

Can you see what happens with this problem in a GDB build without
libexpat?  (Sorry, I won't be able to do that myself in the near
future.)

TIA

Re: [RFC] Fix for Go32-v2 native woes

[H.J. Lu]

On Tue, Apr 6, 2010 at 8:19 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Tue, 06 Apr 2010 20:45:25 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: gdb-patches@sourceware.org
>>
>> > From: "Pierre Muller" <pierre.muller@ics-cnrs.unistra.fr>
>> > Date: Tue, 6 Apr 2010 16:15:05 +0200
>> >
>> >   I finally managed to find a fix, but it is not straightforward:
>> >   I had to add a new xml file in features/i386 directory
>> > specific for go32v2 target, that does not read i386-sse.xml.
>> >   I had to adapt the code in i386-tdep.c to support
>> > missing feature_vector and to set tdesc to
>> > tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
>> > osabi was detected.
>> >
>> >   This allows me to use CVS GDB on DJGPP again.
>> >
>> >   I checked with a testsuite run on gcc-farm that nothing changed
>> > for at least that other target (amd64-linux).
>> >
>> >   Similar fixes might be required for other 'old'
>> > i386 targets that do not support SSE registers.
>> >
>> >   Comments welcome as usual!
>>
>> Thanks.  But I really hope that a much more elegant solution could be
>> found.  A general layer of code such as i386-tdep.c should not include
>> any code that is specific to certain targets.
>
> Btw, I think this solution cannot be acceptable for one more reason:
> GDB should work even without libexpat linked in, and then XML files
> cannot be read.
>
> Can you see what happens with this problem in a GDB build without
> libexpat?  (Sorry, I won't be able to do that myself in the near
> future.)
>

I have a followup patch on top of AVX gdb to support i386 without
SSE. I will submit it after AVX patches are checked in.


-- 
H.J.

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> Date: Tue, 6 Apr 2010 23:19:36 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Cc: pierre.muller@ics-cnrs.unistra.fr, gdb-patches@sourceware.org
> 
> I have a followup patch on top of AVX gdb to support i386 without
> SSE. I will submit it after AVX patches are checked in.

Thank you.

Btw, what happens with the register-related features you added if
libexpat is not linked in?  Do these features silently disappear
(good) or break the build (bad) or cause fatal internal errors at run
time (worse)?

TIA

Re: [RFC] Fix for Go32-v2 native woes

[Daniel Jacobowitz]

On Wed, Apr 07, 2010 at 02:44:10AM -0400, Eli Zaretskii wrote:
> > Date: Tue, 6 Apr 2010 23:19:36 -0700
> > From: "H.J. Lu" <hjl.tools@gmail.com>
> > Cc: pierre.muller@ics-cnrs.unistra.fr, gdb-patches@sourceware.org
> > 
> > I have a followup patch on top of AVX gdb to support i386 without
> > SSE. I will submit it after AVX patches are checked in.
> 
> Thank you.
> 
> Btw, what happens with the register-related features you added if
> libexpat is not linked in?  Do these features silently disappear
> (good) or break the build (bad) or cause fatal internal errors at run
> time (worse)?

They continue to work (even better).  We parse the XML files used for
native debugging into C files, and the generated C files are stored in
the source tree.  This was a design requirement before we could
require XML descriptions for any native platform.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> Date: Wed, 7 Apr 2010 10:41:37 -0400
> From: Daniel Jacobowitz <dan@codesourcery.com>
> Cc: "H.J. Lu" <hjl.tools@gmail.com>, pierre.muller@ics-cnrs.unistra.fr,
> 	gdb-patches@sourceware.org
> 
> > Btw, what happens with the register-related features you added if
> > libexpat is not linked in?  Do these features silently disappear
> > (good) or break the build (bad) or cause fatal internal errors at run
> > time (worse)?
> 
> They continue to work (even better).  We parse the XML files used for
> native debugging into C files, and the generated C files are stored in
> the source tree.  This was a design requirement before we could
> require XML descriptions for any native platform.

Thanks.  So this means we currently assume SSE support regardless of
the XML files, is that right?

Re: [RFC] Fix for Go32-v2 native woes

[H.J. Lu]

On Wed, Apr 7, 2010 at 10:33 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 7 Apr 2010 10:41:37 -0400
>> From: Daniel Jacobowitz <dan@codesourcery.com>
>> Cc: "H.J. Lu" <hjl.tools@gmail.com>, pierre.muller@ics-cnrs.unistra.fr,
>>       gdb-patches@sourceware.org
>>
>> > Btw, what happens with the register-related features you added if
>> > libexpat is not linked in?  Do these features silently disappear
>> > (good) or break the build (bad) or cause fatal internal errors at run
>> > time (worse)?
>>
>> They continue to work (even better).  We parse the XML files used for
>> native debugging into C files, and the generated C files are stored in
>> the source tree.  This was a design requirement before we could
>> require XML descriptions for any native platform.
>
> Thanks.  So this means we currently assume SSE support regardless of
> the XML files, is that right?

It should be fixed on hjl/mmx branch at

http://git.kernel.org/?p=devel/gdb/hjl/avx.git;a=summary



-- 
H.J.

Re: [RFC] Fix for Go32-v2 native woes

[H.J. Lu]

On Tue, Apr 6, 2010 at 7:15 AM, Pierre Muller
<pierre.muller@ics-cnrs.unistra.fr> wrote:
>  In an email to gdb list,
> I complained about go32 native GDB giving internal errors...
>
>  The problem is that some code in i386-tdep.c is not compatible
> with a target that supports no SSE registers.
>
>  I finally managed to find a fix, but it is not straightforward:
>  I had to add a new xml file in features/i386 directory
> specific for go32v2 target, that does not read i386-sse.xml.
>  I had to adapt the code in i386-tdep.c to support
> missing feature_vector and to set tdesc to
> tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
> osabi was detected.
>
>  This allows me to use CVS GDB on DJGPP again.
>
>  I checked with a testsuite run on gcc-farm that nothing changed
> for at least that other target (amd64-linux).
>
>  Similar fixes might be required for other 'old'
> i386 targets that do not support SSE registers.
>
>  Comments welcome as usual!
>
> Pierre Muller
> Pascal language support maintainer for GDB
>
>
>
> 2010-04-06  Pierre Muller  <muller@ics.u-strasbg.fr>
>
>        * i386-tdep.c: Add include features/i386/i386-go32v2.c.
>        (i386_go32_init_abi): Set TDESC field to TDESC_I386_GO32V2.
>        (i386_validate_tdesc_p): Do not require FEATURE_VECTOR.
>        Adapt code accordingly.
>        (i386_gdbarch_init): Set TDESC to TDESC_I386_GO32V2 if
>        os abi is GDB_OSABI_GO32V2.
>        (_initialize_i386_tdep): Call initialize_tdes_i386_go32v2 function.
>
>        * features/Makefile (WHICH): Add new i386/i386-go32v2 entry.
>        * features/i386/i386-go32v2.xml: New file. Without SSE regsiters.
>        * features/i386/i386-go32v2.c: New generated file.
>        * regformats/i386/i386-go32v2.dat: New generated file.
>

This patch is incorrect. Linux runs on 32bit x86 processors without SSE.
I have a patch to support it.

-- 
H.J.

Re: [RFC] Fix for Go32-v2 native woes

[H.J. Lu]

On Tue, Apr 6, 2010 at 11:32 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Tue, Apr 6, 2010 at 7:15 AM, Pierre Muller
> <pierre.muller@ics-cnrs.unistra.fr> wrote:
>>  In an email to gdb list,
>> I complained about go32 native GDB giving internal errors...
>>
>>  The problem is that some code in i386-tdep.c is not compatible
>> with a target that supports no SSE registers.
>>
>>  I finally managed to find a fix, but it is not straightforward:
>>  I had to add a new xml file in features/i386 directory
>> specific for go32v2 target, that does not read i386-sse.xml.
>>  I had to adapt the code in i386-tdep.c to support
>> missing feature_vector and to set tdesc to
>> tdesc_i386_go32v2 instead of tdesc_i386 when go32v2
>> osabi was detected.
>>
>>  This allows me to use CVS GDB on DJGPP again.
>>
>>  I checked with a testsuite run on gcc-farm that nothing changed
>> for at least that other target (amd64-linux).
>>
>>  Similar fixes might be required for other 'old'
>> i386 targets that do not support SSE registers.
>>
>>  Comments welcome as usual!
>>
>> Pierre Muller
>> Pascal language support maintainer for GDB
>>
>>
>>
>> 2010-04-06  Pierre Muller  <muller@ics.u-strasbg.fr>
>>
>>        * i386-tdep.c: Add include features/i386/i386-go32v2.c.
>>        (i386_go32_init_abi): Set TDESC field to TDESC_I386_GO32V2.
>>        (i386_validate_tdesc_p): Do not require FEATURE_VECTOR.
>>        Adapt code accordingly.
>>        (i386_gdbarch_init): Set TDESC to TDESC_I386_GO32V2 if
>>        os abi is GDB_OSABI_GO32V2.
>>        (_initialize_i386_tdep): Call initialize_tdes_i386_go32v2 function.
>>
>>        * features/Makefile (WHICH): Add new i386/i386-go32v2 entry.
>>        * features/i386/i386-go32v2.xml: New file. Without SSE regsiters.
>>        * features/i386/i386-go32v2.c: New generated file.
>>        * regformats/i386/i386-go32v2.dat: New generated file.
>>
>
> This patch is incorrect. Linux runs on 32bit x86 processors without SSE.
> I have a patch to support it.
>

Please try hjl/mmx branch at

http://git.kernel.org/?p=devel/gdb/hjl/avx.git;a=summary

You need to return i386_mmx as target description if your
target doesn't support SSE.

Known issue: "gcore" doesn't work for i386 MMX targets and
I have a patch.


-- 
H.J.

Re: [RFC] Fix for Go32-v2 native woes

[Eli Zaretskii]

> Date: Wed, 7 Apr 2010 10:35:48 -0700
> From: "H.J. Lu" <hjl.tools@gmail.com>
> Cc: gdb-patches@sourceware.org
> 
> Please try hjl/mmx branch at
> 
> http://git.kernel.org/?p=devel/gdb/hjl/avx.git;a=summary
> 
> You need to return i386_mmx as target description if your
> target doesn't support SSE.

Thanks.

> Known issue: "gcore" doesn't work for i386 MMX targets and
> I have a patch.

That's not an issue with the DJGPP build: it doesn't support core
files anyway.

Re: [RFC] Fix for Go32-v2 native woes

[H.J. Lu]

On Wed, Apr 7, 2010 at 10:53 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 7 Apr 2010 10:35:48 -0700
>> From: "H.J. Lu" <hjl.tools@gmail.com>
>> Cc: gdb-patches@sourceware.org
>>
>> Please try hjl/mmx branch at
>>
>> http://git.kernel.org/?p=devel/gdb/hjl/avx.git;a=summary
>>
>> You need to return i386_mmx as target description if your
>> target doesn't support SSE.
>
> Thanks.
>

I checked a  patch to fix DJGPP:

http://git.kernel.org/?p=devel/gdb/hjl/avx.git;a=commit;h=20e15030717d1a2dbe5aeb0e8ef273bb12beb28f

But I can't test it myself. Pierre, could you please give hjl/mmx branch
a try?

Thanks.


-- 
H.J.