This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [5.2.1] quiet warnings for gdbreplay.c
On Fri, Jun 28, 2002 at 05:20:55PM -0400, Andrew Cagney wrote:
> >On Fri, Jun 28, 2002 at 12:12:31PM -0400, Andrew Cagney wrote:
> >
> >>>+#ifdef HAVE_STRING_H
> >>>+#include <string.h>
> >>>+#endif
> >
> >>
> >>Should that bit be "gdb_string.h"?
> >
> >
> >That depends :) gdbreplay is not part of GDB and has a different
> >config.h header (tests for a different set of macros).
>
> (We could always fix that - eliminate that configure file :-^ )
I dunno, I appreciate being able to run configure in the gdbserver/
directory. It means you don't need to a terminal library for your
target if you just want gdbserver. A lot of people have seemed to
appreciate this.
> More seriously, I think someone hacking on gdbreplay is likely to also
> be hacking on GDB. Consequently, they are going to expect the two
> directories to follow the same coding conventions.
We discussed this. The two directories share no code except for
signals/signals.c off in its own space. If they share headers, some
care is called for. They are not part of the same program!
> I had
> >eliminated all references to the gdb source code but then I introduced
> >an include of "gdb_proc_service.h", since the alternative was just
> >duplicating it; I have the feeling we should move that and headers like
> >gdb_string.h somewhere common - are they include/gdb/ candidates?
>
> You mean #include "gdb/gdb_string.h"? I think include/gdb/ is for
> external interfaces that are at some level controlled by GDB.
Then do we want a separate gdb/gdbint/ directory for this? I strongly
prefer that headers shared between GDB and other directories be clearly
marked and separated. That'd give me a place to move
gdb_proc_service.h, too.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer