Re: which patches to review

Re: which patches to review

[David S. Miller]

[ I deleted this from my inbox by accident so I'm replying
  to it by hand... sorry. ]

   Elena Zannoni said:

   could I suggest you post a list of pointers to your pending
   patches?

Ok, but I thought sending emails with "RFA" in the subject to
this list was sufficient to say which patches I want reviewed?
RFA means "request for approval", you can simply scan the GDB
list archives for every posting I made starting with RFA in
the subject, and if nobody has replied to it yet it means its
still pending.

I'm sending in a lot of changes, true.  But what really eats me is
that everyone besides me sticks to one of two things in order to
actually get work done with GDB:

1) Become maintainer, so you can just post patches to the target
   you maintain and you don't need to wait for review before
   installation.

2) Stick to "obvious" fixes and therefore can just check them in.

All day long these people get to install their fixes, yet their work
is not necessarily easier to review nor the changes more obviously
correct than mine.  Yet I am the one with a 30 patch backlog at this
point farting in my chair waiting for patches to be review before I
can work on new things.  30 patches basically means I maintain 30
checked out source trees waiting for approval so that I avoid
dependency problems.

And now I'm being told that I have to periodically post some kind
of "scoreboard" indicating what I want reviewed.

I'm spending all of my time in patch mangement, going above and beyond
what I really should have to do to get fixes installed (especially the
easier ones).  That is my main point.

However, since my goal is to work with people and get the fixes
installed, I will be more mindful in the future of people's schedules
and the time they are able to contribute to GDB patch review.  How
does that sound?

Anyways, back to the original question, the probably highest priority
(read as: one that causes the most dependencies for other changes I
 want to submit) is this one:

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

Which by the "multi-arch" rule I though I could install but Andrew
forced me to revert the changes until "sparc developers" (note the
plural) make some commentary.  As far as I am aware this means Michael
Snyder, which is just one person :-)

Re: which patches to review

[Elena Zannoni]

David S. Miller writes:
 > 
 > [ I deleted this from my inbox by accident so I'm replying
 >   to it by hand... sorry. ]
 > 
 >    Elena Zannoni said:
 > 
 >    could I suggest you post a list of pointers to your pending
 >    patches?
 > 
 > Ok, but I thought sending emails with "RFA" in the subject to
 > this list was sufficient to say which patches I want reviewed?
 > RFA means "request for approval", you can simply scan the GDB
 > list archives for every posting I made starting with RFA in
 > the subject, and if nobody has replied to it yet it means its
 > still pending.

You submitted an unusually large number of patches in a very short
time.  Plus you have committed and reverted some. The status of each
patch is not always clear.

 > 
 > I'm sending in a lot of changes, true.  But what really eats me is
 > that everyone besides me sticks to one of two things in order to
 > actually get work done with GDB:
 > 
 > 1) Become maintainer, so you can just post patches to the target
 >    you maintain and you don't need to wait for review before
 >    installation.
 > 
 > 2) Stick to "obvious" fixes and therefore can just check them in.

This is not true. Look through the archives for this mailing list.

 > 
 > All day long these people get to install their fixes, yet their work
 > is not necessarily easier to review nor the changes more obviously
 > correct than mine.  Yet I am the one with a 30 patch backlog at this
 > point farting in my chair waiting for patches to be review before I
 > can work on new things.  30 patches basically means I maintain 30
 > checked out source trees waiting for approval so that I avoid
 > dependency problems.
 > 

In my opinion, people have learned that since there may be only one
person responsible to review their patches, it make sense to send only
a few at the time. The reviewer's bandwith is limited.

 > And now I'm being told that I have to periodically post some kind
 > of "scoreboard" indicating what I want reviewed.
 > 

This is not the rule, but since your case is somewhat unusual, I
thought this would help the review process. You don't have to comply.

 > I'm spending all of my time in patch mangement, going above and beyond
 > what I really should have to do to get fixes installed (especially the
 > easier ones).  That is my main point.

Everybody goes through that. 

 > 
 > However, since my goal is to work with people and get the fixes
 > installed, I will be more mindful in the future of people's schedules
 > and the time they are able to contribute to GDB patch review.  How
 > does that sound?
 > 

Better.

 > Anyways, back to the original question, the probably highest priority
 > (read as: one that causes the most dependencies for other changes I
 >  want to submit) is this one:
 > 
 > 	http://sources.redhat.com/ml/gdb-patches/2002-04/msg00710.html
 > 
 > Which by the "multi-arch" rule I though I could install but Andrew
 > forced me to revert the changes until "sparc developers" (note the
 > plural) make some commentary.  As far as I am aware this means Michael
 > Snyder, which is just one person :-)

Exactly, just one person. 

Re: which patches to review

[Daniel Jacobowitz]

Please take this as it is meant; observations on the process rather
than criticism.  I think there's nothing we can do about it.  I
certainly have no suggestions.

On Tue, Apr 23, 2002 at 10:46:35AM -0400, Elena Zannoni wrote:
>  > I'm sending in a lot of changes, true.  But what really eats me is
>  > that everyone besides me sticks to one of two things in order to
>  > actually get work done with GDB:
>  > 
>  > 1) Become maintainer, so you can just post patches to the target
>  >    you maintain and you don't need to wait for review before
>  >    installation.
>  > 
>  > 2) Stick to "obvious" fixes and therefore can just check them in.
> 
> This is not true. Look through the archives for this mailing list.

Actually, Elena, I have to agree with David on this point.  I've been
lucky in that no one else is working on the areas I was fixing; that's
how I ended up maintainer for both of them.  It's not 100% true but
it's fairly accurate.

I'm not saying that there is anything to be done about it, or that
anything -must- be done about it, but there is a great gap between the
patch review process for binutils/gcc and the corresponding process for
GDB.  It's purely a manpower problem; we don't have enough dedicated
maintainers.

I greatly prefer not doing sweeping fixes to an area I don't maintain
in GDB; between the insistence on small patches and the long review
time, it's almost impossible to do something highly interdependent when
you can't just approve them yourself.

> In my opinion, people have learned that since there may be only one
> person responsible to review their patches, it make sense to send only
> a few at the time. The reviewer's bandwith is limited.

The submitter's time is also limited, and also valuable to the GDB
project.

>  > I'm spending all of my time in patch mangement, going above and beyond
>  > what I really should have to do to get fixes installed (especially the
>  > easier ones).  That is my main point.
> 
> Everybody goes through that. 

Everybody seems to stay in this stage, actually, except for the global
write maintainers or those who follow David's two bullets above (which
I try to).

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: which patches to review

[David S. Miller]

   From: Daniel Jacobowitz <drow@mvista.com>
   Date: Tue, 23 Apr 2002 10:54:59 -0400

   On Tue, Apr 23, 2002 at 10:46:35AM -0400, Elena Zannoni wrote:
   > This is not true. Look through the archives for this mailing list.
   
   Actually, Elena, I have to agree with David on this point.  I've been
   lucky in that no one else is working on the areas I was fixing; that's
   how I ended up maintainer for both of them.  It's not 100% true but
   it's fairly accurate.
   
Thank you Daniel, I was going crazy thinking I was the only person who
could see the problems the current GDB patch review process has.

   The submitter's time is also limited, and also valuable to the GDB
   project.
   
I think this is the most important comment made thus far.

Much of the commentary has been "the maintainers don't have the time",
and my main point is that this is a self-fulfilling prophecy.  There
are never going to be new up and coming GDB contributors, ie. the new
manpower needed, if the status quo continues like this.

This means, you guys should be excited and jump to it when some new
person comes on here and spams 30 patches to the list and is all
excited about contributing fixes to GDB.  This should especially be
the case if this new person is not getting paid to work on GDB and
is doing the work for more long lasting reliable reasons.

What is this project going to do with someone like me who can hit this
list with 30 patches to review a day?  How long can that kind of
situation continue?  And if it will just continue, what does the
contributors incentive end up looking like long term?

Be honest GDB maintainers, if you didn't have some external compelling
reason to contribute to GDB (e.g. it's your job to do it), would you
be willing to deal with the current review process as a new
contributor for any extended period of time?  I really doubt you'd
put up with it for long.

I'm really unhappy that my commentary has been met with claims that
I don't know what I'm talking about and that the patch review process
for GDB is "not so bad".  I've been working on and contributing to a
variety of high profile open source projects for 7+ years, and this
is the worst I've seen it for such an important source base like GDB.

Working on GCC/Binutils vs. GDB is like night and day, and I do not
believe this has %100 to do with manpower issues, it's partly because
of the approach taken by the maintainers to some extent.  This is a
very large barrier to entry to get real work done on GDB, whereas for
GCC/Binutils there really isn't.

Re: which patches to review

[Stan Shebs]

"David S. Miller" wrote:
> 
> Much of the commentary has been "the maintainers don't have the time",
> and my main point is that this is a self-fulfilling prophecy.  There
> are never going to be new up and coming GDB contributors, ie. the new
> manpower needed, if the status quo continues like this.

The system literally can't work if maintainers don't have the time
to review patches.  Maintainers either need to devote more time to
reviewing, or spend less time on each patch, or step back in favor
of someone who can do the job.

> Working on GCC/Binutils vs. GDB is like night and day, and I do not
> believe this has %100 to do with manpower issues, it's partly because
> of the approach taken by the maintainers to some extent.  This is a
> very large barrier to entry to get real work done on GDB, whereas for
> GCC/Binutils there really isn't.

One of the differences I notice with GCC is that there is less
agonizing over every detail of every patch.  When I put the basic
Darwin support into GCC, the files actually carried along some
crufty dead code inherited from old NeXT stuff, but since it only
affected Darwin, nobody worried about it (since then most of it
has been whacked).  There have been other patches that were brave
attempts, and looked good at first sight, but that didn't last a
week and had to be reverted.  No biggie, that's just a normal
part of the development process.

Another thing I notice with GCC is that while there is a wish
list for future development directions, patches are usually not
held hostage to that list.  It's OK for instance to wish that a
contributor would multi-arch an old macro instead of submitting
yet another use of it, but if the contributor doesn't want to do
that, take the patch anyway and worry about multi-arching later.

Stan

Re: which patches to review

[Andrew Cagney]

Please remember, GDB isn't GCC, is it Linux Kernel list.

> One of the differences I notice with GCC is that there is less
> agonizing over every detail of every patch.  When I put the basic
> Darwin support into GCC, the files actually carried along some
> crufty dead code inherited from old NeXT stuff, but since it only
> affected Darwin, nobody worried about it (since then most of it
> has been whacked).  There have been other patches that were brave
> attempts, and looked good at first sight, but that didn't last a
> week and had to be reverted.  No biggie, that's just a normal
> part of the development process.

Here, you're mistaken.

GDB has (fairly clearly) communicated standards and provided they are 
met, the new port just drops in.  They don't get thrown into limbo 
because a two month feature freeze.  They don't get wedged because the 
toolchain won't build for three weeks. They are even, typically, get 
pulled into release branches.

Its kind of ironic that while all this flaming has been going on, a 
brand new port of gdb (ALPHA/NetBSD) has just been dropped into place. 
A second target port, AVR is about ready to go (I got a panic attack and 
need to go back the assignments clerk.)  otherwize it, again, will drop 
into place.  The AVR port will likely even be pulled into the 5.2 branch 
as soon as 5.2 is released.

> Another thing I notice with GCC is that while there is a wish
> list for future development directions, patches are usually not
> held hostage to that list.  It's OK for instance to wish that a
> contributor would multi-arch an old macro instead of submitting
> yet another use of it, but if the contributor doesn't want to do
> that, take the patch anyway and worry about multi-arching later.

Again, you are mistaken.

GDB developers approve patches with ``please create a bug report'' and 
please include a FIXME...  However, they do also ensure that, to best 
code (in a pragmatic sense) goes in.  Have you recently looked in the 
bug database?

Or to look at it another way, we no longer screw up with things like the 
HP Merge.

enjoy,
Andrew

Re: which patches to review

[David S. Miller]

   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Wed, 24 Apr 2002 13:15:57 -0400

   Here, you're mistaken.
   
He isn't %100 wrong.  I've been asked repeatedly to basically
multi-arch the Sparc targets out the wazoo to get the Linux
Sparc bits in.

While I have no problem doing the multi-arch work (I actually think
it's a barrel of laughs to kill some of these ancient bogon macros
:-)), I would have much rathered merged my Sparc Linux support in THEN
multi-arch'd everything.

I've even stated this desire of mine multiple times during the
patch submission process.  Every time I got back a "well.. you should
really multi arch this first, and then multi arch that".

Right now all of the Sparc Linux bits are in a pending state because
they need to be sequenced after the multi-arch bits.  Currently, this
one is holding up sparc-linux-tdep from being added:

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

The Sparc Linux native bits are:

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

What remains after that are my bug fixes and all of those are in one
of three states:

1) Waiting on discussion on some issues.
2) Whatever issues are resolved, I have to rewrite the patch
3) Waiting for reports on whether Solaris regressions are
   introduced by the change

Do you see what I mean?  I could have Linux Sparc in there fully now,
but instead I'm in multi arch land.

Re: which patches to review

[Kevin Buettner]

On Apr 24, 10:38am, David S. Miller wrote:

> Right now all of the Sparc Linux bits are in a pending state because
> they need to be sequenced after the multi-arch bits.  Currently, this
> one is holding up sparc-linux-tdep from being added:
> 
> 	http://sources.redhat.com/ml/gdb-patches/2002-04/msg00710.html

I just took a quick look at this one and I think it's okay.  I was
going to complain about the fact this...

+#if (GDB_TARGET_IS_SPARC64)
+#define FP_MAX_REGNUM (FP0_REGNUM + 48)
+#else
+#define FP_MAX_REGNUM (FP0_REGNUM + 32)
+#endif

...appears in the new sparc-tdep.h, but then I realized that this was
simply moved over verbatim from sparc-tdep.c.  It seems reasonable to
me that this could/should be cleaned up in a later patch.

Anyway, I recommend that David's lynch-pin patch be approved.

Kevin

Re: which patches to review

[David S. Miller]

   From: Kevin Buettner <kevinb@redhat.com>
   Date: Wed, 24 Apr 2002 12:16:44 -0700

   +#if (GDB_TARGET_IS_SPARC64)
   +#define FP_MAX_REGNUM (FP0_REGNUM + 48)
   +#else
   +#define FP_MAX_REGNUM (FP0_REGNUM + 32)
   +#endif
   
   ...appears in the new sparc-tdep.h, but then I realized that this was
   simply moved over verbatim from sparc-tdep.c.  It seems reasonable to
   me that this could/should be cleaned up in a later patch.

Later in my patch backlog are already patches which do exactly this,
in two stages.  First stage is to force GDB_MULTI_ARCH to
GDB_MULTI_ARCH_PARTIAL, this is done in:

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

The next stage is to then kill all the non-multiarch ifdef Sparc code,
and this is what kills the block of code you are referring to.

Hmmm... I think I didn't post that part because of the dependency
it would create, and I would post it after first bit went in.

So here is that second part for reference.

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

	* sparc-tdep.c, config/sparc/tm-sp64.h, config/sparc/tm-sparc.h,
	config/sparc/tm-sparclet.h, config/sparc/tm-sparclite.h: Kill all
	non-multiarch ifdef'd code.

--- ./config/sparc/tm-sp64.h.~1~	Fri Apr  5 16:02:51 2002
+++ ./config/sparc/tm-sp64.h	Mon Apr 22 00:08:13 2002
@@ -25,416 +25,8 @@
 
 #define GDB_MULTI_ARCH GDB_MULTI_ARCH_PARTIAL
 
-#ifndef GDB_TARGET_IS_SPARC64
-#define GDB_TARGET_IS_SPARC64 1
-#endif
-
 #include "sparc/tm-sparc.h"
 
-/* Eeeew. Ok, we have to assume (for now) that the processor really is
-   in sparc64 mode. While this is the same instruction sequence as
-   on the Sparc, the stack frames are offset by +2047 (and the arguments
-   are 8 bytes instead of 4). */
-/* Instructions are:
-   std  %f10, [ %fp + 0x7a7 ]
-   std  %f8, [ %fp + 0x79f ]
-   std  %f6, [ %fp + 0x797 ]
-   std  %f4, [ %fp + 0x78f ]
-   std  %f2, [ %fp + 0x787 ]
-   std  %f0, [ %fp + 0x77f ]
-   std  %g6, [ %fp + 0x777 ]
-   std  %g4, [ %fp + 0x76f ]
-   std  %g2, [ %fp + 0x767 ]
-   std  %g0, [ %fp + 0x75f ]
-   std  %fp, [ %fp + 0x757 ]
-   std  %i4, [ %fp + 0x74f ]
-   std  %i2, [ %fp + 0x747 ]
-   std  %i0, [ %fp + 0x73f ]
-   nop
-   nop
-   nop
-   nop
-   rd  %tbr, %o0
-   st  %o0, [ %fp + 0x72b ]
-   rd  %tpc, %o0
-   st  %o0, [ %fp + 0x727 ]
-   rd  %psr, %o0
-   st  %o0, [ %fp + 0x723 ]
-   rd  %y, %o0
-   st  %o0, [ %fp + 0x71f ]
-   ldx  [ %sp + 0x8a7 ], %o5
-   ldx  [ %sp + 0x89f ], %o4
-   ldx  [ %sp + 0x897 ], %o3
-   ldx  [ %sp + 0x88f ], %o2
-   ldx  [ %sp + 0x887 ], %o1
-   call  %g0
-   ldx  [ %sp + 0x87f ], %o0
-   nop
-   ta  1
-   nop
-   nop
- */
-
-#if !defined (GDB_MULTI_ARCH) || (GDB_MULTI_ARCH == 0)
-/*
- * The following defines must go away for MULTI_ARCH.
- */
-
-#ifndef DO_CALL_DUMMY_ON_STACK
-
-/*
- * These defines will suffice for the AT_ENTRY_POINT call dummy method.
- */
-
-#undef  CALL_DUMMY
-#define CALL_DUMMY {0}
-#undef  CALL_DUMMY_LENGTH
-#define CALL_DUMMY_LENGTH 0
-#undef  CALL_DUMMY_CALL_OFFSET
-#define CALL_DUMMY_CALL_OFFSET 0
-#undef  CALL_DUMMY_START_OFFSET
-#define CALL_DUMMY_START_OFFSET 0
-#undef  CALL_DUMMY_BREAKPOINT_OFFSET
-#define CALL_DUMMY_BREAKPOINT_OFFSET 0
-#undef  CALL_DUMMY_BREAKPOINT_OFFSET_P
-#define CALL_DUMMY_BREAKPOINT_OFFSET_P 1
-#undef  CALL_DUMMY_LOCATION 
-#define CALL_DUMMY_LOCATION AT_ENTRY_POINT
-#undef  CALL_DUMMY_STACK_ADJUST
-#define CALL_DUMMY_STACK_ADJUST 128
-#undef  SIZEOF_CALL_DUMMY_WORDS
-#define SIZEOF_CALL_DUMMY_WORDS 0
-#undef  CALL_DUMMY_ADDRESS
-#define CALL_DUMMY_ADDRESS() entry_point_address()
-#undef  FIX_CALL_DUMMY
-#define FIX_CALL_DUMMY(DUMMYNAME, PC, FUN, NARGS, ARGS, TYPE, GCC_P) 
-#undef  PUSH_RETURN_ADDRESS
-#define PUSH_RETURN_ADDRESS(PC, SP) sparc_at_entry_push_return_address (PC, SP)
-extern CORE_ADDR 
-sparc_at_entry_push_return_address (CORE_ADDR pc, CORE_ADDR sp);
-
-#undef  STORE_STRUCT_RETURN
-#define STORE_STRUCT_RETURN(ADDR, SP) \
-     sparc_at_entry_store_struct_return (ADDR, SP)
-extern void 
-sparc_at_entry_store_struct_return (CORE_ADDR addr, CORE_ADDR sp);
-
-
-#else
-/*
- * Old call dummy method, with CALL_DUMMY on the stack.
- */
-
-#undef  CALL_DUMMY
-#define CALL_DUMMY {		 0x9de3bec0fd3fa7f7LL, 0xf93fa7eff53fa7e7LL,\
-				 0xf13fa7dfed3fa7d7LL, 0xe93fa7cfe53fa7c7LL,\
-				 0xe13fa7bfdd3fa7b7LL, 0xd93fa7afd53fa7a7LL,\
-				 0xd13fa79fcd3fa797LL, 0xc93fa78fc53fa787LL,\
-				 0xc13fa77fcc3fa777LL, 0xc83fa76fc43fa767LL,\
-				 0xc03fa75ffc3fa757LL, 0xf83fa74ff43fa747LL,\
-				 0xf03fa73f01000000LL, 0x0100000001000000LL,\
-				 0x0100000091580000LL, 0xd027a72b93500000LL,\
-				 0xd027a72791480000LL, 0xd027a72391400000LL,\
-				 0xd027a71fda5ba8a7LL, 0xd85ba89fd65ba897LL,\
-				 0xd45ba88fd25ba887LL, 0x9fc02000d05ba87fLL,\
-				 0x0100000091d02001LL, 0x0100000001000000LL }
-
-
-/* 128 is to reserve space to write the %i/%l registers that will be restored
-   when we resume. */
-#undef  CALL_DUMMY_STACK_ADJUST
-#define CALL_DUMMY_STACK_ADJUST 128
-
-/* Size of the call dummy in bytes. */
-#undef  CALL_DUMMY_LENGTH
-#define CALL_DUMMY_LENGTH 192
-
-/* Offset within CALL_DUMMY of the 'call' instruction. */
-#undef  CALL_DUMMY_START_OFFSET
-#define CALL_DUMMY_START_OFFSET 148
-
-/* Offset within CALL_DUMMY of the 'call' instruction. */
-#undef  CALL_DUMMY_CALL_OFFSET
-#define CALL_DUMMY_CALL_OFFSET (CALL_DUMMY_START_OFFSET + (5 * 4))
-
-/* Offset within CALL_DUMMY of the 'ta 1' instruction. */
-#undef  CALL_DUMMY_BREAKPOINT_OFFSET
-#define CALL_DUMMY_BREAKPOINT_OFFSET (CALL_DUMMY_START_OFFSET + (8 * 4))
-
-/* Let's GDB know that it can make a call_dummy breakpoint.  */
-#undef  CALL_DUMMY_BREAKPOINT_OFFSET_P
-#define CALL_DUMMY_BREAKPOINT_OFFSET_P 1
-
-/* Call dummy will be located on the stack.  */
-#undef  CALL_DUMMY_LOCATION
-#define CALL_DUMMY_LOCATION ON_STACK
-
-/* Insert the function address into the call dummy.  */
-#undef  FIX_CALL_DUMMY
-#define FIX_CALL_DUMMY(dummyname, pc, fun, nargs, args, type, gcc_p) \
- sparc_fix_call_dummy (dummyname, pc, fun, type, gcc_p)
-void sparc_fix_call_dummy (char *dummy, CORE_ADDR pc, CORE_ADDR fun,
-			   struct type *value_type, int using_gcc);
-
-
-/* The remainder of these will accept the default definition.  */
-#undef  SIZEOF_CALL_DUMMY_WORDS
-#undef  PUSH_RETURN_ADDRESS
-#undef  CALL_DUMMY_ADDRESS
-#undef  STORE_STRUCT_RETURN
-
-#endif
-
-/* Does the specified function use the "struct returning" convention
-   or the "value returning" convention?  The "value returning" convention
-   almost invariably returns the entire value in registers.  The
-   "struct returning" convention often returns the entire value in
-   memory, and passes a pointer (out of or into the function) saying
-   where the value (is or should go).
-
-   Since this sometimes depends on whether it was compiled with GCC,
-   this is also an argument.  This is used in call_function to build a
-   stack, and in value_being_returned to print return values. 
-
-   On Sparc64, we only pass pointers to structs if they're larger than
-   32 bytes. Otherwise they're stored in %o0-%o3 (floating-point
-   values go into %fp0-%fp3).  */
-
-#undef  USE_STRUCT_CONVENTION
-#define USE_STRUCT_CONVENTION(gcc_p, type) (TYPE_LENGTH (type) > 32)
-
-CORE_ADDR sparc64_push_arguments (int,
-				  struct value **, CORE_ADDR, int, CORE_ADDR);
-#undef PUSH_ARGUMENTS
-#define PUSH_ARGUMENTS(A,B,C,D,E) \
-     (sparc64_push_arguments ((A), (B), (C), (D), (E)))
-
-/* Store the address of the place in which to copy the structure the
-   subroutine will return.  This is called from call_function. */
-/* FIXME: V9 uses %o0 for this.  */
-
-#undef  STORE_STRUCT_RETURN
-#define STORE_STRUCT_RETURN(ADDR, SP) \
-  { target_write_memory ((SP)+(16*8), (char *)&(ADDR), 8); }
-
-/* Stack must be aligned on 128-bit boundaries when synthesizing
-   function calls. */
-
-#undef  STACK_ALIGN
-#define STACK_ALIGN(ADDR) (((ADDR) + 15 ) & -16)
-
-/* Initializer for an array of names of registers.
-   There should be NUM_REGS strings in this initializer.  */
-/* Some of these registers are only accessible from priviledged mode.
-   They are here for kernel debuggers, etc.  */
-/* FIXME: icc and xcc are currently considered separate registers.
-   This may have to change and consider them as just one (ccr).
-   Let's postpone this as long as we can.  It's nice to be able to set
-   them individually.  */
-/* FIXME: fcc0-3 are currently separate, even though they are also part of
-   fsr.  May have to remove them but let's postpone this as long as
-   possible.  It's nice to be able to set them individually.  */
-/* FIXME: Whether to include f33, f35, etc. here is not clear.
-   There are advantages and disadvantages.  */
-
-#undef  REGISTER_NAMES
-#define REGISTER_NAMES  \
-{ "g0", "g1", "g2", "g3", "g4", "g5", "g6", "g7",	\
-  "o0", "o1", "o2", "o3", "o4", "o5", "sp", "o7",	\
-  "l0", "l1", "l2", "l3", "l4", "l5", "l6", "l7",	\
-  "i0", "i1", "i2", "i3", "i4", "i5", "fp", "i7",	\
-								\
-  "f0", "f1", "f2", "f3", "f4", "f5", "f6", "f7",		\
-  "f8", "f9", "f10", "f11", "f12", "f13", "f14", "f15",		\
-  "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23",	\
-  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31",	\
-  "f32", "f34", "f36", "f38", "f40", "f42", "f44", "f46",	\
-  "f48", "f50", "f52", "f54", "f56", "f58", "f60", "f62",	\
-                                                                \
-  "pc", "npc", "ccr", "fsr", "fprs", "y", "asi",		\
-  "ver", "tick", "pil", "pstate",				\
-  "tstate", "tba", "tl", "tt", "tpc", "tnpc", "wstate",		\
-  "cwp", "cansave", "canrestore", "cleanwin", "otherwin",	\
-  "asr16", "asr17", "asr18", "asr19", "asr20", "asr21",		\
-  "asr22", "asr23", "asr24", "asr25", "asr26", "asr27",		\
-  "asr28", "asr29", "asr30", "asr31",				\
-  /* These are here at the end to simplify removing them if we have to.  */ \
-  "icc", "xcc", "fcc0", "fcc1", "fcc2", "fcc3"			\
-}
-
-#undef REG_STRUCT_HAS_ADDR
-#define REG_STRUCT_HAS_ADDR(gcc_p,type) (TYPE_LENGTH (type) > 32)
-
-extern CORE_ADDR sparc64_read_sp ();
-extern CORE_ADDR sparc64_read_fp ();
-extern void sparc64_write_sp (CORE_ADDR);
-
-#define TARGET_READ_SP() (sparc64_read_sp ())
-#define TARGET_READ_FP() (sparc64_read_fp ())
-#define TARGET_WRITE_SP(X) (sparc64_write_sp (X))
-
-#undef EXTRACT_RETURN_VALUE
-#define EXTRACT_RETURN_VALUE(TYPE,REGBUF,VALBUF) \
-     sp64_extract_return_value(TYPE, REGBUF, VALBUF, 0)
-extern void sp64_extract_return_value (struct type *, char[], char *, int);
-
-/* Register numbers of various important registers.
-   Note that some of these values are "real" register numbers,
-   and correspond to the general registers of the machine,
-   and some are "phony" register numbers which are too large
-   to be actual register numbers as far as the user is concerned
-   but do serve to get the desired values when passed to read_register.  */
-
-#if 0				/* defined in tm-sparc.h, replicated
-				   for doc purposes */
-#define	G0_REGNUM 0		/* %g0 */
-#define	G1_REGNUM 1		/* %g1 */
-#define O0_REGNUM 8		/* %o0 */
-#define	SP_REGNUM 14		/* Contains address of top of stack, \
-				   which is also the bottom of the frame.  */
-#define	RP_REGNUM 15		/* Contains return address value, *before* \
-				   any windows get switched.  */
-#define	O7_REGNUM 15		/* Last local reg not saved on stack frame */
-#define	L0_REGNUM 16		/* First local reg that's saved on stack frame
-				   rather than in machine registers */
-#define	I0_REGNUM 24		/* %i0 */
-#define	FP_REGNUM 30		/* Contains address of executing stack frame */
-#define	I7_REGNUM 31		/* Last local reg saved on stack frame */
-#define	FP0_REGNUM 32		/* Floating point register 0 */
-#endif
-
-/*#define FP_MAX_REGNUM 80*/	/* 1 + last fp reg number */
-
-/* #undef v8 misc. regs */
-
-#undef Y_REGNUM
-#undef PS_REGNUM
-#undef WIM_REGNUM
-#undef TBR_REGNUM
-#undef PC_REGNUM
-#undef NPC_REGNUM
-#undef FPS_REGNUM
-#undef CPS_REGNUM
-
-/* v9 misc. and priv. regs */
-
-#define C0_REGNUM 80			/* Start of control registers */
-
-#define PC_REGNUM (C0_REGNUM + 0)	/* Current PC */
-#define NPC_REGNUM (C0_REGNUM + 1)	/* Next PC */
-#define CCR_REGNUM (C0_REGNUM + 2)	/* Condition Code Register (%xcc,%icc) */
-#define FSR_REGNUM (C0_REGNUM + 3)	/* Floating Point State */
-#define FPRS_REGNUM (C0_REGNUM + 4)	/* Floating Point Registers State */
-#define	Y_REGNUM (C0_REGNUM + 5)	/* Temp register for multiplication, etc.  */
-#define ASI_REGNUM (C0_REGNUM + 6)	/* Alternate Space Identifier */
-#define VER_REGNUM (C0_REGNUM + 7)	/* Version register */
-#define TICK_REGNUM (C0_REGNUM + 8)	/* Tick register */
-#define PIL_REGNUM (C0_REGNUM + 9)	/* Processor Interrupt Level */
-#define PSTATE_REGNUM (C0_REGNUM + 10)	/* Processor State */
-#define TSTATE_REGNUM (C0_REGNUM + 11)	/* Trap State */
-#define TBA_REGNUM (C0_REGNUM + 12)	/* Trap Base Address */
-#define TL_REGNUM (C0_REGNUM + 13)	/* Trap Level */
-#define TT_REGNUM (C0_REGNUM + 14)	/* Trap Type */
-#define TPC_REGNUM (C0_REGNUM + 15)	/* Trap pc */
-#define TNPC_REGNUM (C0_REGNUM + 16)	/* Trap npc */
-#define WSTATE_REGNUM (C0_REGNUM + 17)	/* Window State */
-#define CWP_REGNUM (C0_REGNUM + 18)	/* Current Window Pointer */
-#define CANSAVE_REGNUM (C0_REGNUM + 19)		/* Savable Windows */
-#define CANRESTORE_REGNUM (C0_REGNUM + 20)	/* Restorable Windows */
-#define CLEANWIN_REGNUM (C0_REGNUM + 21)	/* Clean Windows */
-#define OTHERWIN_REGNUM (C0_REGNUM + 22)	/* Other Windows */
-#define ASR_REGNUM(n) (C0_REGNUM+(23-16)+(n))	/* Ancillary State Register
-						   (n = 16...31) */
-#define ICC_REGNUM (C0_REGNUM + 39)	/* 32 bit condition codes */
-#define XCC_REGNUM (C0_REGNUM + 40)	/* 64 bit condition codes */
-#define FCC0_REGNUM (C0_REGNUM + 41)	/* fp cc reg 0 */
-#define FCC1_REGNUM (C0_REGNUM + 42)	/* fp cc reg 1 */
-#define FCC2_REGNUM (C0_REGNUM + 43)	/* fp cc reg 2 */
-#define FCC3_REGNUM (C0_REGNUM + 44)	/* fp cc reg 3 */
-
-/* Number of machine registers.  */
-
-#undef  NUM_REGS
-#define NUM_REGS 125
-
-/* Total amount of space needed to store our copies of the machine's
-   register state, the array `registers'.
-   Some of the registers aren't 64 bits, but it's a lot simpler just to assume
-   they all are (since most of them are).  */
-#undef  REGISTER_BYTES
-#define REGISTER_BYTES (32*8+32*8+45*8)
-
-/* Index within `registers' of the first byte of the space for
-   register N.  */
-#undef  REGISTER_BYTE
-#define REGISTER_BYTE(N) \
-  ((N) < 32 ? (N)*8				\
-   : (N) < 64 ? 32*8 + ((N)-32)*4		\
-   : (N) < C0_REGNUM ? 32*8 + 32*4 + ((N)-64)*8	\
-   : 64*8 + ((N)-C0_REGNUM)*8)
-
-/* Say how long (ordinary) registers are.  This is a piece of bogosity
-   used in push_word and a few other places; REGISTER_RAW_SIZE is the
-   real way to know how big a register is.  */
-
-#undef  REGISTER_SIZE
-#define REGISTER_SIZE 8
-
-/* Number of bytes of storage in the actual machine representation
-   for register N.  */
-
-#undef  REGISTER_RAW_SIZE
-#define REGISTER_RAW_SIZE(N) \
-  ((N) < 32 ? 8 : (N) < 64 ? 4 : 8)
-
-/* Number of bytes of storage in the program's representation
-   for register N.  */
-
-#undef  REGISTER_VIRTUAL_SIZE
-#define REGISTER_VIRTUAL_SIZE(N) \
-  ((N) < 32 ? 8 : (N) < 64 ? 4 : 8)
-
-/* Largest value REGISTER_RAW_SIZE can have.  */
-/* tm-sparc.h defines this as 8, but play it safe.  */
-
-#undef  MAX_REGISTER_RAW_SIZE
-#define MAX_REGISTER_RAW_SIZE 8
-
-/* Largest value REGISTER_VIRTUAL_SIZE can have.  */
-/* tm-sparc.h defines this as 8, but play it safe.  */
-
-#undef  MAX_REGISTER_VIRTUAL_SIZE
-#define MAX_REGISTER_VIRTUAL_SIZE 8
-
-/* Return the GDB type object for the "standard" data type
-   of data in register N.  */
-
-#undef  REGISTER_VIRTUAL_TYPE
-#define REGISTER_VIRTUAL_TYPE(N) \
- ((N) < 32 ? builtin_type_long_long \
-  : (N) < 64 ? builtin_type_float \
-  : (N) < 80 ? builtin_type_double \
-  : builtin_type_long_long)
-
-/* We use to support both 32 bit and 64 bit pointers.
-   We can't anymore because TARGET_PTR_BIT must now be a constant.  */
-#undef  TARGET_PTR_BIT
-#define TARGET_PTR_BIT 64
-
-/* Longs are 64 bits. */
-#undef TARGET_LONG_BIT
-#define TARGET_LONG_BIT 64
-
-#undef TARGET_LONG_LONG_BIT
-#define TARGET_LONG_LONG_BIT 64
-
-/* Return number of bytes at start of arglist that are not really args.  */
-
-#undef  FRAME_ARGS_SKIP
-#define FRAME_ARGS_SKIP 136
-
-#endif /* GDB_MULTI_ARCH */
-\f
 /* Offsets into jmp_buf.
    FIXME: This was borrowed from the v8 stuff and will probably have to change
    for v9.  */
--- ./config/sparc/tm-sparc.h.~1~	Sun Apr 21 19:17:03 2002
+++ ./config/sparc/tm-sparc.h	Mon Apr 22 00:11:13 2002
@@ -116,218 +116,18 @@ enum {	/* Sparc64 control registers, exc
  * Make sparc target multi-archable: April 2000
  */
 
-#if defined (GDB_MULTI_ARCH) && (GDB_MULTI_ARCH > 0)
-
 /* Multi-arch definition of TARGET_IS_SPARC64, TARGET_ELF64 */
-#undef  GDB_TARGET_IS_SPARC64
 #define GDB_TARGET_IS_SPARC64 \
      (sparc_intreg_size () == 8)
-#undef  TARGET_ELF64
 #define TARGET_ELF64 \
      (sparc_intreg_size () == 8)
 extern int sparc_intreg_size (void);
-#else
-
-/* Non-multi-arch: if it isn't defined, define it to zero.  */
-#ifndef GDB_TARGET_IS_SPARC64
-#define GDB_TARGET_IS_SPARC64 0
-#endif
-#ifndef TARGET_ELF64
-#define TARGET_ELF64 0
-#endif
-#endif
-
-#if !defined (GDB_MULTI_ARCH) || (GDB_MULTI_ARCH == 0)
-/*
- * The following defines must go away for MULTI_ARCH
- */
-
-/* Initializer for an array of names of registers.
-   There should be NUM_REGS strings in this initializer.  */
-
-#define REGISTER_NAMES  \
-{ "g0", "g1", "g2", "g3", "g4", "g5", "g6", "g7",		\
-  "o0", "o1", "o2", "o3", "o4", "o5", "sp", "o7",		\
-  "l0", "l1", "l2", "l3", "l4", "l5", "l6", "l7",		\
-  "i0", "i1", "i2", "i3", "i4", "i5", "fp", "i7",		\
-								\
-  "f0", "f1", "f2", "f3", "f4", "f5", "f6", "f7",		\
-  "f8", "f9", "f10", "f11", "f12", "f13", "f14", "f15",		\
-  "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23",	\
-  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31",	\
-                                                                \
-  "y", "psr", "wim", "tbr", "pc", "npc", "fpsr", "cpsr" 	\
-}
-
-/* Offset from address of function to start of its code.
-   Zero on most machines.  */
-
-#define FUNCTION_START_OFFSET 0
-
-/* Amount PC must be decremented by after a breakpoint.
-   This is often the number of bytes in BREAKPOINT
-   but not always.  */
-
-#define DECR_PC_AFTER_BREAK 0
-
-/* Say how long (ordinary) registers are.  This is a piece of bogosity
-   used in push_word and a few other places; REGISTER_RAW_SIZE is the
-   real way to know how big a register is.  */
-
-#define REGISTER_SIZE 4
-
-/* Number of machine registers */
-
-#define NUM_REGS 72
-
-#define	SP_REGNUM 14		/* Contains address of top of stack, \
-				   which is also the bottom of the frame.  */
-#define	FP_REGNUM 30		/* Contains address of executing stack frame */
-
-#define	FP0_REGNUM 32		/* Floating point register 0 */
-
-#define	Y_REGNUM 64		/* Temp register for multiplication, etc.  */
-
-#define	PC_REGNUM 68		/* Contains program counter */
-
-#define	NPC_REGNUM 69		/* Contains next PC */
-
-
-/* Total amount of space needed to store our copies of the machine's
-   register state, the array `registers'.  On the sparc, `registers'
-   contains the ins and locals, even though they are saved on the
-   stack rather than with the other registers, and this causes hair
-   and confusion in places like pop_frame.  It might be better to
-   remove the ins and locals from `registers', make sure that
-   get_saved_register can get them from the stack (even in the
-   innermost frame), and make this the way to access them.  For the
-   frame pointer we would do that via TARGET_READ_FP.  On the other
-   hand, that is likely to be confusing or worse for flat frames.  */
-
-#define REGISTER_BYTES (32*4+32*4+8*4)
-
-/* Index within `registers' of the first byte of the space for
-   register N.  */
-
-#define REGISTER_BYTE(N)  ((N)*4)
-
-/* Number of bytes of storage in the actual machine representation for
-   register N.  */
-
-/* On the SPARC, all regs are 4 bytes (except Sparc64, where they're 8).  */
-
-#define REGISTER_RAW_SIZE(N) (4)
-
-/* Number of bytes of storage in the program's representation
-   for register N.  */
-
-/* On the SPARC, all regs are 4 bytes (except Sparc64, where they're 8).  */
-
-#define REGISTER_VIRTUAL_SIZE(N) (4)
-
-/* Largest value REGISTER_RAW_SIZE can have.  */
-
-#define MAX_REGISTER_RAW_SIZE 8
-
-/* Largest value REGISTER_VIRTUAL_SIZE can have.  */
-
-#define MAX_REGISTER_VIRTUAL_SIZE 8
-
-/* Return the GDB type object for the "standard" data type
-   of data in register N.  */
-
-#define REGISTER_VIRTUAL_TYPE(N) \
-     ((N) < 32 ? builtin_type_int : (N) < 64 ? builtin_type_float : \
-      builtin_type_int)
-
-/* Sun /bin/cc gets this right as of SunOS 4.1.x.  We need to define
-   BELIEVE_PCC_PROMOTION to get this right now that the code which
-   detects gcc2_compiled. is broken.  This loses for SunOS 4.0.x and
-   earlier.  */
-
-#define BELIEVE_PCC_PROMOTION 1
-
-/* Advance PC across any function entry prologue instructions
-   to reach some "real" code.  */
-
-extern CORE_ADDR sparc_skip_prologue (CORE_ADDR, int);
-#define SKIP_PROLOGUE(PC) sparc_skip_prologue (PC, 0)
-
-/* Immediately after a function call, return the saved pc.
-   Can't go through the frames for this because on some machines
-   the new frame is not set up until the new function executes
-   some instructions.  */
-
-#define SAVED_PC_AFTER_CALL(FRAME) PC_ADJUST (read_register (RP_REGNUM))
-
-/* Stack grows downward.  */
-
-#define INNER_THAN(LHS,RHS) ((LHS) < (RHS))
-
-/* Write into appropriate registers a function return value of type
-   TYPE, given in virtual format.  */
-
-#define STORE_RETURN_VALUE(TYPE, VALBUF) \
-     sparc_store_return_value (TYPE, VALBUF)
-extern void sparc_store_return_value (struct type *, char *);
-
-/* Extract from an array REGBUF containing the (raw) register state
-   the address in which a function should return its structure value,
-   as a CORE_ADDR (or an expression that can be used as one).  */
-
-#define EXTRACT_STRUCT_VALUE_ADDRESS(REGBUF) \
-     sparc_extract_struct_value_address (REGBUF)
-
-extern CORE_ADDR sparc_extract_struct_value_address (char *);
-
-/* If the current gcc for for this target does not produce correct
-   debugging information for float parameters, both prototyped and
-   unprototyped, then define this macro.  This forces gdb to always
-   assume that floats are passed as doubles and then converted in the
-   callee. */
-
-#define COERCE_FLOAT_TO_DOUBLE(FORMAL, ACTUAL) (1)
-
-/* Stack must be aligned on 64-bit boundaries when synthesizing
-   function calls (128-bit for sparc64).  */
-
-#define STACK_ALIGN(ADDR) sparc32_stack_align (ADDR)
-extern CORE_ADDR sparc32_stack_align (CORE_ADDR addr);
-
-/* The Sparc returns long doubles on the stack.  */
-
-#define RETURN_VALUE_ON_STACK(TYPE) \
-  (TYPE_CODE(TYPE) == TYPE_CODE_FLT \
-   && TYPE_LENGTH(TYPE) > 8)
-
-/* When passing a structure to a function, Sun cc passes the address
-   not the structure itself.  It (under SunOS4) creates two symbols,
-   which we need to combine to a LOC_REGPARM.  Gcc version two (as of
-   1.92) behaves like sun cc.  REG_STRUCT_HAS_ADDR is smart enough to
-   distinguish between Sun cc, gcc version 1 and gcc version 2.  */
-
-#define REG_STRUCT_HAS_ADDR(GCC_P, TYPE) \
-     sparc_reg_struct_has_addr (GCC_P, TYPE)
-extern int sparc_reg_struct_has_addr (int, struct type *);
-
-/* Is the prologue at PC frameless?  */
-#define PROLOGUE_FRAMELESS_P(PC) sparc_prologue_frameless_p (PC)
-extern int sparc_prologue_frameless_p (CORE_ADDR);
-
-#endif /* GDB_MULTI_ARCH */
-
-#if defined (GDB_MULTI_ARCH) && (GDB_MULTI_ARCH > 0)
-/*
- * The following defines should ONLY appear for MULTI_ARCH.
- */
 
 /* Multi-arch the nPC and Y registers.  */
 #define Y_REGNUM              (sparc_y_regnum ())
 extern int sparc_npc_regnum (void);
 extern int sparc_y_regnum (void);
 
-#endif /* GDB_MULTI_ARCH */
-
 /* On the Sun 4 under SunOS, the compile will leave a fake insn which
    encodes the structure size being returned.  If we detect such
    a fake insn, step past it.  */
@@ -399,120 +199,6 @@ extern CORE_ADDR sparc_pc_adjust (CORE_A
 
 #define CANNOT_STORE_REGISTER(regno) ((regno) == G0_REGNUM)
 
-/*
- * FRAME_CHAIN and FRAME_INFO definitions, collected here for convenience.
- */
-
-#if !defined (GDB_MULTI_ARCH) || (GDB_MULTI_ARCH == 0)
-/*
- * The following defines must go away for MULTI_ARCH.
- */
-
-/* Describe the pointer in each stack frame to the previous stack frame
-   (its caller).  */
-
-/* FRAME_CHAIN takes a frame's nominal address
-   and produces the frame's chain-pointer. */
-
-/* In the case of the Sun 4, the frame-chain's nominal address
-   is held in the frame pointer register.
-
-   On the Sun4, the frame (in %fp) is %sp for the previous frame.
-   From the previous frame's %sp, we can find the previous frame's
-   %fp: it is in the save area just above the previous frame's %sp.
-
-   If we are setting up an arbitrary frame, we'll need to know where
-   it ends.  Hence the following.  This part of the frame cache
-   structure should be checked before it is assumed that this frame's
-   bottom is in the stack pointer.
-
-   If there isn't a frame below this one, the bottom of this frame is
-   in the stack pointer.
-
-   If there is a frame below this one, and the frame pointers are
-   identical, it's a leaf frame and the bottoms are the same also.
-
-   Otherwise the bottom of this frame is the top of the next frame.
-
-   The bottom field is misnamed, since it might imply that memory from
-   bottom to frame contains this frame.  That need not be true if
-   stack frames are allocated in different segments (e.g. some on a
-   stack, some on a heap in the data segment).
-
-   GCC 2.6 and later can generate ``flat register window'' code that
-   makes frames by explicitly saving those registers that need to be
-   saved.  %i7 is used as the frame pointer, and the frame is laid out
-   so that flat and non-flat calls can be intermixed freely within a
-   program.  Unfortunately for GDB, this means it must detect and
-   record the flatness of frames.
-
-   Since the prologue in a flat frame also tells us where fp and pc
-   have been stashed (the frame is of variable size, so their location
-   is not fixed), it's convenient to record them in the frame info.  */
-
-#define EXTRA_FRAME_INFO \
-  CORE_ADDR bottom;      \
-  int in_prologue;       \
-  int flat;              \
-  /* Following fields only relevant for flat frames.  */ \
-  CORE_ADDR pc_addr;     \
-  CORE_ADDR fp_addr;     \
-  /* Add this to ->frame to get the value of the stack pointer at the */ \
-  /* time of the register saves.  */ \
-  int sp_offset;
-
-/* We need to override GET_SAVED_REGISTER so that we can deal with the
-   way outs change into ins in different frames.  */
-
-void sparc_get_saved_register (char *raw_buffer,
-			       int *optimized,
-			       CORE_ADDR * addrp,
-			       struct frame_info *frame,
-			       int regnum, enum lval_type *lvalp);
-
-#define GET_SAVED_REGISTER(RAW_BUFFER, OPTIMIZED, ADDRP, FRAME, REGNUM, LVAL) \
-     sparc_get_saved_register (RAW_BUFFER, OPTIMIZED, ADDRP, \
-			       FRAME, REGNUM, LVAL)
-
-#define FRAME_INIT_SAVED_REGS(FP)	/*no-op */
-
-#define INIT_EXTRA_FRAME_INFO(FROMLEAF, FCI) \
-     sparc_init_extra_frame_info (FROMLEAF, FCI)
-extern void sparc_init_extra_frame_info (int, struct frame_info *);
-
-#define FRAME_CHAIN(THISFRAME) (sparc_frame_chain (THISFRAME))
-extern CORE_ADDR sparc_frame_chain (struct frame_info *);
-
-/* A macro that tells us whether the function invocation represented
-   by FI does not have a frame on the stack associated with it.  If it
-   does not, FRAMELESS is set to 1, else 0.  */
-
-#define FRAMELESS_FUNCTION_INVOCATION(FI) \
-     frameless_look_for_prologue (FI)
-
-/* Where is the PC for a specific frame */
-
-#define FRAME_SAVED_PC(FRAME) sparc_frame_saved_pc (FRAME)
-extern CORE_ADDR sparc_frame_saved_pc (struct frame_info *);
-
-/* If the argument is on the stack, it will be here.  */
-#define FRAME_ARGS_ADDRESS(FI) ((FI)->frame)
-
-#define FRAME_LOCALS_ADDRESS(FI) ((FI)->frame)
-
-/* Set VAL to the number of args passed to frame described by FI.
-   Can set VAL to -1, meaning no way to tell.  */
-
-/* We can't tell how many args there are
-   now that the C compiler delays popping them.  */
-#define FRAME_NUM_ARGS(FI) (-1)
-
-/* Return number of bytes at start of arglist that are not really args.  */
-
-#define FRAME_ARGS_SKIP 68
-
-#endif /* GDB_MULTI_ARCH */
-
 #define	PRINT_EXTRA_FRAME_INFO(FI) \
      sparc_print_extra_frame_info (FI)
 extern void sparc_print_extra_frame_info (struct frame_info *);
@@ -535,193 +221,6 @@ extern void sparc_print_extra_frame_info
 #define	FRAME_SAVED_I0	(8 * REGISTER_RAW_SIZE (L0_REGNUM))
 
 #define FRAME_STRUCT_ARGS_ADDRESS(FI) ((FI)->frame)
-
-/* Things needed for making the inferior call functions.  */
-/*
- * First of all, let me give my opinion of what the DUMMY_FRAME
- * actually looks like.
- *
- *               |                                 |
- *               |                                 |
- *               + - - - - - - - - - - - - - - - - +<-- fp (level 0)
- *               |                                 |
- *               |                                 |
- *               |                                 |
- *               |                                 |
- *               |  Frame of innermost program     |
- *               |           function              |
- *               |                                 |
- *               |                                 |
- *               |                                 |
- *               |                                 |
- *               |                                 |
- *               |---------------------------------|<-- sp (level 0), fp (c)
- *               |                                 |
- *     DUMMY     |             fp0-31              |
- *               |                                 |
- *               |             ------              |<-- fp - 0x80
- *     FRAME     |              g0-7               |<-- fp - 0xa0
- *               |              i0-7               |<-- fp - 0xc0
- *               |             other               |<-- fp - 0xe0
- *               |               ?                 |
- *               |               ?                 |
- *               |---------------------------------|<-- sp' = fp - 0x140
- *               |                                 |
- * xcution start |                                 |
- * sp' + 0x94 -->|        CALL_DUMMY (x code)      |
- *               |                                 |
- *               |                                 |
- *               |---------------------------------|<-- sp'' = fp - 0x200
- *               |  align sp to 8 byte boundary    |
- *               |     ==> args to fn <==          |
- *  Room for     |                                 |
- * i & l's + agg | CALL_DUMMY_STACK_ADJUST = 0x0x44|
- *               |---------------------------------|<-- final sp (variable)
- *               |                                 |
- *               |   Where function called will    |
- *               |           build frame.          |
- *               |                                 |
- *               |                                 |
- *
- *   I understand everything in this picture except what the space
- * between fp - 0xe0 and fp - 0x140 is used for.  Oh, and I don't
- * understand why there's a large chunk of CALL_DUMMY that never gets
- * executed (its function is superceeded by PUSH_DUMMY_FRAME; they
- * are designed to do the same thing).
- *
- *   PUSH_DUMMY_FRAME saves the registers above sp' and pushes the
- * register file stack down one.
- *
- *   call_function then writes CALL_DUMMY, pushes the args onto the
- * stack, and adjusts the stack pointer.
- *
- *   run_stack_dummy then starts execution (in the middle of
- * CALL_DUMMY, as directed by call_function).
- */
-
-#ifndef CALL_DUMMY
-/* This sequence of words is the instructions
-
-   00:   bc 10 00 01     mov  %g1, %fp
-   04:   9d e3 80 00     save  %sp, %g0, %sp
-   08:   bc 10 00 02     mov  %g2, %fp
-   0c:   be 10 00 03     mov  %g3, %i7
-   10:   da 03 a0 58     ld  [ %sp + 0x58 ], %o5
-   14:   d8 03 a0 54     ld  [ %sp + 0x54 ], %o4
-   18:   d6 03 a0 50     ld  [ %sp + 0x50 ], %o3
-   1c:   d4 03 a0 4c     ld  [ %sp + 0x4c ], %o2
-   20:   d2 03 a0 48     ld  [ %sp + 0x48 ], %o1
-   24:   40 00 00 00     call  <fun>
-   28:   d0 03 a0 44     ld  [ %sp + 0x44 ], %o0
-   2c:   01 00 00 00     nop 
-   30:   91 d0 20 01     ta  1
-   34:   01 00 00 00     nop
-
-   NOTES:
-   * the first four instructions are necessary only on the simulator.
-   * this is a multiple of 8 (not only 4) bytes.
-   * the `call' insn is a relative, not an absolute call.
-   * the `nop' at the end is needed to keep the trap from
-     clobbering things (if NPC pointed to garbage instead).
- */
-
-#if !defined (GDB_MULTI_ARCH) || (GDB_MULTI_ARCH == 0)
-/*
- * The following defines must go away for MULTI_ARCH.
- */
-
-#define CALL_DUMMY { 0xbc100001, 0x9de38000, 0xbc100002, 0xbe100003,	\
-		     0xda03a058, 0xd803a054, 0xd603a050, 0xd403a04c,	\
-		     0xd203a048, 0x40000000, 0xd003a044, 0x01000000,	\
-		     0x91d02001, 0x01000000 }
-
-
-/* Size of the call dummy in bytes. */
-
-#define CALL_DUMMY_LENGTH 0x38
-
-/* Offset within call dummy of first instruction to execute. */
-
-#define CALL_DUMMY_START_OFFSET 0
-
-/* Offset within CALL_DUMMY of the 'call' instruction. */
-
-#define CALL_DUMMY_CALL_OFFSET (CALL_DUMMY_START_OFFSET + 0x24)
-
-/* Offset within CALL_DUMMY of the 'ta 1' trap instruction. */
-
-#define CALL_DUMMY_BREAKPOINT_OFFSET (CALL_DUMMY_START_OFFSET + 0x30)
-
-#define CALL_DUMMY_STACK_ADJUST 68
-
-/* Call dummy method (eg. on stack, at entry point, etc.) */
-
-#define CALL_DUMMY_LOCATION ON_STACK
-
-/* Method for detecting dummy frames.  */
-
-#define PC_IN_CALL_DUMMY(PC, SP, FRAME_ADDRESS) \
-     pc_in_call_dummy_on_stack (PC, SP, FRAME_ADDRESS)
-
-#endif /* GDB_MULTI_ARCH */
-
-#endif /* CALL_DUMMY */
-
-#if !defined (GDB_MULTI_ARCH) || (GDB_MULTI_ARCH == 0)
-/*
- * The following defines must go away for MULTI_ARCH. 
- */
-
-/* Insert the specified number of args and function address
-   into a call sequence of the above form stored at DUMMYNAME.  */
-
-#define FIX_CALL_DUMMY(DUMMYNAME, PC, FUN, NARGS, ARGS, TYPE, GCC_P) \
-     sparc_fix_call_dummy (DUMMYNAME, PC, FUN, TYPE, GCC_P)
-void sparc_fix_call_dummy (char *dummy, CORE_ADDR pc, CORE_ADDR fun,
-			   struct type *value_type, int using_gcc);
-
-/* Arguments smaller than an int must be promoted to ints when
-   synthesizing function calls.  */
-
-/* Push an empty stack frame, to record the current PC, etc.  */
-
-#define PUSH_DUMMY_FRAME	sparc_push_dummy_frame ()
-#define POP_FRAME		sparc_pop_frame ()
-
-void sparc_push_dummy_frame (void);
-void sparc_pop_frame (void);
-
-#define PUSH_ARGUMENTS(NARGS, ARGS, SP, STRUCT_RETURN, STRUCT_ADDR) \
-     sparc32_push_arguments (NARGS, ARGS, SP, STRUCT_RETURN, STRUCT_ADDR)
-
-extern CORE_ADDR
-sparc32_push_arguments (int, struct value **, CORE_ADDR, int, CORE_ADDR);
-
-/* Store the address of the place in which to copy the structure the
-   subroutine will return.  This is called from call_function_by_hand. 
-   The ultimate mystery is, tho, what is the value "16"?  */
-
-#define STORE_STRUCT_RETURN(ADDR, SP) \
-  { char val[4]; \
-    store_unsigned_integer (val, 4, (ADDR)); \
-    write_memory ((SP)+(16*4), val, 4); }
-
-/* Default definition of USE_STRUCT_CONVENTION.  */
-
-#ifndef USE_STRUCT_CONVENTION
-#define USE_STRUCT_CONVENTION(GCC_P, TYPE) \
-     generic_use_struct_convention (GCC_P, TYPE)
-#endif
-
-/* Extract from an array REGBUF containing the (raw) register state a
-   function return value of type TYPE, and copy that, in virtual
-   format, into VALBUF.  */
-
-#define EXTRACT_RETURN_VALUE(TYPE, REGBUF, VALBUF) \
-     sparc32_extract_return_value (TYPE, REGBUF, VALBUF)
-extern void sparc32_extract_return_value (struct type *, char[], char *);
-
-#endif /* GDB_MULTI_ARCH */
 
 \f
 /* Sparc has no reliable single step ptrace call */
--- ./config/sparc/tm-sparclet.h.~1~	Sun Apr 21 20:51:53 2002
+++ ./config/sparc/tm-sparclet.h	Mon Apr 22 00:13:18 2002
@@ -57,78 +57,6 @@ enum { 
 #define BIG_BREAKPOINT {0x91, 0xd0, 0x20, 0x01}
 #define LITTLE_BREAKPOINT {0x01, 0x20, 0xd0, 0x91}
 
-#if !defined (GDB_MULTI_ARCH) || (GDB_MULTI_ARCH == 0)
-/*
- * The following defines must go away for MULTI_ARCH.
- */
-
-#undef  NUM_REGS		/* formerly "72" */
-/*                WIN  FP   CPU  CCP  ASR  AWR  APSR */
-#define NUM_REGS (32 + 32 + 8  + 8  + 8/*+ 32 + 1*/)
-
-#undef  REGISTER_BYTES		/* formerly "(32*4 + 32*4 + 8*4)" */
-#define REGISTER_BYTES (32*4 + 32*4 + 8*4 + 8*4 + 8*4/* + 32*4 + 1*4*/)
-
-/* Initializer for an array of names of registers.
-   There should be NUM_REGS strings in this initializer.  */
-/* Sparclet has no fp! */
-/* Compiler maps types for floats by number, so can't 
-   change the numbers here. */
-
-#undef REGISTER_NAMES
-#define REGISTER_NAMES  \
-{ "g0", "g1", "g2", "g3", "g4", "g5", "g6", "g7",	\
-  "o0", "o1", "o2", "o3", "o4", "o5", "o6", "o7",	\
-  "l0", "l1", "l2", "l3", "l4", "l5", "l6", "l7",	\
-  "i0", "i1", "i2", "i3", "i4", "i5", "i6", "i7",	\
-							\
-  "", "", "", "", "", "", "", "", /* no FPU regs */	\
-  "", "", "", "", "", "", "", "", 			\
-  "", "", "", "", "", "", "", "", 			\
-  "", "", "", "", "", "", "", "", 			\
-				  /* no CPSR, FPSR */	\
-  "y", "psr", "wim", "tbr", "pc", "npc", "", "", 	\
-							\
-  "ccsr", "ccpr", "cccrcr", "ccor", "ccobr", "ccibr", "ccir", "", \
-								  \
-  /*       ASR15                 ASR19 (don't display them) */    \
-  "asr1",  "", "asr17", "asr18", "", "asr20", "asr21", "asr22",   \
-/*									  \
-  "awr0",  "awr1",  "awr2",  "awr3",  "awr4",  "awr5",  "awr6",  "awr7",  \
-  "awr8",  "awr9",  "awr10", "awr11", "awr12", "awr13", "awr14", "awr15", \
-  "awr16", "awr17", "awr18", "awr19", "awr20", "awr21", "awr22", "awr23", \
-  "awr24", "awr25", "awr26", "awr27", "awr28", "awr29", "awr30", "awr31", \
-  "apsr",								  \
- */									  \
-}
-
-/* Remove FP dependant code which was defined in tm-sparc.h */
-#undef	FP0_REGNUM		/* Floating point register 0 */
-#undef  FPS_REGNUM		/* Floating point status register */
-#undef 	CPS_REGNUM		/* Coprocessor status register */
-
-/* sparclet register numbers */
-#define CCSR_REGNUM 72
-
-#undef EXTRACT_RETURN_VALUE
-#define EXTRACT_RETURN_VALUE(TYPE,REGBUF,VALBUF)                       \
-  {                                                                    \
-    memcpy ((VALBUF),                                                  \
-	    (char *)(REGBUF) + REGISTER_RAW_SIZE (O0_REGNUM) * 8 +     \
-	    (TYPE_LENGTH(TYPE) >= REGISTER_RAW_SIZE (O0_REGNUM)        \
-	     ? 0 : REGISTER_RAW_SIZE (O0_REGNUM) - TYPE_LENGTH(TYPE)), \
-	    TYPE_LENGTH(TYPE));                                        \
-  }
-#undef STORE_RETURN_VALUE
-#define STORE_RETURN_VALUE(TYPE,VALBUF) \
-  {                                                                    \
-    /* Other values are returned in register %o0.  */                  \
-    write_register_bytes (REGISTER_BYTE (O0_REGNUM), (VALBUF),         \
-			  TYPE_LENGTH (TYPE));                         \
-  }
-
-#endif /* GDB_MULTI_ARCH */
-
 #undef PRINT_REGISTER_HOOK
 #define PRINT_REGISTER_HOOK(regno)
 
--- ./config/sparc/tm-sparclite.h.~1~	Sun Apr 21 20:52:02 2002
+++ ./config/sparc/tm-sparclite.h	Mon Apr 22 00:13:44 2002
@@ -60,46 +60,6 @@ enum {
 
 #define DECR_PC_AFTER_HW_BREAK 4
 
-#if !defined (GDB_MULTI_ARCH) || (GDB_MULTI_ARCH == 0)
-/*
- * The following defines must go away for MULTI_ARCH.
- */
-
-#undef  FRAME_CHAIN_VALID
-#define FRAME_CHAIN_VALID(FP,FI) func_frame_chain_valid (FP, FI)
-
-#undef NUM_REGS
-#define NUM_REGS 80
-
-#undef REGISTER_BYTES
-#define REGISTER_BYTES (32*4+32*4+8*4+8*4)
-
-#undef REGISTER_NAMES
-#define REGISTER_NAMES  \
-{ "g0", "g1", "g2", "g3", "g4", "g5", "g6", "g7",       \
-  "o0", "o1", "o2", "o3", "o4", "o5", "sp", "o7",       \
-  "l0", "l1", "l2", "l3", "l4", "l5", "l6", "l7",       \
-  "i0", "i1", "i2", "i3", "i4", "i5", "fp", "i7",       \
-                                                                \
-  "f0", "f1", "f2", "f3", "f4", "f5", "f6", "f7",       \
-  "f8", "f9", "f10", "f11", "f12", "f13", "f14", "f15", \
-  "f16", "f17", "f18", "f19", "f20", "f21", "f22", "f23",       \
-  "f24", "f25", "f26", "f27", "f28", "f29", "f30", "f31",       \
-                                                                \
-  "y", "psr", "wim", "tbr", "pc", "npc", "fpsr", "cpsr",        \
-  "dia1", "dia2", "dda1", "dda2", "ddv1", "ddv2", "dcr", "dsr" }
-
-#define DIA1_REGNUM 72		/* debug instr address register 1 */
-#define DIA2_REGNUM 73		/* debug instr address register 2 */
-#define DDA1_REGNUM 74		/* debug data address register 1 */
-#define DDA2_REGNUM 75		/* debug data address register 2 */
-#define DDV1_REGNUM 76		/* debug data value register 1 */
-#define DDV2_REGNUM 77		/* debug data value register 2 */
-#define DCR_REGNUM 78		/* debug control register */
-#define DSR_REGNUM 79		/* debug status regsiter */
-
-#endif /* GDB_MULTI_ARCH */
-
 #define TARGET_HW_BREAK_LIMIT 2
 #define TARGET_HW_WATCH_LIMIT 2
 
--- ./sparc-tdep.c.~1~	Sun Apr 21 20:48:04 2002
+++ ./sparc-tdep.c	Mon Apr 22 00:10:26 2002
@@ -44,12 +44,6 @@
 
 #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: */
@@ -60,46 +54,9 @@
 #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 */
+/* Offset within the call dummy sequence of the call instruction.  */
+#define CALL_DUMMY_CALL_OFFSET \
+     (gdbarch_tdep (current_gdbarch)->call_dummy_call_offset)
 
 struct gdbarch_tdep
   {
@@ -2140,11 +2097,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.
 
@@ -2912,6 +2864,30 @@ sparc_gdbarch_init (struct gdbarch_info 
   struct gdbarch *gdbarch;
   struct gdbarch_tdep *tdep;
 
+/* This sequence of words is the instructions
+
+   00:   bc 10 00 01     mov  %g1, %fp
+   04:   9d e3 80 00     save  %sp, %g0, %sp
+   08:   bc 10 00 02     mov  %g2, %fp
+   0c:   be 10 00 03     mov  %g3, %i7
+   10:   da 03 a0 58     ld  [ %sp + 0x58 ], %o5
+   14:   d8 03 a0 54     ld  [ %sp + 0x54 ], %o4
+   18:   d6 03 a0 50     ld  [ %sp + 0x50 ], %o3
+   1c:   d4 03 a0 4c     ld  [ %sp + 0x4c ], %o2
+   20:   d2 03 a0 48     ld  [ %sp + 0x48 ], %o1
+   24:   40 00 00 00     call  <fun>
+   28:   d0 03 a0 44     ld  [ %sp + 0x44 ], %o0
+   2c:   01 00 00 00     nop 
+   30:   91 d0 20 01     ta  1
+   34:   01 00 00 00     nop
+
+   NOTES:
+   * the first four instructions are necessary only on the simulator.
+   * this is a multiple of 8 (not only 4) bytes.
+   * the `call' insn is a relative, not an absolute call.
+   * the `nop' at the end is needed to keep the trap from
+     clobbering things (if NPC pointed to garbage instead).
+ */
   static LONGEST call_dummy_32[] = 
     { 0xbc100001, 0x9de38000, 0xbc100002, 0xbe100003,
       0xda03a058, 0xd803a054, 0xd603a050, 0xd403a04c,

Re: which patches to review

[Andrew Cagney]

David, to (possibly re-iterate) some previous suggestions:

> If you post a new patch, start a new thread.
> If you superseed a patch, clearly withdraw the old patch.

This makes life easier for everyone and is accepted pratice on this list.

enjoy,
Andrew

Re: which patches to review

[Andrew Cagney]

>  From: Andrew Cagney <ac131313@cygnus.com>
> Date: Wed, 24 Apr 2002 13:15:57 -0400
> 
>    Here, you're mistaken.
>    
> He isn't %100 wrong.  I've been asked repeatedly to basically
> multi-arch the Sparc targets out the wazoo to get the Linux
> Sparc bits in.

One of GDB's overriding objectives it to get everything multi-arch.  To 
that end:

Post 5.0, every new architecture has to be mult-arched
Post 5.1, every addition to an existing architecture has to be mult-arch 
enabled

As acceptence criteria, they are simple and transparent.  I don't think 
me stiching up some sort of cosy deal where you were some how excempted 
from this would go down very well :-)

Andrew

Re: which patches to review

[cgd]

At Thu, 25 Apr 2002 14:04:30 +0000 (UTC), "Andrew Cagney" wrote:
> David, to (possibly re-iterate) some previous suggestions:
> 
> > If you post a new patch, start a new thread.
> > If you superseed a patch, clearly withdraw the old patch.
> 
> This makes life easier for everyone and is accepted pratice on this list.

My personal practice, which i've found helpful in the past, is to keep
a list of patches i've submitted, keep track of their status, and
occasionally send a ping msg containing the list of unreviewed patches
that have gone "too long" w/o approval or rejection.

Like it or not, even in the best circumstances things _do_ get lost,
dropped, overlooked, or otherwise ignored occasionally.  That's
especially true when volunteers are doing the reviewing, and the
volunteers are busy.

I've found that it also helps me keep track of my own outstanding
patches when _I_ get really busy and distracted for a month at a
time...  8-)


(my personal cutoff for 'too long' tends to be '2 weeks to a month, or
whenever after a longer period i remember to look at my outstanding
patches page.'  8-)


chris

Re: which patches to review

[David S. Miller]

   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Thu, 25 Apr 2002 10:32:29 -0400

   One of GDB's overriding objectives it to get everything multi-arch.  To 
   that end:
   
   Post 5.0, every new architecture has to be mult-arched
   Post 5.1, every addition to an existing architecture has to be mult-arch 
   enabled
   
   As acceptence criteria, they are simple and transparent.  I don't think 
   me stiching up some sort of cosy deal where you were some how excempted 
   from this would go down very well :-)
   
I think that is an unreasonable requirement and it will serve often to
deter new contributors.  Because they will come here trying to
contribute support for a new platform, and they will do so on the
evaluation that they have the time to merge just that addition.
This means they think they have time to submit the addition and tweak
a thing or two to make the patch acceptable.

Unlike me, they won't have weeks upon weeks of spare time available to
multiarch the cpu target in question.

I believe this was a bad decision and it is not the only way the GDB
team could have obtained their goal of getting things multi-arched.

Re: which patches to review

[Daniel Jacobowitz]

On Thu, Apr 25, 2002 at 10:32:29AM -0400, Andrew Cagney wrote:
> > From: Andrew Cagney <ac131313@cygnus.com>
> >Date: Wed, 24 Apr 2002 13:15:57 -0400
> >
> >   Here, you're mistaken.
> >   
> >He isn't %100 wrong.  I've been asked repeatedly to basically
> >multi-arch the Sparc targets out the wazoo to get the Linux
> >Sparc bits in.
> 
> One of GDB's overriding objectives it to get everything multi-arch.  To 
> that end:
> 
> Post 5.0, every new architecture has to be mult-arched
> Post 5.1, every addition to an existing architecture has to be mult-arch 
> enabled
> 
> As acceptence criteria, they are simple and transparent.  I don't think 
> me stiching up some sort of cosy deal where you were some how excempted 
> from this would go down very well :-)

Again with due respect, I've got to object to the point of view in this
message.  I wouldn't say that becoming multi-arch is "one of GDB's
overriding objectives".  It's something that we all agree would be good
for GDB; it's something that I agree with you should happen before our
next release, which is not scheduled for at least four months IIRC. 
But if it is an "overriding objective", it's only so for you.  My
overriding objective is for GDB to improve.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: which patches to review

[Christopher Faylor]

On Thu, Apr 25, 2002 at 09:13:24PM -0400, Daniel Jacobowitz wrote:
>On Thu, Apr 25, 2002 at 10:32:29AM -0400, Andrew Cagney wrote:
>> > From: Andrew Cagney <ac131313@cygnus.com>
>> >Date: Wed, 24 Apr 2002 13:15:57 -0400
>> >
>> >   Here, you're mistaken.
>> >   
>> >He isn't %100 wrong.  I've been asked repeatedly to basically
>> >multi-arch the Sparc targets out the wazoo to get the Linux
>> >Sparc bits in.
>> 
>> One of GDB's overriding objectives it to get everything multi-arch.  To 
>> that end:
>> 
>> Post 5.0, every new architecture has to be mult-arched
>> Post 5.1, every addition to an existing architecture has to be mult-arch 
>> enabled
>> 
>> As acceptence criteria, they are simple and transparent.  I don't think 
>> me stiching up some sort of cosy deal where you were some how excempted 
>> from this would go down very well :-)
>
>Again with due respect, I've got to object to the point of view in this
>message.  I wouldn't say that becoming multi-arch is "one of GDB's
>overriding objectives".  It's something that we all agree would be good
>for GDB; it's something that I agree with you should happen before our
>next release, which is not scheduled for at least four months IIRC. 
>But if it is an "overriding objective", it's only so for you.  My
>overriding objective is for GDB to improve.

Hmm.  I was under the impression that 1) Andrew was the head maintainer
for gdb and, so, got to specify little things like "overriding
directions" for gdb, and 2) multiarching targets was an improvement.

cgf

Re: which patches to review

[Daniel Jacobowitz]

On Thu, Apr 25, 2002 at 09:36:11PM -0400, Christopher Faylor wrote:
> On Thu, Apr 25, 2002 at 09:13:24PM -0400, Daniel Jacobowitz wrote:
> >On Thu, Apr 25, 2002 at 10:32:29AM -0400, Andrew Cagney wrote:
> >> > From: Andrew Cagney <ac131313@cygnus.com>
> >> >Date: Wed, 24 Apr 2002 13:15:57 -0400
> >> >
> >> >   Here, you're mistaken.
> >> >   
> >> >He isn't %100 wrong.  I've been asked repeatedly to basically
> >> >multi-arch the Sparc targets out the wazoo to get the Linux
> >> >Sparc bits in.
> >> 
> >> One of GDB's overriding objectives it to get everything multi-arch.  To 
> >> that end:
> >> 
> >> Post 5.0, every new architecture has to be mult-arched
> >> Post 5.1, every addition to an existing architecture has to be mult-arch 
> >> enabled
> >> 
> >> As acceptence criteria, they are simple and transparent.  I don't think 
> >> me stiching up some sort of cosy deal where you were some how excempted 
> >> from this would go down very well :-)
> >
> >Again with due respect, I've got to object to the point of view in this
> >message.  I wouldn't say that becoming multi-arch is "one of GDB's
> >overriding objectives".  It's something that we all agree would be good
> >for GDB; it's something that I agree with you should happen before our
> >next release, which is not scheduled for at least four months IIRC. 
> >But if it is an "overriding objective", it's only so for you.  My
> >overriding objective is for GDB to improve.
> 
> Hmm.  I was under the impression that 1) Andrew was the head maintainer
> for gdb

If so, this isn't said anywhere.  It certainly may be true; all I know
is that he's a blanket write maintainer and the release manager for the
last several releases.  If the GDB projects has a single head
maintainer, perhaps that should be listed in gdb/MAINTAINERS somewhere?

>         and, so, got to specify little things like "overriding
> directions" for gdb, and 

To the extent of excluding large contributions that don't seem to
conflict in any substantial way with his design improvements?

>                           2) multiarching targets was an improvement.

Sure it is.  So are David's SPARC/Linux patches, and they're a much
more concrete one to users.  I was just objecting to the one
"obviously" trumping with the other.

I'm going to shut up now; I've no desire for a protacted argument and
I've foolishly walked into the middle of one.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: which patches to review

[Christopher Faylor]

On Thu, Apr 25, 2002 at 09:45:51PM -0400, Daniel Jacobowitz wrote:
>>Hmm.  I was under the impression that 1) Andrew was the head maintainer
>>for gdb
>
>If so, this isn't said anywhere.  It certainly may be true; all I know
>is that he's a blanket write maintainer and the release manager for the
>last several releases.  If the GDB projects has a single head
>maintainer, perhaps that should be listed in gdb/MAINTAINERS somewhere?

It's true.  Maybe "head maintainer" is the wrong word.  I don't know what
the correct PC term is.

You're correct, however, in saying that this isn't mentioned anywhere
obvious.  I agree that should be corrected.

Maybe we should make a new hard rule that no further changes to
MAINTAINERS will be accepted until this oversight is corrected.  :-)

>I'm going to shut up now; I've no desire for a protacted argument and
>I've foolishly walked into the middle of one.

Ditto on both counts.

cgf

Re: which patches to review

[Andrew Cagney]

> As acceptence criteria, they are simple and transparent.  I don't think 
>> me stiching up some sort of cosy deal where you were some how excempted 
>> from this would go down very well :-)
> 
> 
> Again with due respect, I've got to object to the point of view in this
> message.  I wouldn't say that becoming multi-arch is "one of GDB's
> overriding objectives".  It's something that we all agree would be good
> for GDB; it's something that I agree with you should happen before our
> next release, which is not scheduled for at least four months IIRC. 
> But if it is an "overriding objective", it's only so for you.  My
> overriding objective is for GDB to improve.

