Re: [RFA] fix child_xfer_memory in hppah-nat.c

[Eli Zaretskii <eliz@delorie.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 25398 bytes --]

> Date: Mon, 5 Feb 2001 13:18:14 -0500
> From: Christopher Faylor <cgf@redhat.com>
> 
> Here are the lines from configure.in:
> 
>     # NOTE: Don't add -Wall or -Wunused, they both include
>     # -Wunused-parameter which reports bogus warnings.
> 
> The TODO has some words, too:
> 
>     Frequently requested but not approved requests.
> 
>     --
> 
>     Eliminate unused argument warnings using ATTRIBUTE_UNUSED.
> 
>     The benefits on this one are thought to be marginal - GDBs design
>     means that unused parameters are very common.  GCC 3.0 will also
>     include the option -Wno-unused-parameter which means that ``-Wall
>     -Wno-unused-parameters -Werror'' can be specified.
> 
> 
> >Several files in the CVS use ATTRIBUTE_UNUSED (not surprisingly, 
> >go32-nat.c is one of them ;-).  So I wonder what is the current say-so 
> >on this matter.
> 
> I specifically added some of these to win32-nat.c, too, not too long ago.
> I do remember the discussion now.  I can't say that I agree with it,
> but I remember it.
> 
> It looks like at least one discussion is here:
> 
> http://sources.redhat.com/ml/gdb/2000-q1/msg00826.html

Thanks for the pointers.

However, after reading those, I'm still unsure what, if anything,
should I do with ATTRIBUTE_UNUSED in files I'm responsible for.

The TODO snippet seems to say that ATTRIBUTE_UNUSED should be deleted,
and we should endure the warnings until GCC 3.0 conquers the face of
Earth.  The discussion you pointed to seems to say the same, albeit
differently: it tells that GCC options should be changed to avoid
triggering the warnings which require ATTRIBUTE_UNUSED.

I remember that I added ATTRIBUTE_UNUSED to stop those warnings from
popping up and obscuring the real warnings (such as the one about the
missing mem_attrib parameter in go32_xfer_memory that I fixed the
other day).  I also set up a special set of compiler switches (in
gdb/config/djgpp/djconfig.sh) to make sure these warnings don't
return.  But to remove ATTRIBUTE_UNUSED from the sources we need a
more safe assumption to bet on...

Andrew?
From eliz@delorie.com Tue Feb 06 08:38:00 2001
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: gdb-patches@sourceware.cygnus.com, fpastor.etra-id@etra.es
Subject: Re: [PATCH]: Fix ser-go32.c for UARTs with FIFOs.
Date: Tue, 06 Feb 2001 08:38:00 -0000
Message-id: <200102061638.LAA08744@indy.delorie.com>
References: <Pine.SUN.3.91.1010204094707.20547Q-100000@is> <3A7F6BCF.605B1D7F@cygnus.com>
X-SW-Source: 2001-02/msg00076.html
Content-length: 1082

> Date: Mon, 05 Feb 2001 19:13:19 -0800
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> Eli Zaretskii wrote:
> > 
> > FYI: I committed today the following patch:
> > 
> > 2001-02-04  Eli Zaretskii  <eliz@is.elta.co.il>
> > 
> >         * ser-go32.c (dos_write) [UART_FIFO_WORKS]: Use outportsb only if
> >         UART_FIFO_WORKS is defined.  Otherwise use outportb.
> >         From Francisco Pastor <fpastor.etra-id@etra.es>
> 
> Eli, would it be better to make this a run-time option?

You mean, introduce a new interactive command, or an option for an
existing command?

If you think this would be a good idea, I'll put that on my todo (I
have a few much more important issues to deal with, such as the
unified handling of hardware-assisted watchpoints and breakpoints for
x86, which I promised a long time ago, as well as a few bugs).

