Re: Cannot build GDB for arm-elf targets under cygwin...

[Fernando Nasser <fnasser@redhat.com>]

Of course, you will need the patch... :-)

I have attached it this time.



Fernando Nasser wrote:
> 
> Joao,
> 
> Please try this patch and let me know if it is compiling now.
> 
> Thank you for reporting this.
> 


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9
Index: remote-rdi.c
===================================================================
RCS file: /cvs/src/src/gdb/remote-rdi.c,v
retrieving revision 1.16
diff -c -p -r1.16 remote-rdi.c
*** remote-rdi.c	2001/05/04 04:15:26	1.16
--- remote-rdi.c	2001/06/21 07:54:11
*************** static void arm_rdi_mourn (void);
*** 77,83 ****
  
  static void arm_rdi_send (char *buf);
  
! static int arm_rdi_wait (ptid_t ptid, struct target_waitstatus *status);
  
  static void arm_rdi_kill (void);
  
--- 77,83 ----
  
  static void arm_rdi_send (char *buf);
  
! static ptid_t arm_rdi_wait (ptid_t ptid, struct target_waitstatus *status);
  
  static void arm_rdi_kill (void);
  
Index: rdi-share/host.h
===================================================================
RCS file: /cvs/src/src/gdb/rdi-share/host.h,v
retrieving revision 1.2
diff -c -p -r1.2 host.h
*** host.h	2001/06/10 16:25:51	1.2
--- host.h	2001/06/21 07:54:11
*************** typedef char *ArgvType;
*** 180,186 ****
  #  define FILENAME_MAX 256
  #endif
  
! #if (!defined(__STDC__) && !defined(__cplusplus) || defined(COMPILING_ON_SUNOS)
  /* Use bcopy rather than memmove, as memmove is not available.     */
  /* There does not seem to be a header for bcopy.                   */
  void bcopy(const char *src, char *dst, int length);
--- 180,186 ----
  #  define FILENAME_MAX 256
  #endif
  
! #if (!defined(__STDC__) && !defined(__cplusplus)) || defined(COMPILING_ON_SUNOS)
  /* Use bcopy rather than memmove, as memmove is not available.     */
  /* There does not seem to be a header for bcopy.                   */
  void bcopy(const char *src, char *dst, int length);
From qqi@world.std.com Thu Jun 21 06:08:00 2001
From: Quality Quorum <qqi@world.std.com>
To: Daniel Jacobowitz <dmj+@andrew.cmu.edu>
Cc: gdb@sources.redhat.com
Subject: Re: Who owns gdbserver?
Date: Thu, 21 Jun 2001 06:08:00 -0000
Message-id: <Pine.SGI.4.21.0106210903050.12138-100000@world.std.com>
References: <20010620221224.A19552@nevyn.them.org>
X-SW-Source: 2001-06/msg00171.html
Content-length: 1451

On Wed, 20 Jun 2001, Daniel Jacobowitz wrote:

> No one admits to it, in MAINTAINERS at least...
> 
> I am considering some fairly invasive changes to it, between some signal
> problems I've been having, more Linux ports, and threads.  It would be nice
> to establish a clear owner before I do that.
> 
> On a related note, I'm trying to think of a way to eliminate some of the
> crasser code duplication between gdb and gdbserver - or rather, right now
> it's mostly a lack of code duplication, causing gdbserver not to work
> terribly well.  The ideal solution would be to abstract the details of
> managing a Unix inferior via ptrace to the point where I can link the same
> files into gdbserver, but there are of course some intractable issues -
> setting the shared library debugging breakpoint, for instance.  Before I
> begin working on this, does anyone have any thoughts?  Is someone out there
> working on a similar thing before I waste my time?

I put together rproxy, which is in essense exteneded gdbserver, look at
gbd section on my web site http://world.std.com/~qqi

Also, if you are talking about threads support over remote GDB 
protocol there is some stuff there.

The only caveat there is that in the coming update I am going to change
licensing from GPL to BSD.
 
> Daniel Jacobowitz                           Carnegie Mellon University
> MontaVista Software                         Debian GNU/Linux Developer

Thanks,

Aleksey