The overall objective is obviously to make GDB better.  To that end, 
longer term objectives sometimes need to override more immediate ones. 
I consider multi-arch to be one such objective.

enjoy,
Andrew

PS: The hypothetical 6.0 is two releases away - ~nov-dec.

Re: which patches to review

[Andrew Cagney]

> I think that is an unreasonable requirement and it will serve often to
> deter new contributors.  Because they will come here trying to
> contribute support for a new platform, and they will do so on the
> evaluation that they have the time to merge just that addition.
> This means they think they have time to submit the addition and tweak
> a thing or two to make the patch acceptable.
> 
> Unlike me, they won't have weeks upon weeks of spare time available to
> multiarch the cpu target in question.
> 
> I believe this was a bad decision and it is not the only way the GDB
> team could have obtained their goal of getting things multi-arched.

``weeks upon weeks of spare time''!  Yes, love it!

Andrew

Re: which patches to review

[Andrew Cagney]

> On Thu, Apr 25, 2002 at 09:45:51PM -0400, Daniel Jacobowitz wrote:
> 
>>>Hmm.  I was under the impression that 1) Andrew was the head maintainer
>>>for gdb
> 
>>
>>If so, this isn't said anywhere.  It certainly may be true; all I know
>>is that he's a blanket write maintainer and the release manager for the
>>last several releases.  If the GDB projects has a single head
>>maintainer, perhaps that should be listed in gdb/MAINTAINERS somewhere?
> 
> 
> It's true.  Maybe "head maintainer" is the wrong word.  I don't know what
> the correct PC term is.

