From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: João Cadamuro Junior , gdb Subject: Re: Cannot build GDB for arm-elf targets under cygwin... Date: Thu, 21 Jun 2001 00:59:00 -0000 Message-id: <3B31A87C.67DB1FFE@redhat.com> References: <3B30E895.5BDE9E4A@lit.cpdtt.cefetpr.br> <3B31A7F1.4BA158FF@redhat.com> X-SW-Source: 2001-06/msg00170.html 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 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Who owns gdbserver? Date: Thu, 21 Jun 2001 06:08:00 -0000 Message-id: 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