Re: [PATCH] Deal with GCC bug on 64-bit SPARC

Re: [PATCH] Deal with GCC bug on 64-bit SPARC

[Michael Elizabeth Chastain]

> GCC generates code that doesn't conform to the ABI.

I hate it when that happens.

Can you enhance your comment to say which version of gcc?
gcc 3.4 has a different default ABI than gcc 3.3.
 
Michael C

Re: [PATCH] Deal with GCC bug on 64-bit SPARC

[Mark Kettenis]

   Date: Sat,  3 Jan 2004 17:47:17 -0500 (EST)
   From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)

   > GCC generates code that doesn't conform to the ABI.

   I hate it when that happens.

Well, it's a corner case.  Only if you define a structure that
consists of a single `float' member and pass it by value and you're
mixing code from two compiler you'll get hit.  Any sensible person
would not use a struct here and simply pass the float around.

   Can you enhance your comment to say which version of gcc?
   gcc 3.4 has a different default ABI than gcc 3.3.

I've seen this with GCC 3.3.2, GCC 3.3.3-ish and GCC 3.4.  But I bet
older versions have this problem too.  Anyway, I'm talking about plain
old C here, not C++.  Oh, and it's SPARC only of course.

Anyway, it's nothing we should be too worried about.  GDB handles it
without problems now :-).

Mark

Re: [PATCH] Deal with GCC bug on 64-bit SPARC

[Mark Kettenis]

   Date: Sat,  3 Jan 2004 18:06:41 -0500 (EST)
   From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)

   > I've seen this with GCC 3.3.2, GCC 3.3.3-ish and GCC 3.4.  But I bet
   > older versions have this problem too.

   That's what I'd like to see in the source code.  So that four years
   from now, when we're worrying about gcc 4.1, we know that it's an
   old comment and not a current comment.

Good point.  I mentioned GCC 3.3.2 since that's the latest official
release.  I've verified that it shows the problem.  Better not mention
GCC 3.3.3 or GCC 3.4, since the bugs still might be fixed before those
are released ;-).

Mark

Re: [PATCH] Deal with GCC bug on 64-bit SPARC

[Michael Elizabeth Chastain]

> I've seen this with GCC 3.3.2, GCC 3.3.3-ish and GCC 3.4.  But I bet
> older versions have this problem too.

That's what I'd like to see in the source code.  So that four years
from now, when we're worrying about gcc 4.1, we know that it's an
old comment and not a current comment.

Michael C

[PATCH] Deal with GCC bug on 64-bit SPARC

[Mark Kettenis]

GCC generates code that doesn't conform to the ABI.  Fortunately, we
can deal with that lossage in GDB.  Patch attached and committed.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>
 
	* sparc64-tdep.c (sparc64_store_floating_fields): If TYPE is a
	structure that has a single `float' member, store it in %f1 in
	addition to %f0.

 
Index: sparc64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc64-tdep.c,v
retrieving revision 1.5
diff -u -p -r1.5 sparc64-tdep.c
--- sparc64-tdep.c 3 Jan 2004 15:00:10 -0000 1.5
+++ sparc64-tdep.c 3 Jan 2004 20:44:44 -0000
@@ -668,6 +668,21 @@ sparc64_store_floating_fields (struct re
 	  sparc64_store_floating_fields (regcache, subtype, valbuf,
 					 element, subpos);
 	}
+
+      /* GCC has an interesting bug.  If TYPE is a structure that has
+         a single `float' member, GCC doesn't treat it as a structure
+         at all, but rather as an ordinary `float' argument.  This
+         argument will be stored in %f1, as required by the psABI.
+         However, as a member of a structure the psABI requires it to
+         be stored in.  To appease GCC, if a structure has only a
+         single `float' member, we store its value in %f1 too.  */
+      if (TYPE_NFIELDS (type) == 1)
+	{
+	  struct type *subtype = check_typedef (TYPE_FIELD_TYPE (type, 0));
+
+	  if (sparc64_floating_p (subtype) && TYPE_LENGTH (subtype) == 4)
+	    regcache_cooked_write (regcache, SPARC_F1_REGNUM, valbuf);
+	}
     }
 }