It didn't seem to me as a grave problem to make this a compile-time
option because I don't think the speed we gain by using OUTS vs OUT is
significant.  (I also cannot test this code on my machine, since I
don't have a serial link set up.)
From ac131313@cygnus.com Tue Feb 06 11:06:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Eli Zaretskii <eliz@is.elta.co.il>
Cc: cgf@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [RFA] fix child_xfer_memory in hppah-nat.c
Date: Tue, 06 Feb 2001 11:06:00 -0000
Message-id: <3A804A32.D816139E@cygnus.com>
References: <3A7DCAB6.333C1DE0@cygnus.com> <Pine.SUN.3.91.1010205110800.5862G-100000@is> <20010205131813.A734@redhat.com> <200102061637.LAA08729@indy.delorie.com>
X-SW-Source: 2001-02/msg00077.html
Content-length: 1603

Eli Zaretskii wrote:
> 
> > Date: Mon, 5 Feb 2001 13:18:14 -0500
> > From: Christopher Faylor <cgf@redhat.com>
> >
> > Here are the lines from configure.in:
> >
> >     # NOTE: Don't add -Wall or -Wunused, they both include
> >     # -Wunused-parameter which reports bogus warnings.
> >
> > The TODO has some words, too:
> >
> >     Frequently requested but not approved requests.
> >
> >     --
> >
> >     Eliminate unused argument warnings using ATTRIBUTE_UNUSED.
> >
> >     The benefits on this one are thought to be marginal - GDBs design
> >     means that unused parameters are very common.  GCC 3.0 will also
> >     include the option -Wno-unused-parameter which means that ``-Wall
> >     -Wno-unused-parameters -Werror'' can be specified.
> >
> >
> > >Several files in the CVS use ATTRIBUTE_UNUSED (not surprisingly,
> > >go32-nat.c is one of them ;-).  So I wonder what is the current say-so
> > >on this matter.
> >
> > I specifically added some of these to win32-nat.c, too, not too long ago.
> > I do remember the discussion now.  I can't say that I agree with it,
> > but I remember it.
> >
> > It looks like at least one discussion is here:
> >
> > http://sources.redhat.com/ml/gdb/2000-q1/msg00826.html
> 
> Thanks for the pointers.
> 
> However, after reading those, I'm still unsure what, if anything,
> should I do with ATTRIBUTE_UNUSED in files I'm responsible for.

Nothing! You've plenty of other things to do above and beyond worrying
about them.  Just don't be suprised if someone some day submits a patch
to eliminate them (like chris just did for a bunch of PTRs).

	Andrew
From taylor@cygnus.com Tue Feb 06 11:15:00 2001
From: David Taylor <taylor@cygnus.com>
To: gdb-patches@sourceware.cygnus.com
Subject: [RFA] parse_frame_specification (stack.c)
Date: Tue, 06 Feb 2001 11:15:00 -0000
Message-id: <200102061915.OAA00445@texas.cygnus.com>
X-SW-Source: 2001-02/msg00079.html
Content-length: 2053

In gdb, if you say:

    "frame <small-number>"
or
    "info frame <small-number>"

then you expect to either move up or down some number of frames or to
get information on the frame having the specified "index".

But, if for your gdb target, addresses and pointers are different,
then the current code in parse_frame_specification will treat the
number as a pointer and convert it to an address.

So, if you have a Harvard architecture processor where a pointer of 0
(say) corresponds to a text address of 0x2000000 and a data address of
0x1000000, and you say

    frame 0

then gdb will try to move to frame 0x1000000.

Assuming you don't have that many frames, it will then try to create a
frame at address 0x1000000.  Which, in my case, will generate an
error...

This fixes it so that

    frame 0

will do the right thing on such configurations.

ChangeLog entry:

	* stack.c (parse_frame_specification): For one argument case,
 	handle the situation where the argument is an integer, not an
 	address -- arguably the most common case.  This matters on
	targets where pointers and addresses are different.

Index: stack.c
===================================================================
RCS file: /cvs/src/src/gdb/stack.c,v
retrieving revision 1.11
diff -c -r1.11 stack.c
*** stack.c	2001/01/27 17:57:53	1.11
--- stack.c	2001/02/06 19:01:15
***************
*** 722,727 ****
--- 722,728 ----
    int numargs = 0;
  #define	MAXARGS	4
    CORE_ADDR args[MAXARGS];
+   int level;
  
    if (frame_exp)
      {
***************
*** 742,747 ****
--- 743,752 ----
  
  	  {
  	    tmp_cleanup = make_cleanup (xfree, addr_string);
+ 
+ 	    if (numargs == 0)
+ 	      level = parse_and_eval_long (addr_string);
+ 
  	    args[numargs++] = parse_and_eval_address (addr_string);
  	    do_cleanups (tmp_cleanup);
  	  }
***************
*** 762,768 ****
        /* NOTREACHED */
      case 1:
        {
- 	int level = args[0];
  	struct frame_info *fid =
  	find_relative_frame (get_current_frame (), &level);
  	struct frame_info *tfid;
--- 767,772 ----
From ac131313@cygnus.com Tue Feb 06 11:15:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Francisco Pastor <fpastor.etra-id@etra.es>
Cc: Eli Zaretskii <eliz@is.elta.co.il>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: Fix ser-go32.c for UARTs with FIFOs.
Date: Tue, 06 Feb 2001 11:15:00 -0000
Message-id: <3A804C5F.9F2B6D84@cygnus.com>
References: <Pine.SUN.3.91.1010204094707.20547Q-100000@is> <3A7F6BCF.605B1D7F@cygnus.com> <6137-Tue06Feb2001105337+0200-eliz@is.elta.co.il> <004f01c09034$e7aa2300$0500a8c0@etra.es>
X-SW-Source: 2001-02/msg00078.html
Content-length: 650

Francisco Pastor wrote:

> The problem with OUTS only happen with NT DOS console, not with true DOS
> 6.22. So, I think that a general solution is leave the patch with a compile
> time option or, perhaps, test the DOS version for avoid the use of OUTS. I
> don´t think that introduce a new interactive command be a good solution.

I've been assuming that a single DJGPP-GDB binary can run on all dos
platforms (6.22, NT, ...).  If that is the case then the serial
configury should be run-time configurable.  If that isn't the case then
a compile time flag is ok.

I suspect this will go onto Eli's very long to do one day list :-)

	enjoy,
		Andrew
From msnyder@cygnus.com Tue Feb 06 11:17:00 2001
From: Michael Snyder <msnyder@cygnus.com>
To: gary37@seed.net.tw
Cc: gdb-patches@sourceware.cygnus.com
Subject: Re: gdbserver arm-linux support?
Date: Tue, 06 Feb 2001 11:17:00 -0000
Message-id: <3A804DE9.962848E@cygnus.com>
References: <E14Pykg-00023g-00@fwm2.seed.net.tw>
X-SW-Source: 2001-02/msg00080.html
Content-length: 1015

gary37@seed.net.tw wrote:
> 
> Hi all,
> 
> I know this question has been asked before in this list
> but I got gdb 20001208 source and tried to apply the
> patches floating around here before. I can not successfully
> apply the patches into source tree. I tried to do it
> manually but found the source seems to be changed since.
> So, I fumbled the code a little and finally got the
> arm-linux gdbserver built ok.
> 
> But, when I am on a x86 host run gdb and arm client runs
> gdbserver, the connection seems to be up, but while I
> simply want to run the debugged program at host, it told
> me "don't know how to run", and the client gdbserver shows
> "killing the inferior ..." and dies.

When you use "target remote", you do not say "run".
You say "continue".  Just imagine that when you initially
connect, the process already exists and the PC is stopped
at the start address.

Try that, anyway, and see if it works.  Something like:
	(gdb) target remote foo
	(gdb) break main
	(gdb) continue

HTH,
Michael
From jtc@redback.com Tue Feb 06 11:44:00 2001
From: jtc@redback.com (J.T. Conklin)
To: Andrew Cagney <ac131313@cygnus.com>
Cc: Francisco Pastor <fpastor.etra-id@etra.es>, Eli Zaretskii <eliz@is.elta.co.il>, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: Fix ser-go32.c for UARTs with FIFOs.
Date: Tue, 06 Feb 2001 11:44:00 -0000
Message-id: <5mitmnsik8.fsf@jtc.redback.com>
References: <Pine.SUN.3.91.1010204094707.20547Q-100000@is> <3A7F6BCF.605B1D7F@cygnus.com> <6137-Tue06Feb2001105337+0200-eliz@is.elta.co.il> <004f01c09034$e7aa2300$0500a8c0@etra.es> <3A804C5F.9F2B6D84@cygnus.com>
X-SW-Source: 2001-02/msg00081.html
Content-length: 1112

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
Andrew> Francisco Pastor wrote:
>> The problem with OUTS only happen with NT DOS console, not with true DOS
>> 6.22. So, I think that a general solution is leave the patch with a compile
>> time option or, perhaps, test the DOS version for avoid the use of OUTS. I
>> don´t think that introduce a new interactive command be a good solution.

Andrew> I've been assuming that a single DJGPP-GDB binary can run on
Andrew> all dos platforms (6.22, NT, ...).  If that is the case then
Andrew> the serial configury should be run-time configurable.  If that
Andrew> isn't the case then a compile time flag is ok.
Andrew>
Andrew> I suspect this will go onto Eli's very long to do one day list :-)

Eli mentioned that he didn't think the speed gain from using OUTS 
vs. OUT was significant.  If that is really the case, why not use 
the conservative approach and always use OUT?  If there isn't a 
win, I can't see the value of having knobs to tweak the implement-
ation, either at compile time or run time.

        --jtc

-- 
J.T. Conklin
RedBack Networks
From eliz@delorie.com Tue Feb 06 11:50:00 2001
From: Eli Zaretskii <eliz@delorie.com>
To: ac131313@cygnus.com
Cc: fpastor.etra-id@etra.es, gdb-patches@sourceware.cygnus.com
Subject: Re: [PATCH]: Fix ser-go32.c for UARTs with FIFOs.
Date: Tue, 06 Feb 2001 11:50:00 -0000
Message-id: <200102061950.OAA13398@indy.delorie.com>
References: <Pine.SUN.3.91.1010204094707.20547Q-100000@is> <3A7F6BCF.605B1D7F@cygnus.com> <6137-Tue06Feb2001105337+0200-eliz@is.elta.co.il> <004f01c09034$e7aa2300$0500a8c0@etra.es> <3A804C5F.9F2B6D84@cygnus.com>
X-SW-Source: 2001-02/msg00082.html
Content-length: 766

> Date: Tue, 06 Feb 2001 11:11:27 -0800
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> Francisco Pastor wrote:
> 
> > The problem with OUTS only happen with NT DOS console, not with true DOS
> > 6.22. So, I think that a general solution is leave the patch with a compile
> > time option or, perhaps, test the DOS version for avoid the use of OUTS. I
> > don't think that introduce a new interactive command be a good solution.
> 
> I've been assuming that a single DJGPP-GDB binary can run on all dos
> platforms (6.22, NT, ...).

This is true.  DJGPP programs run on MS-DOS, all versions of
MS-Windows, and any other environment that has some kind of ``DOS
Box'' (OS/2, DOSEmu, etc.)

> I suspect this will go onto Eli's very long to do one day list :-)

Yes ;-)
From msnyder@cygnus.com Tue Feb 06 12:03:00 2001
From: Michael Snyder <msnyder@cygnus.com>
To: gdb-patches@sources.redhat.com
Cc: hilfingr@gnat.com
Subject: [PATCH]: Allow compilation by Sun cc
Date: Tue, 06 Feb 2001 12:03:00 -0000
Message-id: <3A8058A8.5DE5CC35@cygnus.com>
X-SW-Source: 2001-02/msg00083.html
Content-length: 10483

I've checked in this portion of Paul Hilfinger's patch for compiling with Sun cc.

2001-02-06  Michael Snyder  <msnyder@makita.cygnus.com>
        Submitted by Paul Hilfinger (hilfingr@gnat.com) 
        and Andrei Petrov (and@genesyslab.com).
        * findvar.c: Buffers of size MAX_REGISTER_RAW_SIZE or REGISTER_BYTES
        must be allocated dynamically, since these are no longer constants.
        * infcmd.c: Ditto.
        * regcache.c: Ditto.
        * remote.c: Ditto.
        * sol-thread.c: Ditto.
        * valops.c: Ditto.
        * config/sparc/sun4sol2.mh (MH_CFLAGS): Add -I/usr/include/v9, as a
        work-around for a missing Sun header file in solaris for sparc64.

Index: gdb/findvar.c
===================================================================
RCS file: /cvs/src/src/gdb/findvar.c,v
retrieving revision 1.15
diff -c -3 -p -r1.15 findvar.c
*** findvar.c   2000/07/30 01:48:25     1.15
--- findvar.c   2001/02/06 19:52:57
*************** value_of_register (int regnum)
*** 393,399 ****
    CORE_ADDR addr;
    int optim;
    register value_ptr reg_val;
!   char raw_buffer[MAX_REGISTER_RAW_SIZE];
    enum lval_type lval;
  
    get_saved_register (raw_buffer, &optim, &addr,
--- 393,399 ----
    CORE_ADDR addr;
    int optim;
    register value_ptr reg_val;
!   char *raw_buffer = (char*) alloca (MAX_REGISTER_RAW_SIZE);
    enum lval_type lval;
  
    get_saved_register (raw_buffer, &optim, &addr,
*************** addresses have not been bound by the dyn
*** 606,612 ****
      case LOC_BASEREG:
      case LOC_BASEREG_ARG:
        {
!       char buf[MAX_REGISTER_RAW_SIZE];
        get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG (var),
                            NULL);
        addr = extract_address (buf, REGISTER_RAW_SIZE (SYMBOL_BASEREG (var)));
--- 606,612 ----
      case LOC_BASEREG:
      case LOC_BASEREG_ARG:
        {
!       char *buf = (char*) alloca (MAX_REGISTER_RAW_SIZE);
        get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG (var),
                            NULL);
        addr = extract_address (buf, REGISTER_RAW_SIZE (SYMBOL_BASEREG (var)));
*************** addresses have not been bound by the dyn
*** 616,622 ****
  
      case LOC_THREAD_LOCAL_STATIC:
        {
!       char buf[MAX_REGISTER_RAW_SIZE];
  
        get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG (var),
                            NULL);
--- 616,622 ----
  
      case LOC_THREAD_LOCAL_STATIC:
        {
!       char *buf = (char*) alloca (MAX_REGISTER_RAW_SIZE);
  
        get_saved_register (buf, NULL, NULL, frame, SYMBOL_BASEREG (var),
                            NULL);
*************** addresses have not been bound by the dyn
*** 711,717 ****
  value_ptr
  value_from_register (struct type *type, int regnum, struct frame_info *frame)
  {
!   char raw_buffer[MAX_REGISTER_RAW_SIZE];
    CORE_ADDR addr;
    int optim;
    value_ptr v = allocate_value (type);
--- 711,717 ----
  value_ptr
  value_from_register (struct type *type, int regnum, struct frame_info *frame)
  {
!   char *raw_buffer = (char*) alloca (MAX_REGISTER_RAW_SIZE);
    CORE_ADDR addr;
    int optim;
    value_ptr v = allocate_value (type);
Index: gdb/infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.19
diff -c -3 -p -r1.19 infcmd.c
*** infcmd.c    2001/01/31 01:24:01     1.19
--- infcmd.c    2001/02/06 19:52:57
*************** do_registers_info (int regnum, int fpreg
*** 1467,1474 ****
  
    for (i = 0; i < numregs; i++)
      {
!       char raw_buffer[MAX_REGISTER_RAW_SIZE];
!       char virtual_buffer[MAX_REGISTER_VIRTUAL_SIZE];
  
        /* Decide between printing all regs, nonfloat regs, or specific reg.  */
        if (regnum == -1)
--- 1467,1474 ----
  
    for (i = 0; i < numregs; i++)
      {
!       char *raw_buffer = (char*) alloca (MAX_REGISTER_RAW_SIZE);
!       char *virtual_buffer = (char*) alloca (MAX_REGISTER_VIRTUAL_SIZE);
  
        /* Decide between printing all regs, nonfloat regs, or specific reg.  */
        if (regnum == -1)
Index: gdb/regcache.c
===================================================================
RCS file: /cvs/src/src/gdb/regcache.c,v
retrieving revision 1.14
diff -c -3 -p -r1.14 regcache.c
*** regcache.c  2001/01/09 00:12:48     1.14
--- regcache.c  2001/02/06 19:52:57
*************** write_register_bytes (int myregstart, ch
*** 558,564 ****
        /* The register partially overlaps the range being written.  */
        else
        {
!         char regbuf[MAX_REGISTER_RAW_SIZE];
          /* What's the overlap between this register's bytes and
               those the caller wants to write?  */
          int overlapstart = max (regstart, myregstart);
--- 558,564 ----
        /* The register partially overlaps the range being written.  */
        else
        {
!         char *regbuf = (char*) alloca (MAX_REGISTER_RAW_SIZE);
          /* What's the overlap between this register's bytes and
               those the caller wants to write?  */
          int overlapstart = max (regstart, myregstart);
Index: gdb/remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.36
diff -c -3 -p -r1.36 remote.c
*** remote.c    2001/02/02 19:14:33     1.36
--- remote.c    2001/02/06 19:52:58
*************** remote_wait (int pid, struct target_wait
*** 2604,2610 ****
          {
            int i;
            long regno;
!           char regs[MAX_REGISTER_RAW_SIZE];
  
            /* Expedited reply, containing Signal, {regno, reg} repeat */
            /*  format is:  'Tssn...:r...;n...:r...;n...:r...;#cc', where
--- 2604,2610 ----
          {
            int i;
            long regno;
!           char* regs = (char*) alloca (MAX_REGISTER_RAW_SIZE);
  
            /* Expedited reply, containing Signal, {regno, reg} repeat */
            /*  format is:  'Tssn...:r...;n...:r...;n...:r...;#cc', where
*************** remote_async_wait (int pid, struct targe
*** 2825,2831 ****
          {
            int i;
            long regno;
!           char regs[MAX_REGISTER_RAW_SIZE];
  
            /* Expedited reply, containing Signal, {regno, reg} repeat */
            /*  format is:  'Tssn...:r...;n...:r...;n...:r...;#cc', where
--- 2825,2831 ----
          {
            int i;
            long regno;
!           char* regs = (char*) alloca (MAX_REGISTER_RAW_SIZE);
  
            /* Expedited reply, containing Signal, {regno, reg} repeat */
            /*  format is:  'Tssn...:r...;n...:r...;n...:r...;#cc', where
Index: gdb/sol-thread.c
===================================================================
RCS file: /cvs/src/src/gdb/sol-thread.c,v
retrieving revision 1.20
diff -c -3 -p -r1.20 sol-thread.c
*** sol-thread.c        2001/01/24 21:01:02     1.20
--- sol-thread.c        2001/02/06 19:52:58
*************** sol_thread_store_registers (int regno)
*** 685,691 ****
    if (regno != -1)
      {                         /* Not writing all the regs */
        /* save new register value */
!       char old_value[REGISTER_SIZE];
        memcpy (old_value, &registers[REGISTER_BYTE (regno)], REGISTER_SIZE);
  
        val = p_td_thr_getgregs (&thandle, gregset);
--- 685,691 ----
    if (regno != -1)
      {                         /* Not writing all the regs */
        /* save new register value */
!       char* old_value = (char*) alloca (REGISTER_SIZE);
        memcpy (old_value, &registers[REGISTER_BYTE (regno)], REGISTER_SIZE);
  
        val = p_td_thr_getgregs (&thandle, gregset);
Index: gdb/valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.30
diff -c -3 -p -r1.30 valops.c
*** valops.c    2001/02/06 18:07:48     1.30
--- valops.c    2001/02/06 19:52:58
*************** value_assign (register value_ptr toval, 
*** 570,576 ****
  {
    register struct type *type;
    register value_ptr val;
!   char raw_buffer[MAX_REGISTER_RAW_SIZE];
    int use_buffer = 0;
  
    if (!toval->modifiable)
--- 570,576 ----
  {
    register struct type *type;
    register value_ptr val;
!   char *raw_buffer = (char*) alloca (MAX_REGISTER_RAW_SIZE);
    int use_buffer = 0;
  
    if (!toval->modifiable)
*************** CORE_ADDR
*** 1027,1033 ****
  push_word (CORE_ADDR sp, ULONGEST word)
  {
    register int len = REGISTER_SIZE;
!   char buffer[MAX_REGISTER_RAW_SIZE];
  
    store_unsigned_integer (buffer, len, word);
    if (INNER_THAN (1, 2))
--- 1027,1033 ----
  push_word (CORE_ADDR sp, ULONGEST word)
  {
    register int len = REGISTER_SIZE;
!   char *buffer = alloca (MAX_REGISTER_RAW_SIZE);
  
    store_unsigned_integer (buffer, len, word);
    if (INNER_THAN (1, 2))
*************** You must use a pointer to function type 
*** 1665,1671 ****
      SAVE_DUMMY_FRAME_TOS (sp);
  
    {
!     char retbuf[REGISTER_BYTES];
      char *name;
      struct symbol *symbol;
  
--- 1665,1671 ----
      SAVE_DUMMY_FRAME_TOS (sp);
  
    {
!     char *retbuf = (char*) alloca (REGISTER_BYTES);
      char *name;
      struct symbol *symbol;
  
Index: gdb/config/sparc/sun4sol2.mh
===================================================================
RCS file: /cvs/src/src/gdb/config/sparc/sun4sol2.mh,v
retrieving revision 1.3
diff -c -3 -p -r1.3 sun4sol2.mh
*** sun4sol2.mh 2000/10/24 20:05:36     1.3
--- sun4sol2.mh 2001/02/06 19:52:58
*************** NAT_FILE= nm-sun4sol2.h
*** 8,13 ****
--- 8,16 ----
  NATDEPFILES= corelow.o core-sol2.o solib.o solib-svr4.o fork-child.o procfs.o \
        proc-api.o proc-events.o proc-flags.o proc-why.o
  
+ # /usr/include/v9 is needed only by core-sol2.c when including 
+ # v9/sys/privregs.h, or rather the headers it in turn includes.
+ MH_CFLAGS=-I/usr/include/v9
  # If you are compiling with Sun's compiler, add the -xs option to CC
  # (e.g. `make CC="cc -xs"').
  # Sun's compilers require the -xs option to produce debug information
*************** NATDEPFILES= corelow.o core-sol2.o solib
*** 15,19 ****
  # files only, with undocumented pointers to it in the linked executable.
  # This is commented out because we don't assume that the Sun compiler
  # is in use.
! #MH_CFLAGS=-xs
  HOST_IPC=-DBSD_IPC
--- 18,22 ----
  # files only, with undocumented pointers to it in the linked executable.
  # This is commented out because we don't assume that the Sun compiler
  # is in use.
! #MH_CFLAGS=-xs -I/usr/include/v9
  HOST_IPC=-DBSD_IPC
From philb@gnu.org Tue Feb 06 12:14:00 2001
From: Philip Blundell <philb@gnu.org>
To: "Scott Bambrough" <scottb@netwinder.org>
Cc: "Michael Snyder" <msnyder@cygnus.com>, "Mark Kettenis" <kettenis@wins.uva.nl>, gdb-patches@sources.redhat.com
Subject: Re: patch for ARM GNU/Linux 
Date: Tue, 06 Feb 2001 12:14:00 -0000
Message-id: <E14QETP-0006gb-00@kings-cross.london.uk.eu.org>
References: <E14PWEF-0006Yz-00@kings-cross.london.uk.eu.org> <3A7F0B3A.1D1B33B3@cygnus.com> <s3in1c07swk.fsf@soliton.wins.uva.nl> <01f401c08fca$055387e0$LocalHost@netbackup>
X-SW-Source: 2001-02/msg00084.html
Content-length: 64

>This patch is ok with me.

Thanks.  I've checked it in.

p.