[RFA] Sparc/Linux fixes part 1

[RFA] Sparc/Linux fixes part 1

[David S. Miller]

Ok, let's try to split up these changes even more in hopes
someone might be able to start to look at least at the obvious
bits.

32-bit Sparc under Linux does not have a 16-byte long double,
this causes testsuite failures.  Fix this by providing a
SPARC_TARGET_LONG_DOUBLE_BYTES the OS specific target headers
can override.

Tested on sparc-linux-gnu, no regressions, a few new successes
:-)

2002-04-19  David S. Miller  <davem@redhat.com>

	* config/sparc/tm-sparc.h (SPARC_TARGET_LONG_DOUBLE_BYTES): New.
	(TARGET_LONG_DOUBLE_BIT): Define in non-multi-arch case.
	* config/sparc/tm-linux.h (SPARC_TARGET_LONG_DOUBLE_BYTES):
	Override.
	* config/sparc/tm-sp64linux.h (SPARC_TARGET_LONG_DOUBLE_BYTES):
	Override.
	* sparc-tdep.c (sparc_gdbarch_init): Use
	SPARC_TARGET_LONG_DOUBLE_BYTES in set_gdbarch_long_double_bit
	call.  Do it after GDB_TARGET_IS_SPARC64 has stabilized.

--- ./config/sparc/tm-sparc.h.~1~	Mon Jan 28 20:42:44 2002
+++ ./config/sparc/tm-sparc.h	Fri Apr 19 13:55:48 2002
@@ -137,6 +137,8 @@ extern int sparc_intreg_size (void);
 #endif
 #endif
 
+#define SPARC_TARGET_LONG_DOUBLE_BYTES	16
+
 #if !defined (GDB_MULTI_ARCH) || (GDB_MULTI_ARCH == 0)
 /*
  * The following defines must go away for MULTI_ARCH
@@ -175,6 +177,11 @@ extern int sparc_intreg_size (void);
    real way to know how big a register is.  */
 
 #define REGISTER_SIZE 4
+
+/* Say how large a 'long double' is.  */
+
+#define TARGET_LONG_DOUBLE_BIT \
+        (SPARC_TARGET_LONG_DOUBLE_BYTES * TARGET_CHAR_BIT)
 
 /* Number of machine registers */
 
--- ./config/sparc/tm-linux.h.~1~	Sun Feb 24 14:56:07 2002
+++ ./config/sparc/tm-linux.h	Fri Apr 19 13:58:11 2002
@@ -25,6 +25,9 @@
 
 #include "sparc/tm-sparc.h"
 
+#undef SPARC_TARGET_LONG_DOUBLE_BYTES
+#define SPARC_TARGET_LONG_DOUBLE_BYTES 8
+
 #define SIGCONTEXT_PC_OFFSET 12
 
 #include "tm-linux.h"
--- ./config/sparc/tm-sp64linux.h.~1~	Sun Feb 24 14:56:07 2002
+++ ./config/sparc/tm-sp64linux.h	Fri Apr 19 13:58:03 2002
@@ -25,6 +25,10 @@ Foundation, Inc., 59 Temple Place - Suit
 
 #include "sparc/tm-sp64.h"
 
+#undef SPARC_TARGET_LONG_DOUBLE_BYTES
+#define SPARC_TARGET_LONG_DOUBLE_BYTES \
+	(GDB_TARGET_IS_SPARC64 ? 16 : 8)
+
 #define SIGCONTEXT_PC_OFFSET 16  /* See asm-sparc64/sigcontext.h */
 
 /* We always want full V9 + Ultra VIS stuff... */