The PC term is GDB Adminstrator.  The details are all in the mail archives.

> You're correct, however, in saying that this isn't mentioned anywhere
> obvious.  I agree that should be corrected.
> 
> Maybe we should make a new hard rule that no further changes to
> MAINTAINERS will be accepted until this oversight is corrected.  :-)

I don't see a reason to identify one global write maintainer as being 
different to any other.

Andrew

Re: which patches to review

[Daniel Jacobowitz]

On Thu, Apr 25, 2002 at 11:17:44PM -0400, Andrew Cagney wrote:
> PS: The hypothetical 6.0 is two releases away - ~nov-dec.

Oh, thanks.  That makes more sense with what I remember.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: which patches to review

[Stan Shebs]

Daniel Jacobowitz wrote:
> 
> On Thu, Apr 25, 2002 at 09:36:11PM -0400, Christopher Faylor wrote:
> >
> > Hmm.  I was under the impression that 1) Andrew was the head maintainer
> > for gdb
> 
> If so, this isn't said anywhere.  It certainly may be true; all I know
> is that he's a blanket write maintainer and the release manager for the
> last several releases.  If the GDB projects has a single head
> maintainer, perhaps that should be listed in gdb/MAINTAINERS somewhere?

The old situation was that from the point of view of the FSF, I
was the sole maintainer, and that everybody else was at most
"helpers" (I kid you not).  After the formation of the GDB
Steering Committee - which was never announced by RMS like he
was supposed to - I proposed to the committee that I retire
as maintainer, but that we retain the concept of a single
head or chief maintainer, mainly to avoid the evils of committee
indecisiveness, and that Andrew be that chief maintainer.
There was basically no reaction either positive or negative, not
exactly a ringing endorsement, but certainly justifying my
concern about the decisionmaking abilities of committees! :-)

So we've proceeded on that basis "unofficially" since then, and it
seems to have worked well enough.  You're right that it ought to
be documented; I can do it if the head maintainer is shy about
taking the crown and putting it on his own head. :-)

Stan