--- ./sparc-tdep.c.~1~	Fri Apr 12 11:18:57 2002
+++ ./sparc-tdep.c	Fri Apr 19 13:57:40 2002
@@ -2970,7 +2970,6 @@ sparc_gdbarch_init (struct gdbarch_info 
   set_gdbarch_init_extra_frame_info (gdbarch, sparc_init_extra_frame_info);
   set_gdbarch_inner_than (gdbarch, core_addr_lessthan);
   set_gdbarch_int_bit (gdbarch, 4 * TARGET_CHAR_BIT);
-  set_gdbarch_long_double_bit (gdbarch, 16 * TARGET_CHAR_BIT);
   set_gdbarch_long_long_bit (gdbarch, 8 * TARGET_CHAR_BIT);
   set_gdbarch_max_register_raw_size (gdbarch, 8);
   set_gdbarch_max_register_virtual_size (gdbarch, 8);
@@ -3114,6 +3113,11 @@ sparc_gdbarch_init (struct gdbarch_info 
       tdep->call_dummy_call_offset = 148 + 4 * 5;
       break;
     }
+
+  /* Set this after GDB_TARGET_IS_SPARC64 has stabilized.  */
+  set_gdbarch_long_double_bit (gdbarch,
+			       SPARC_TARGET_LONG_DOUBLE_BYTES
+			       * TARGET_CHAR_BIT);
 
   /* 
    * Settings that vary per-architecture:

Re: [RFA] Sparc/Linux fixes part 1

[Michael Snyder]

"David S. Miller" wrote:
> 
> Ok, let's try to split up these changes even more in hopes
> someone might be able to start to look at least at the obvious
> bits.
> 
> 32-bit Sparc under Linux does not have a 16-byte long double,
> this causes testsuite failures.  Fix this by providing a
> SPARC_TARGET_LONG_DOUBLE_BYTES the OS specific target headers
> can override.
> 
> Tested on sparc-linux-gnu, no regressions, a few new successes
> :-)

The idea is sound, but the implementation is not very 
multi-arch-ish.  Is there a runtime way to do this, 
rather than by using a macro?  The whole purpose of
multi-arch is that these decisions get made at runtime.

> 
> 2002-04-19  David S. Miller  <davem@redhat.com>
> 
>         * config/sparc/tm-sparc.h (SPARC_TARGET_LONG_DOUBLE_BYTES): New.
>         (TARGET_LONG_DOUBLE_BIT): Define in non-multi-arch case.
>         * config/sparc/tm-linux.h (SPARC_TARGET_LONG_DOUBLE_BYTES):
>         Override.
>         * config/sparc/tm-sp64linux.h (SPARC_TARGET_LONG_DOUBLE_BYTES):
>         Override.
>         * sparc-tdep.c (sparc_gdbarch_init): Use
>         SPARC_TARGET_LONG_DOUBLE_BYTES in set_gdbarch_long_double_bit
>         call.  Do it after GDB_TARGET_IS_SPARC64 has stabilized.
> 
> --- ./config/sparc/tm-sparc.h.~1~       Mon Jan 28 20:42:44 2002
> +++ ./config/sparc/tm-sparc.h   Fri Apr 19 13:55:48 2002
> @@ -137,6 +137,8 @@ extern int sparc_intreg_size (void);
>  #endif
>  #endif
> 
> +#define SPARC_TARGET_LONG_DOUBLE_BYTES 16
> +
>  #if !defined (GDB_MULTI_ARCH) || (GDB_MULTI_ARCH == 0)
>  /*
>   * The following defines must go away for MULTI_ARCH
> @@ -175,6 +177,11 @@ extern int sparc_intreg_size (void);
>     real way to know how big a register is.  */
> 
>  #define REGISTER_SIZE 4
> +
> +/* Say how large a 'long double' is.  */
> +
> +#define TARGET_LONG_DOUBLE_BIT \
> +        (SPARC_TARGET_LONG_DOUBLE_BYTES * TARGET_CHAR_BIT)
> 
>  /* Number of machine registers */
> 
> --- ./config/sparc/tm-linux.h.~1~       Sun Feb 24 14:56:07 2002
> +++ ./config/sparc/tm-linux.h   Fri Apr 19 13:58:11 2002
> @@ -25,6 +25,9 @@
> 
>  #include "sparc/tm-sparc.h"
> 
> +#undef SPARC_TARGET_LONG_DOUBLE_BYTES
> +#define SPARC_TARGET_LONG_DOUBLE_BYTES 8
> +
>  #define SIGCONTEXT_PC_OFFSET 12
> 
>  #include "tm-linux.h"
> --- ./config/sparc/tm-sp64linux.h.~1~   Sun Feb 24 14:56:07 2002
> +++ ./config/sparc/tm-sp64linux.h       Fri Apr 19 13:58:03 2002
> @@ -25,6 +25,10 @@ Foundation, Inc., 59 Temple Place - Suit
> 
>  #include "sparc/tm-sp64.h"
> 
> +#undef SPARC_TARGET_LONG_DOUBLE_BYTES
> +#define SPARC_TARGET_LONG_DOUBLE_BYTES \
> +       (GDB_TARGET_IS_SPARC64 ? 16 : 8)
> +
>  #define SIGCONTEXT_PC_OFFSET 16  /* See asm-sparc64/sigcontext.h */
> 
>  /* We always want full V9 + Ultra VIS stuff... */
> --- ./sparc-tdep.c.~1~  Fri Apr 12 11:18:57 2002
> +++ ./sparc-tdep.c      Fri Apr 19 13:57:40 2002
> @@ -2970,7 +2970,6 @@ sparc_gdbarch_init (struct gdbarch_info
>    set_gdbarch_init_extra_frame_info (gdbarch, sparc_init_extra_frame_info);
>    set_gdbarch_inner_than (gdbarch, core_addr_lessthan);
>    set_gdbarch_int_bit (gdbarch, 4 * TARGET_CHAR_BIT);
> -  set_gdbarch_long_double_bit (gdbarch, 16 * TARGET_CHAR_BIT);
>    set_gdbarch_long_long_bit (gdbarch, 8 * TARGET_CHAR_BIT);
>    set_gdbarch_max_register_raw_size (gdbarch, 8);
>    set_gdbarch_max_register_virtual_size (gdbarch, 8);
> @@ -3114,6 +3113,11 @@ sparc_gdbarch_init (struct gdbarch_info
>        tdep->call_dummy_call_offset = 148 + 4 * 5;
>        break;
>      }
> +
> +  /* Set this after GDB_TARGET_IS_SPARC64 has stabilized.  */
> +  set_gdbarch_long_double_bit (gdbarch,
> +                              SPARC_TARGET_LONG_DOUBLE_BYTES
> +                              * TARGET_CHAR_BIT);
> 
>    /*
>     * Settings that vary per-architecture:

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Michael Snyder <msnyder@redhat.com>
   Date: Fri, 19 Apr 2002 18:25:32 -0700

   The idea is sound, but the implementation is not very 
   multi-arch-ish.  Is there a runtime way to do this, 
   rather than by using a macro?  The whole purpose of
   multi-arch is that these decisions get made at runtime.
   
It is done at runtime, why do you think I check
GDB_TARGET_IS_SPARC64 in the tm-sp64linux.h case?

For tm-linux.h it can only possibly be one value.

Eventually I want to merge tm-sp64linux.h and tm-linux.h
into one configuration, but I want to merge in all of
my previous work first as that provides the infrastructure I need to
do that properly.

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Michael Snyder <msnyder@redhat.com>
   Date: Fri, 19 Apr 2002 18:25:32 -0700

   "David S. Miller" wrote:
   > 32-bit Sparc under Linux does not have a 16-byte long double,
   > this causes testsuite failures.  Fix this by providing a
   > SPARC_TARGET_LONG_DOUBLE_BYTES the OS specific target headers
   > can override.
   
   The idea is sound, but the implementation is not very 
   multi-arch-ish.  Is there a runtime way to do this, 
   rather than by using a macro?  The whole purpose of
   multi-arch is that these decisions get made at runtime.

Some more commentary, just to be absolutely clear...

Note that this is an OS-specific setting, and the current
multi-arch code does not lend itself to anything other
than cpu target gdbarch inits.

If GDB provided a framework whereby I could install an os-specific
gdbarch_init, I'd be more than happy to implement this in the
holy-grail-multi-arch way you want me to.

Look, I'll stick around long after this change is installed so
when the facility is there, I will convert this long double
stuff to use it and the macros will basically disappear from the
sparc headers. :-)

Re: [RFA] Sparc/Linux fixes part 1

[Andrew Cagney]

>  From: Michael Snyder <msnyder@redhat.com>
> Date: Fri, 19 Apr 2002 18:25:32 -0700
> 
>    "David S. Miller" wrote:
>    > 32-bit Sparc under Linux does not have a 16-byte long double,
>    > this causes testsuite failures.  Fix this by providing a
>    > SPARC_TARGET_LONG_DOUBLE_BYTES the OS specific target headers
>    > can override.
>    
>    The idea is sound, but the implementation is not very 
>    multi-arch-ish.  Is there a runtime way to do this, 
>    rather than by using a macro?  The whole purpose of
>    multi-arch is that these decisions get made at runtime.
> 
> Some more commentary, just to be absolutely clear...
> 
> Note that this is an OS-specific setting, and the current
> multi-arch code does not lend itself to anything other
> than cpu target gdbarch inits.

sizeof(long double) is a property of the ABI not the OS.

> If GDB provided a framework whereby I could install an os-specific
> gdbarch_init, I'd be more than happy to implement this in the
> holy-grail-multi-arch way you want me to.
> 
> Look, I'll stick around long after this change is installed so
> when the facility is there, I will convert this long double
> stuff to use it and the macros will basically disappear from the
> sparc headers. :-)

The value of long double can be set at run time by examining information 
provided by the BFD.  ARM does this for the ABI, MIPS this for almost 
everything.

enjoy,
Andrew

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Fri, 19 Apr 2002 22:13:05 -0400

   > Some more commentary, just to be absolutely clear...
   > 
   > Note that this is an OS-specific setting, and the current
   > multi-arch code does not lend itself to anything other
   > than cpu target gdbarch inits.
   
   sizeof(long double) is a property of the ABI not the OS.
   
Under Linux/Sparc we, unfortunately, did not follow the ABI, so
effectively we do have an OS-specific Sparc 32-bit ABI in that
we use 8 byte long doubles.

   The value of long double can be set at run time by examining information 
   provided by the BFD.  ARM does this for the ABI, MIPS this for almost 
   everything.
   
I don't see mips-tdep.c using bfd information in it's one and only
call to set_gdbarch_long_double_bit(), what am I overlooking?

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Fri, 19 Apr 2002 22:13:05 -0400
   
   The value of long double can be set at run time by examining information 
   provided by the BFD.  ARM does this for the ABI, MIPS this for almost 
   everything.

I see what MIPS is doing, it does it for other type.

But this isn't going to help my long double case on
sparc, the BFD information is going to look identical.

It's elf_sparc 32-bit, but under Linux long double's
are 8 bytes, and that's all she wrote. :-)

Re: [RFA] Sparc/Linux fixes part 1

[Andrew Cagney]

>  The value of long double can be set at run time by examining information 
>    provided by the BFD.  ARM does this for the ABI, MIPS this for almost 
>    everything.
>    
> I don't see mips-tdep.c using bfd information in it's one and only
> call to set_gdbarch_long_double_bit(), what am I overlooking?

``almost everything''?

>  From: Andrew Cagney <ac131313@cygnus.com>
> Date: Fri, 19 Apr 2002 22:13:05 -0400
>    
>    The value of long double can be set at run time by examining information 
>    provided by the BFD.  ARM does this for the ABI, MIPS this for almost 
>    everything.
> 
> I see what MIPS is doing, it does it for other type.
> 
> But this isn't going to help my long double case on
> sparc, the BFD information is going to look identical.
> 
> It's elf_sparc 32-bit, but under Linux long double's
> are 8 bytes, and that's all she wrote. :-)

The BFD is the starting point, from there you can root around in all 
sorts of nasty places.  .note sections, symbols, ....

How does this Kernel, for instance, differentate between a GNU/Linux 
sparc binary and a Solaris binary when doing emulation?

Andrew

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Fri, 19 Apr 2002 22:46:23 -0400
   
   How does this Kernel, for instance, differentate between a GNU/Linux 
   sparc binary and a Solaris binary when doing emulation?

I'm going to delete the Solaris binary support any day now as an
aside.

The two binaries look identical, the both look like elf32_sparc.
I don't know how many times I can say this.

"The binaries look identical, but we screwed up on Sparc/Linux
 a long time ago and the long double type is 8 bytes instead of
 the ABI mandated 16 bytes.  We are in no position to change this
 with the amount of existing binaries out there."

There is no distinguising characterstic in the elf header nor anywhere
else.

I can't "look at the bfd and elf bits" to "find out" what the long
double type size is.  The information simply isn't there.

What the heck do you want me to do?  If it's a native 32-bit Sparc
binary running on a Linux/Sparc host, the long double type is 8
bytes.  That is the algorithm, and it is what I have implemented.

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Fri, 19 Apr 2002 22:46:23 -0400

   How does this Kernel, for instance, differentate between a GNU/Linux 
   sparc binary and a Solaris binary when doing emulation?

To make this clear, it doesn't know until the first system call
is made, this is a fact.  The trap used for system calls are
different, but the binary information is identical.

Only the bfd/executable information is available at the time we
make gdbarch decisions.

Can we get over this issue so I can get to the more globally (read as:
changes that get 64-bit Solaris/Sparc actually working) useful bits of
my contributions? :(

Re: [RFA] Sparc/Linux fixes part 1

[Jason R Thorpe]

On Fri, Apr 19, 2002 at 06:47:09PM -0700, David S. Miller wrote:

 > Note that this is an OS-specific setting, and the current
 > multi-arch code does not lend itself to anything other
 > than cpu target gdbarch inits.

Err, the ARM target deals with multiple OS settings in the multi-arch
framework...

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Jason R Thorpe <thorpej@wasabisystems.com>
   Date: Sat, 20 Apr 2002 10:00:52 -0700

   Err, the ARM target deals with multiple OS settings in the multi-arch
   framework...

This won't work at all for my case.  There is no "elfosabi" to use to
distinguish between Solaris ELF 32-bit Sparc (which has 16 byte long
doubles) and Linux ELF 32-bit Sparc (which has 8 byte long doubles).

The OS tag is listed as SYSV in both cases.

Maybe I can say "there is no way to distinguish whether it is a Linux
32-bit Sparc binary or a Solaris 32-bit Sparc one" 50 more times and
people would begin to understand the situation.

Here, let me show everyone exactly what I am saying:

? uname -a
Linux nuts.ninka.net 2.4.19-pre7 #1 SMP Fri Apr 19 20:18:39 PDT 2002 sparc64 unknown
? readelf -h /bin/sh | grep OS
  OS/ABI:                            UNIX - System V
? 

bash-2.03$ uname -a
SunOS caip.rutgers.edu 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-Enterprise-10000
bash-2.03$ readelf -h /bin/sh | grep OS
  OS/ABI:                            UNIX - System V
bash-2.03$ 

See?

Franks a lot,
David S. Miller
davem@redhat.com

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: "David S. Miller" <davem@redhat.com>
   Date: Fri, 19 Apr 2002 19:44:17 -0700 (PDT)
   
   I can't "look at the bfd and elf bits" to "find out" what the long
   double type size is.  The information simply isn't there.

Michael or someone, can we please bring closure to these
issues?  I've believe I've described my delimma ad nauseum
at this point.

Now, if debugging information contained the size/layout of
fundamental C types, we could solve this using that.  But
I somehow doubt this information is provided that way.

On another topic, I have like 10 or so RFAs pending, and nobody
provides any feedback.  Yet someone else submits a patch after all of
mine and it gets an RFA quite quickly.  It's not like I'm submitting
jumbo patches or anything, what gives?

I want to maintain and fix up the Sparc port, but I cannot do that
with multi-day lead times on patch review for even the most simple of
changes.  If nobody has the time to review my changes, then lets vote
on letting me be the Sparc maintainer because I do have the time to
keep it in good shape.

If the answer is "we don't have the time, and no you can't become the
Sparc maintainer", how the heck is someone supposed to become a
significant contributor to GDB? :(

I want to work on new bugs, failures in the testsuite, but I really
ought not to do that until my existing work is sorted out.

Re: [RFA] Sparc/Linux fixes part 1

[Jason R Thorpe]

On Sat, Apr 20, 2002 at 05:50:49PM -0700, David S. Miller wrote:

 > This won't work at all for my case.  There is no "elfosabi" to use to
 > distinguish between Solaris ELF 32-bit Sparc (which has 16 byte long
 > doubles) and Linux ELF 32-bit Sparc (which has 8 byte long doubles).

...so have your sparc-linux-{nat,tdep} _initialize function set the default
"sparc os abi" to Linux, or something.

 > Maybe I can say "there is no way to distinguish whether it is a Linux
 > 32-bit Sparc binary or a Solaris 32-bit Sparc one" 50 more times and
 > people would begin to understand the situation.

You don't have to distinguish between the two binaries.  Seems like you only
need to provide a default depending on the target GDB was configured for,
and a way to switch them at run-time.

(no ".note.ABI-tag" note section in sparc linux binaries, eh?  oh well... my
suggestion would still work :-)

 > Here, let me show everyone exactly what I am saying:
 > 
 > ? uname -a
 > Linux nuts.ninka.net 2.4.19-pre7 #1 SMP Fri Apr 19 20:18:39 PDT 2002 sparc64 unknown
 > ? readelf -h /bin/sh | grep OS
 >   OS/ABI:                            UNIX - System V
 > ? 
 > 
 > bash-2.03$ uname -a
 > SunOS caip.rutgers.edu 5.8 Generic_108528-13 sun4u sparc SUNW,Ultra-Enterprise-10000
 > bash-2.03$ readelf -h /bin/sh | grep OS
 >   OS/ABI:                            UNIX - System V
 > bash-2.03$ 
 > 
 > See?

Yes, I understood that from the beginning.

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [RFA] Sparc/Linux fixes part 1

[Jason R Thorpe]

On Sat, Apr 20, 2002 at 06:52:17PM -0700, David S. Miller wrote:

 > On another topic, I have like 10 or so RFAs pending, and nobody
 > provides any feedback.  Yet someone else submits a patch after all of
 > mine and it gets an RFA quite quickly.  It's not like I'm submitting
 > jumbo patches or anything, what gives?

Hm.  The sparc target is currently listed as maintainer-less.  I have a
similar dilemma with the alpha target ... who do I ask approval from if
I'm not doing the "considered obvious" stuff?

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Jason R Thorpe <thorpej@wasabisystems.com>
   Date: Sat, 20 Apr 2002 19:04:16 -0700

   You don't have to distinguish between the two binaries.  Seems like you only
   need to provide a default depending on the target GDB was configured for,
   and a way to switch them at run-time.
   
That's a great idea.

   (no ".note.ABI-tag" note section in sparc linux binaries, eh?  oh
   well... my suggestion would still work :-)

Indeed, that's the ticket.  Thanks for mentioning this.

Re: [RFA] Sparc/Linux fixes part 1

[Jason R Thorpe]

On Sat, Apr 20, 2002 at 07:10:23PM -0700, David S. Miller wrote:

 >    (no ".note.ABI-tag" note section in sparc linux binaries, eh?  oh
 >    well... my suggestion would still work :-)
 > 
 > Indeed, that's the ticket.  Thanks for mentioning this.

Cool.  You should be able to lift all the code you need for it
right from arm-tdep.c

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Jason R Thorpe <thorpej@wasabisystems.com>
   Date: Sat, 20 Apr 2002 19:24:20 -0700
   
   Cool.  You should be able to lift all the code you need for it
   right from arm-tdep.c

Right, i386-tdep.c has almost identical code as well.
(at least for the .note.ABI-tag parsing)

Re: [RFA] Sparc/Linux fixes part 1

[Andrew Cagney]

> On Sat, Apr 20, 2002 at 06:52:17PM -0700, David S. Miller wrote:
> 
>  > On another topic, I have like 10 or so RFAs pending, and nobody
>  > provides any feedback.  Yet someone else submits a patch after all of
>  > mine and it gets an RFA quite quickly.  It's not like I'm submitting
>  > jumbo patches or anything, what gives?
> 
> Hm.  The sparc target is currently listed as maintainer-less.  I have a
> similar dilemma with the alpha target ... who do I ask approval from if
> I'm not doing the "considered obvious" stuff?

 From MAINTAINERS:

> All developers recognized by this file can make arbitrary changes to
> OBSOLETE targets.
> 
> All maintainers can test and thence approve non-trivial changes to
> ``maintenance only'' targets submitted by recognized developers.
> 
> All recognized developers can make mechanical changes (by virtue of
> the obvious fix rule) to ``maintenance only'' targets.  The change
> shall be sanity checked by compiling with one of the listed targets.

However, typically, a global write maintainer, or I end up going through 
the changes.

enjoy,
Andrew

Re: [RFA] Sparc/Linux fixes part 1

[Andrew Cagney]

>  From: "David S. Miller" <davem@redhat.com>
> Date: Fri, 19 Apr 2002 19:44:17 -0700 (PDT)
>    
>    I can't "look at the bfd and elf bits" to "find out" what the long
>    double type size is.  The information simply isn't there.
> 

> Michael or someone, can we please bring closure to these
> issues?  I've believe I've described my delimma ad nauseum
> at this point.
> 
> Now, if debugging information contained the size/layout of
> fundamental C types, we could solve this using that.  But
> I somehow doubt this information is provided that way.

I believe JasonT's drawn your attention to the ARM and, hence, you've 
found a way to resolve this.

> On another topic, I have like 10 or so RFAs pending, and nobody
> provides any feedback.  Yet someone else submits a patch after all of
> mine and it gets an RFA quite quickly.  It's not like I'm submitting
> jumbo patches or anything, what gives?
> 
> I want to maintain and fix up the Sparc port, but I cannot do that
> with multi-day lead times on patch review for even the most simple of
> changes.  If nobody has the time to review my changes, then lets vote
> on letting me be the Sparc maintainer because I do have the time to
> keep it in good shape.

Unfortunatly, the changes you're making, while small, are often not 
simple or obvious and, in the case of the patch that went with this 
thread, not correct.

Please also appreciate that GDB runs on international time and most 
everyone on this list has a day job. Your changes will be reviewed but 
perhaphs not in the timeframe you seem to expect.

Andrew

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Sat, 20 Apr 2002 23:06:12 -0400
   
   Please also appreciate that GDB runs on international time and most 
   everyone on this list has a day job. Your changes will be reviewed but 
   perhaphs not in the timeframe you seem to expect.

My expectation is set based upon how the patches of others
are treated.

I produced a backlog of 12 patches, then Jason Thorpe posted his
patch.  You choose to review his change before any of the rest of
mine.

This is not the first time I've seen this kind of thing happen.
And it isn't because foo's patch is simpler than bar's patch, so
don't go down that road.

And honeslty, I find it erroneous to take out on me the fact that the
GDB maintainers don't have the time necessary to do their job.  I am
offering my time and assistance, as a mechanism to take some of the
load off of your shoulders.

My objective is to make is so that you need to spend less time on GDB
issues, so that when a Sparc specific bug is fielded, you can push it
to me instead of looking at it yourself.

By complaining that you don't have any time, you create a
self-fulfilling prophecy.  Because if you don't review submissions by
"up and coming" people in a timely manner, they get discouraged and go
away instead of eventually becomming "trusted" GDB developers who can
take the load off of your shoulders.

And again, you had time to look at Jason's patch from today and
decided to preempt looking at any of my backlog from the previous
day.

So my offer still stands, either make me sparc maintainer or assure me
that reviews will be performed in a timely manner.

[RFA] Sparc OS abi gdbarch init (was Re: [RFA] Sparc/Linux fixes part 1)

[David S. Miller]

   From: Jason R Thorpe <thorpej@wasabisystems.com>
   Date: Sat, 20 Apr 2002 19:24:20 -0700
   
   Cool.  You should be able to lift all the code you need for it
   right from arm-tdep.c
   
Infrastructure implemented thusly, ok to install?

2002-04-20  David S. Miller  <davem@redhat.com>

	* sparc-tdep.h: New file.
	* sparc-tdep.c (elf-bfd.h): Include.
	(SPARC_HAS_FPU, FP_REGISTER_BYTES, FP_MAX_REGNUM,
	SPARC_INTREG_SIZE, DUMMY_REG_SAVE_OFFSET, gdbarch_tdep,
	CALL_DUMMY_CALL_OFFSET): Move out to sparc-tdep.h
	(sparc_dump_tdep): New function.
	(_initialize_sparc_tdep): Use gdbarch_register instead of
	register_gdbarch_init which is deprecated.
	(process_note_abi_tag_sections, sparc_abi_handler,
	sparc_abi_handler_list, sparc_gdbarch_register_os_abi): New.
	(sparc_gdbarch_init): Determine elf os ident key based upon
	either the elf header or by using process_note_abi_tag_sections.
	Fix 'gdbarch already exists' test by comparing os_ident as well.
	As the last action, invoke OS abi_handler if installed.
	
--- ./Makefile.in.~1~	Mon Apr  8 20:06:13 2002
+++ ./Makefile.in	Sat Apr 20 20:18:29 2002
@@ -2053,7 +2053,7 @@ sparc-nat.o: sparc-nat.c $(bfd_h) $(defs
 
 sparc-tdep.o: sparc-tdep.c $(floatformat_h) $(defs_h) $(gdbcore_h) \
 	$(inferior_h) $(objfiles_h) $(symfile_h) $(target_h) $(gdb_string_h) \
-	$(arch_utils_h) $(regcache_h)
+	$(arch_utils_h) $(regcache_h) $(BFD_SRC)/elf-bfd.h sparc-tdep.h
 
 sparcl-tdep.o: sparcl-tdep.c $(defs_h) $(gdbcore_h) $(target_h) $(regcache_h)
 
--- ./sparc-tdep.c.~1~	Fri Apr 19 20:09:28 2002
+++ ./sparc-tdep.c	Sat Apr 20 20:21:56 2002
@@ -34,6 +34,8 @@
 #include "gdb_string.h"
 #include "regcache.h"
 
+#include "elf-bfd.h"
+
 #ifdef	USE_PROC_FS
 #include <sys/procfs.h>
 /* Prototypes for supply_gregset etc. */
@@ -44,74 +46,7 @@
 
 #include "symfile.h" 	/* for 'entry_point_address' */
 
-/*
- * Some local macros that have multi-arch and non-multi-arch versions:
- */
-
-#if (GDB_MULTI_ARCH > 0)
-
-/* Does the target have Floating Point registers?  */
-#define SPARC_HAS_FPU     (gdbarch_tdep (current_gdbarch)->has_fpu)
-/* Number of bytes devoted to Floating Point registers: */
-#define FP_REGISTER_BYTES (gdbarch_tdep (current_gdbarch)->fp_register_bytes)
-/* Highest numbered Floating Point register.  */
-#define FP_MAX_REGNUM     (gdbarch_tdep (current_gdbarch)->fp_max_regnum)
-/* Size of a general (integer) register: */
-#define SPARC_INTREG_SIZE (gdbarch_tdep (current_gdbarch)->intreg_size)
-/* Offset within the call dummy stack of the saved registers.  */
-#define DUMMY_REG_SAVE_OFFSET (gdbarch_tdep (current_gdbarch)->reg_save_offset)
-
-#else /* non-multi-arch */
-
-
-/* Does the target have Floating Point registers?  */
-#if defined(TARGET_SPARCLET) || defined(TARGET_SPARCLITE)
-#define SPARC_HAS_FPU 0
-#else
-#define SPARC_HAS_FPU 1
-#endif
-
-/* Number of bytes devoted to Floating Point registers: */
-#if (GDB_TARGET_IS_SPARC64)
-#define FP_REGISTER_BYTES (64 * 4)
-#else
-#if (SPARC_HAS_FPU)
-#define FP_REGISTER_BYTES (32 * 4)
-#else
-#define FP_REGISTER_BYTES 0
-#endif
-#endif
-
-/* Highest numbered Floating Point register.  */
-#if (GDB_TARGET_IS_SPARC64)
-#define FP_MAX_REGNUM (FP0_REGNUM + 48)
-#else
-#define FP_MAX_REGNUM (FP0_REGNUM + 32)
-#endif
-
-/* Size of a general (integer) register: */
-#define SPARC_INTREG_SIZE (REGISTER_RAW_SIZE (G0_REGNUM))
-
-/* Offset within the call dummy stack of the saved registers.  */
-#if (GDB_TARGET_IS_SPARC64)
-#define DUMMY_REG_SAVE_OFFSET (128 + 16)
-#else
-#define DUMMY_REG_SAVE_OFFSET 0x60
-#endif
-
-#endif /* GDB_MULTI_ARCH */
-
-struct gdbarch_tdep
-  {
-    int has_fpu;
-    int fp_register_bytes;
-    int y_regnum;
-    int fp_max_regnum;
-    int intreg_size;
-    int reg_save_offset;
-    int call_dummy_call_offset;
-    int print_insn_mach;
-  };
+#include "sparc-tdep.h"
 
 /* Now make GDB_TARGET_IS_SPARC64 a runtime test.  */
 /* FIXME MVS: or try testing bfd_arch_info.arch and bfd_arch_info.mach ... 
@@ -2132,11 +2067,6 @@ sparclet_store_return_value (struct type
 }
 
 
-#ifndef CALL_DUMMY_CALL_OFFSET
-#define CALL_DUMMY_CALL_OFFSET \
-     (gdbarch_tdep (current_gdbarch)->call_dummy_call_offset)
-#endif /* CALL_DUMMY_CALL_OFFSET */
-
 /* Insert the function address into a call dummy instruction sequence
    stored at DUMMY.
 
@@ -2237,11 +2167,13 @@ sparc_target_architecture_hook (const bf
 static struct gdbarch * sparc_gdbarch_init (struct gdbarch_info info,
 					    struct gdbarch_list *arches);
 
+static void sparc_dump_tdep (struct gdbarch *gdbarch, struct ui_file *file);
+
 void
 _initialize_sparc_tdep (void)
 {
   /* Hook us into the gdbarch mechanism.  */
-  register_gdbarch_init (bfd_arch_sparc, sparc_gdbarch_init);
+  gdbarch_register (bfd_arch_sparc, sparc_gdbarch_init, sparc_dump_tdep);
 
   tm_print_insn = gdb_print_insn_sparc;
   tm_print_insn_info.mach = TM_PRINT_INSN_MACH;		/* Selects sparc/sparclite */
@@ -2885,6 +2817,92 @@ sparc_return_value_on_stack (struct type
     return 0;
 }
 
+\f
+static void
+process_note_abi_tag_sections (bfd *abfd, asection *sect, void *obj)
+{
+  int *os_ident_ptr = obj;
+  const char *name;
+  unsigned int sect_size;
+
+  name = bfd_get_section_name (abfd, sect);
+  sect_size = bfd_section_size (abfd, sect);
+  if (strcmp (name, ".note.ABI-tag") == 0 && sect_size > 0)
+    {
+      unsigned int name_length, data_length, note_type;
+      char *note = alloca (sect_size);
+
+      bfd_get_section_contents (abfd, sect, note,
+                                (file_ptr) 0, (bfd_size_type) sect_size);
+
+      name_length = bfd_h_get_32 (abfd, note);
+      data_length = bfd_h_get_32 (abfd, note + 4);
+      note_type = bfd_h_get_32 (abfd, note + 8);
+
+      if (name_length == 4 && data_length == 16 && note_type == 1
+          && strcmp (note + 12, "GNU") == 0)
+        {
+          int os_number = bfd_h_get_32 (abfd, note + 16);
+
+          /* The case numbers are from abi-tags in glibc.  */
+          switch (os_number)
+            {
+            case 0:
+              *os_ident_ptr = ELFOSABI_LINUX;
+              break;
+            case 1:
+              *os_ident_ptr = ELFOSABI_HURD;
+              break;
+            case 2:
+              *os_ident_ptr = ELFOSABI_SOLARIS;
+              break;
+            default:
+              internal_error (__FILE__, __LINE__,
+                              "process_note_abi_sections: "
+                              "unknown OS number %d", os_number);
+              break;
+            }
+        }
+    }
+}
+
+struct sparc_abi_handler
+{
+  struct sparc_abi_handler *next;
+  int os_ident;
+  void (*init_abi)(struct gdbarch_info, struct gdbarch *);
+};
+
+struct sparc_abi_handler *sparc_abi_handler_list = NULL;
+
+void
+sparc_gdbarch_register_os_abi (int os_ident,
+			       void (*init_abi)(struct gdbarch_info,
+						struct gdbarch *))
+{
+  struct sparc_abi_handler *p;
+
+  for (p = sparc_abi_handler_list; p != NULL; p = p->next)
+    {
+      if (p->os_ident == os_ident)
+	{
+	  internal_error
+	    (__FILE__, __LINE__,
+	     "sparc_gdbarch_register_os_abi: A handler for this ABI variant (%d)"
+	     " has already been registered", (int)os_ident);
+	  /* If user wants to continue, override previous definition.  */
+	  p->init_abi = init_abi;
+	  return;
+	}
+    }
+
+  p = (struct sparc_abi_handler *) xmalloc (sizeof (*p));
+  p->os_ident = os_ident;
+  p->init_abi = init_abi;
+  p->next = sparc_abi_handler_list;
+  sparc_abi_handler_list = p;
+}
+
 /*
  * Gdbarch "constructor" function.
  */
@@ -2906,6 +2924,8 @@ sparc_gdbarch_init (struct gdbarch_info 
 {
   struct gdbarch *gdbarch;
   struct gdbarch_tdep *tdep;
+  struct sparc_abi_handler *abi_handler;
+  int os_ident;
 
   static LONGEST call_dummy_32[] = 
     { 0xbc100001, 0x9de38000, 0xbc100002, 0xbe100003,
@@ -2929,10 +2949,33 @@ sparc_gdbarch_init (struct gdbarch_info 
     };
   static LONGEST call_dummy_nil[] = {0};
 
+  if (info.abfd != NULL
+      && bfd_get_flavour (info.abfd) == bfd_target_elf_flavour)
+    {
+      os_ident = elf_elfheader (info.abfd)->e_ident[EI_OSABI];
+
+      /* If os_ident is 0, it is not necessarily the case that we're
+         on a SYSV system.  (ELFOSABI_NONE is defined to be 0.)
+         GNU/Linux uses a note section to record OS/ABI info, but
+         leaves e_ident[EI_OSABI] zero.  So we have to check for note
+         sections too.  */
+      if (os_ident == ELFOSABI_NONE)
+	bfd_map_over_sections (info.abfd,
+			       process_note_abi_tag_sections,
+			       &os_ident);
+    }
+  else
+    os_ident = -1;
+
   /* First see if there is already a gdbarch that can satisfy the request.  */
-  arches = gdbarch_list_lookup_by_info (arches, &info);
-  if (arches != NULL)
-    return arches->gdbarch;
+  for (arches = gdbarch_list_lookup_by_info (arches, &info);
+       arches != NULL;
+       arches = gdbarch_list_lookup_by_info (arches->next, &info))
+    {
+      tdep = gdbarch_tdep (arches->gdbarch);
+      if (tdep && tdep->os_ident == os_ident)
+        return arches->gdbarch;
+    }
 
   /* None found: is the request for a sparc architecture? */
   if (info.bfd_arch_info->arch != bfd_arch_sparc)
@@ -2942,6 +2985,8 @@ sparc_gdbarch_init (struct gdbarch_info 
   tdep = (struct gdbarch_tdep *) xmalloc (sizeof (struct gdbarch_tdep));
   gdbarch = gdbarch_alloc (&info, tdep);
 
+  tdep->os_ident = os_ident;
+
   /* First set settings that are common for all sparc architectures.  */
   set_gdbarch_believe_pcc_promotion (gdbarch, 1);
   set_gdbarch_breakpoint_from_pc (gdbarch, memory_breakpoint_from_pc);
@@ -3212,6 +3257,107 @@ sparc_gdbarch_init (struct gdbarch_info 
       break;
     }
 
+  for (abi_handler = sparc_abi_handler_list;
+       abi_handler;
+       abi_handler = abi_handler->next)
+    if (abi_handler->os_ident == os_ident)
+      break;
+
+  if (abi_handler)
+    abi_handler->init_abi (info, gdbarch);
+
   return gdbarch;
 }
 
+static void
+sparc_dump_tdep (struct gdbarch *gdbarch, struct ui_file *file)
+{
+  struct gdbarch_tdep *tdep = gdbarch_tdep (current_gdbarch);
+
+  if (tdep == NULL)
+    return;
+
+  fprintf_unfiltered (file, "sparc_dump_tdep: os_ident ");
+  switch (tdep->os_ident)
+    {
+    case ELFOSABI_NONE:
+      fprintf_unfiltered (file, "ELFOSABI_NONE");
+      break;
+    case ELFOSABI_NETBSD:
+      fprintf_unfiltered (file, "ELFOSABI_NETBSD");
+      break;
+    case ELFOSABI_LINUX:
+      fprintf_unfiltered (file, "ELFOSABI_LINUX");
+      break;
+    case ELFOSABI_HURD:
+      fprintf_unfiltered (file, "ELFOSABI_HURD");
+      break;
+    case ELFOSABI_SOLARIS:
+      fprintf_unfiltered (file, "ELFOSABI_SOLARIS");
+      break;
+    case ELFOSABI_FREEBSD:
+      fprintf_unfiltered (file, "ELFOSABI_FREEBSD");
+      break;
+    case ELFOSABI_OPENBSD:
+      fprintf_unfiltered (file, "ELFOSABI_OPENBSD");
+      break;
+    case ELFOSABI_STANDALONE:
+      fprintf_unfiltered (file, "ELFOSABI_STANDALONE");
+      break;
+    default:
+      fprintf_unfiltered (file, "UNKNOWN");
+      break;
+    }
+
+  fprintf_unfiltered (file, "sparc_dump_tdep: has_fpu %d\n",
+		      tdep->has_fpu);
+  fprintf_unfiltered (file, "sparc_dump_tdep: fp_register_bytes %d\n",
+		      tdep->fp_register_bytes);
+  fprintf_unfiltered (file, "sparc_dump_tdep: y_regnum %d\n",
+		      tdep->y_regnum);
+  fprintf_unfiltered (file, "sparc_dump_tdep: fp_max_regnum %d\n",
+		      tdep->fp_max_regnum);
+  fprintf_unfiltered (file, "sparc_dump_tdep: intreg_size %d\n",
+		      tdep->intreg_size);
+  fprintf_unfiltered (file, "sparc_dump_tdep: reg_save_offset %d\n",
+		      tdep->reg_save_offset);
+  fprintf_unfiltered (file, "sparc_dump_tdep: call_dummy_call_offset %d\n",
+		      tdep->call_dummy_call_offset);
+  fprintf_unfiltered (file, "sparc_dump_tdep: print_insn_mach ");
+  switch (tdep->print_insn_mach)
+    {
+    case bfd_mach_sparc:
+      fprintf_unfiltered (file, "bfd_mach_sparc\n");
+      break;
+    case bfd_mach_sparc_sparclet:
+      fprintf_unfiltered (file, "bfd_mach_sparc_sparclet\n");
+      break;
+    case bfd_mach_sparc_sparclite:
+      fprintf_unfiltered (file, "bfd_mach_sparc_sparclite\n");
+      break;
+    case bfd_mach_sparc_sparclite_le:
+      fprintf_unfiltered (file, "bfd_mach_sparc_sparclite_le\n");
+      break;
+    case bfd_mach_sparc_v8plus:
+      fprintf_unfiltered (file, "bfd_mach_sparc_v8plus\n");
+      break;
+    case bfd_mach_sparc_v8plusa:
+      fprintf_unfiltered (file, "bfd_mach_sparc_v8plusa\n");
+      break;
+    case bfd_mach_sparc_v8plusb:
+      fprintf_unfiltered (file, "bfd_mach_sparc_v8plusb\n");
+      break;
+    case bfd_mach_sparc_v9:
+      fprintf_unfiltered (file, "bfd_mach_sparc_v9\n");
+      break;
+    case bfd_mach_sparc_v9a:
+      fprintf_unfiltered (file, "bfd_mach_sparc_v9a\n");
+      break;
+    case bfd_mach_sparc_v9b:
+      fprintf_unfiltered (file, "bfd_mach_sparc_v9b\n");
+      break;
+    default:
+      fprintf_unfiltered (file, "UNKNOWN\n");
+      break;
+    };
+}
--- ./sparc-tdep.h.~1~	Sat Apr 20 20:24:22 2002
+++ ./sparc-tdep.h	Sat Apr 20 20:23:31 2002
@@ -0,0 +1,99 @@
+/* Common target dependent code for GDB on SPARC systems.
+   Copyright 2002 Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330,
+   Boston, MA 02111-1307, USA.  */
+
+/*
+ * Some local macros that have multi-arch and non-multi-arch versions:
+ */
+
+#if (GDB_MULTI_ARCH > 0)
+
+/* Does the target have Floating Point registers?  */
+#define SPARC_HAS_FPU     (gdbarch_tdep (current_gdbarch)->has_fpu)
+/* Number of bytes devoted to Floating Point registers: */
+#define FP_REGISTER_BYTES (gdbarch_tdep (current_gdbarch)->fp_register_bytes)
+/* Highest numbered Floating Point register.  */
+#define FP_MAX_REGNUM     (gdbarch_tdep (current_gdbarch)->fp_max_regnum)
+/* Size of a general (integer) register: */
+#define SPARC_INTREG_SIZE (gdbarch_tdep (current_gdbarch)->intreg_size)
+/* Offset within the call dummy stack of the saved registers.  */
+#define DUMMY_REG_SAVE_OFFSET (gdbarch_tdep (current_gdbarch)->reg_save_offset)
+
+#else /* non-multi-arch */
+
+/* Does the target have Floating Point registers?  */
+#if defined(TARGET_SPARCLET) || defined(TARGET_SPARCLITE)
+#define SPARC_HAS_FPU 0
+#else
+#define SPARC_HAS_FPU 1
+#endif
+
+/* Number of bytes devoted to Floating Point registers: */
+#if (GDB_TARGET_IS_SPARC64)
+#define FP_REGISTER_BYTES (64 * 4)
+#else
+#if (SPARC_HAS_FPU)
+#define FP_REGISTER_BYTES (32 * 4)
+#else
+#define FP_REGISTER_BYTES 0
+#endif
+#endif
+
+/* Highest numbered Floating Point register.  */
+#if (GDB_TARGET_IS_SPARC64)
+#define FP_MAX_REGNUM (FP0_REGNUM + 48)
+#else
+#define FP_MAX_REGNUM (FP0_REGNUM + 32)
+#endif
+
+/* Size of a general (integer) register: */
+#define SPARC_INTREG_SIZE (REGISTER_RAW_SIZE (G0_REGNUM))
+
+/* Offset within the call dummy stack of the saved registers.  */
+#if (GDB_TARGET_IS_SPARC64)
+#define DUMMY_REG_SAVE_OFFSET (128 + 16)
+#else
+#define DUMMY_REG_SAVE_OFFSET 0x60
+#endif
+
+#endif /* GDB_MULTI_ARCH */
+
+#ifndef CALL_DUMMY_CALL_OFFSET
+#define CALL_DUMMY_CALL_OFFSET \
+     (gdbarch_tdep (current_gdbarch)->call_dummy_call_offset)
+#endif /* CALL_DUMMY_CALL_OFFSET */
+
+struct gdbarch_tdep
+  {
+    int os_ident;
+    int has_fpu;
+    int fp_register_bytes;
+    int y_regnum;
+    int fp_max_regnum;
+    int intreg_size;
+    int reg_save_offset;
+    int call_dummy_call_offset;
+    int print_insn_mach;
+  };
+
+/* How a OS variant tells the SPARC generic code that it can handle an ABI
+   type.  */
+extern void sparc_gdbarch_register_os_abi (int os_ident,
+					   void (*init_abi)(struct gdbarch_info,
+							    struct gdbarch *));

Re: [RFA] Sparc/Linux fixes part 1

[Jason R Thorpe]

On Sat, Apr 20, 2002 at 08:09:57PM -0700, David S. Miller wrote:

 > I produced a backlog of 12 patches, then Jason Thorpe posted his
 > patch.  You choose to review his change before any of the rest of
 > mine.

Err, I don't think you're being completely fair to Andrew, here.  The
patch I posted to frame.c today was quite trivial, and the code it fixed
was pretty obviously broken, and thus the patch very easy to review.

The patches you've posted to the sparc target are not hugely complicated,
but have to be viewed in a wider context, and discussion about one of them
resulted in a do-over.

It's not like all of my patches get reviewed lightning-quick either... I've
been waiting for 8 days or so for approval of a patch that simply moves
code from one i386 support file to another :-)

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Jason R Thorpe <thorpej@wasabisystems.com>
   Date: Sat, 20 Apr 2002 21:24:25 -0700

   On Sat, Apr 20, 2002 at 08:09:57PM -0700, David S. Miller wrote:
   
    > I produced a backlog of 12 patches, then Jason Thorpe posted his
    > patch.  You choose to review his change before any of the rest of
    > mine.
   
   Err, I don't think you're being completely fair to Andrew, here.  The
   patch I posted to frame.c today was quite trivial, and the code it fixed
   was pretty obviously broken, and thus the patch very easy to review.

I posted patches of similar complexity.  For example:

	http://sources.redhat.com/ml/gdb-patches/2002-04/msg00675.html

And even the following "add braces to remove ambigous else warning"
didn't get a review either:

	http://sources.redhat.com/ml/gdb-patches/2002-04/msg00669.html

I mean, if that isn't easy to review, what the heck is?

No, I think am being totally fair with Andrew.

Re: [RFA] Sparc/Linux fixes part 1

[Andrew Cagney]

>  From: Jason R Thorpe <thorpej@wasabisystems.com>
> Date: Sat, 20 Apr 2002 21:24:25 -0700
> 
>    On Sat, Apr 20, 2002 at 08:09:57PM -0700, David S. Miller wrote:
>    
>     > I produced a backlog of 12 patches, then Jason Thorpe posted his
>     > patch.  You choose to review his change before any of the rest of
>     > mine.
>    
>    Err, I don't think you're being completely fair to Andrew, here.  The
>    patch I posted to frame.c today was quite trivial, and the code it fixed
>    was pretty obviously broken, and thus the patch very easy to review.
> 
> I posted patches of similar complexity.  For example:
> 
> 	http://sources.redhat.com/ml/gdb-patches/2002-04/msg00675.html
> 

The number of lines in a patch is not a good indicator of the amount of 
time required or the relative priority of a submitted change.

The other patch didn't contain a single macro, it refered to one 
one-line function (which I know backwards), it fixes a core dump, and 
the patch itself contained all the relevant code in question.  Given I 
only just changed the code myself, I'm also ``on the hook'' for any fallout.

On the other hand, the above patch contains alloca, macros, and zero 
context (surounding code).  It is changing code that currently works 
(just not efficiently) and, if wrong, will cause a stack buffer overrun.

enjoy,Andrew

Re: [RFA] Sparc/Linux fixes part 1

[Richard Earnshaw]

>    From: Andrew Cagney <ac131313@cygnus.com>
>    Date: Fri, 19 Apr 2002 22:46:23 -0400
>    
>    How does this Kernel, for instance, differentate between a GNU/Linux 
>    sparc binary and a Solaris binary when doing emulation?
> 
> I'm going to delete the Solaris binary support any day now as an
> aside.
> 
> The two binaries look identical, the both look like elf32_sparc.
> I don't know how many times I can say this.
> 
> "The binaries look identical, but we screwed up on Sparc/Linux
>  a long time ago and the long double type is 8 bytes instead of
>  the ABI mandated 16 bytes.  We are in no position to change this
>  with the amount of existing binaries out there."
> 
> There is no distinguising characterstic in the elf header nor anywhere
> else.

I'm sticking my nose in here where I probably don't know all the facts, so 
please excuse me if I'm barking up the wrong tree...

glibc does provide a note in the executable, which as I understand it, 
will differ between Linux and Solaris.  Can you not assume that if the 
note is missing entirely that you have a Sun/Solaris system and that if it 
is present you can use it to determine the OS and hence the ABI?

See glibc/abi-tags and glibc/csu/abi-note.S

R.

Re: [RFA] Sparc/Linux fixes part 1

[David S. Miller]

   From: Richard Earnshaw <rearnsha@arm.com>
   Date: Mon, 22 Apr 2002 11:54:56 +0100
   
   glibc does provide a note in the executable, which as I understand it, 
   will differ between Linux and Solaris.

This is what was discovered and how I began implementing
things, see:

	http://sources.redhat.com/ml/gdb-patches/2002-04/msg00710.html

for which I am still awaiting approval.

Re: [RFA] Sparc/Linux fixes part 1

[Elena Zannoni]

David S. Miller writes:
 > 
 > On another topic, I have like 10 or so RFAs pending, and nobody
 > provides any feedback.  Yet someone else submits a patch after all of
 > mine and it gets an RFA quite quickly.  It's not like I'm submitting
 > jumbo patches or anything, what gives?
 > 
 > I want to maintain and fix up the Sparc port, but I cannot do that
 > with multi-day lead times on patch review for even the most simple of
 > changes.  If nobody has the time to review my changes, then lets vote
 > on letting me be the Sparc maintainer because I do have the time to
 > keep it in good shape.
 > 
 > If the answer is "we don't have the time, and no you can't become the
 > Sparc maintainer", how the heck is someone supposed to become a
 > significant contributor to GDB? :(
 > 
 > I want to work on new bugs, failures in the testsuite, but I really
 > ought not to do that until my existing work is sorted out.


David, sorry, but I think your expectations are a bit unreasonable.
Michael Snyder, who is the Sparc host maintainer, replied to your
patches up to 7PM Friday night his time (2AM GMT). I assume after that
he had something else to do for the duration of the weekend.

You first complained that your patches had not been reviewed just 4 
hours after you submitted them. 

While everybody appreciates you fixing the sparc, it is going to take
a bit of time to get your patches reviewed. Please don't think we are
ignoring you. Everybody on this list is doing their best to maintain a
cooperative environment, and so far we have been fairly successful in
this regard.

To facilitate the review process, could I suggest you post a list of
pointers to your pending patches? I have seen a few of them being
checked in, reverted, etc, and it's getting a bit confusing.
Have any of the patches been withdrawn?


Thank you for your understanding.

Elena