No Subject

No Subject

[Andris Pavenis]

Hi!

Tried gdb-4.17.85 on i586-pc-linux-gnu (with glibc-2.1) and met following
problem that was no with gdb-4.17:

Some global symbols are defined in gdb/main.c (eg. gdb_stdout,
gdb-stderr, etc). As the result if I'm building all except main.c in
object library to use with some IDE that uses gdb for debugging 
(rhide-1.4.7),  I'm getting unresolved references. 

So I'm suggesting rather ugly hack (moving these definitions to top.c
and puting there static constructor that initializes gdb_std*). I agree does
not look nice, but I'm sending it only to point to possible problem.
I cannot use _initialize_* here as files must be defined before running
all _initialize_* procedures.

An alternative idea could be duplicating init code and global vrariables in
rhide.

Andris


--- main.c~1	Wed Feb 24 22:55:05 1999
+++ main.c	Mon Mar  8 16:38:44 1999
@@ -54,18 +54,6 @@
 
 int display_space;
 
-/* Whether this is the command line version or not */
-int tui_version = 0;
-
-/* Whether xdb commands will be handled */
-int xdb_commands = 0;
-
-/* Whether dbx commands will be handled */
-int dbx_commands = 0;
-
-GDB_FILE *gdb_stdout;
-GDB_FILE *gdb_stderr;
-
 /* Whether to enable writing into executable and core files */
 extern int write_files;
 
@@ -161,20 +149,6 @@
 
   getcwd (gdb_dirbuf, sizeof (gdb_dirbuf));
   current_directory = gdb_dirbuf;
-
-  gdb_file_size = sizeof(GDB_FILE);
-
-  gdb_stdout = (GDB_FILE *)xmalloc (gdb_file_size);
-  gdb_stdout->ts_streamtype = afile;
-  gdb_stdout->ts_filestream = stdout;
-  gdb_stdout->ts_strbuf = NULL;
-  gdb_stdout->ts_buflen = 0;
-
-  gdb_stderr = (GDB_FILE *)xmalloc (gdb_file_size);
-  gdb_stderr->ts_streamtype = afile;
-  gdb_stderr->ts_filestream = stderr;
-  gdb_stderr->ts_strbuf = NULL;
-  gdb_stderr->ts_buflen = 0;
 
   /* Parse arguments and options.  */
   {
--- top.c~1	Fri Jan 29 11:46:03 1999
+++ top.c	Mon Mar  8 16:37:03 1999
@@ -53,6 +53,19 @@
 
 extern void initialize_utils PARAMS ((void));
 
+
+/* Whether this is the command line version or not */
+int tui_version = 0;
+
+/* Whether xdb commands will be handled */
+int xdb_commands = 0;
+
+/* Whether dbx commands will be handled */
+int dbx_commands = 0;
+
+GDB_FILE *gdb_stdout;
+GDB_FILE *gdb_stderr;
+
 /* Prototypes for local functions */
 
 static void dont_repeat_command PARAMS ((char *, int));
@@ -467,6 +480,28 @@
 SIGJMP_BUF error_return;
 /* Where to go for return_to_top_level (RETURN_QUIT).  */
 SIGJMP_BUF quit_return;
+
+
+
+void __attribute__((constructor))
+_init_gdb_stdio (void)
+{
+  int gdb_file_size;
+  gdb_file_size = sizeof(GDB_FILE);
+
+  gdb_stdout = (GDB_FILE *)xmalloc (gdb_file_size);
+  gdb_stdout->ts_streamtype = afile;
+  gdb_stdout->ts_filestream = stdout;
+  gdb_stdout->ts_strbuf = NULL;
+  gdb_stdout->ts_buflen = 0;
+
+  gdb_stderr = (GDB_FILE *)xmalloc (gdb_file_size);
+  gdb_stderr->ts_streamtype = afile;
+  gdb_stderr->ts_filestream = stderr;
+  gdb_stderr->ts_strbuf = NULL;
+  gdb_stderr->ts_buflen = 0;
+}
+
 
 /* Return for reason REASON.  This generally gets back to the command
    loop, but can be caught via catch_errors.  */

Re: none

[Jim Blandy]

> Some global symbols are defined in gdb/main.c (eg. gdb_stdout,
> gdb-stderr, etc). As the result if I'm building all except main.c in
> object library to use with some IDE that uses gdb for debugging 
> (rhide-1.4.7),  I'm getting unresolved references. 

Um, wow.  It never occurred to me that anyone would try that.

Specifically, we can't include GCC-specific things like the
constructor attribute in GDB's source code.  Lots of people build GDB
with compilers other than GCC.

I'm not the GDB Maintainer --- that'd be Dr. Shebs --- but my feeling
is that we don't want to get into maintaining GDB with this kind of
application in mind.  If we turn GDB into a library, we should do it
right --- design an interface that makes sense, document the
interface, make sure that future changes preserve the boundaries, etc.
My guess is that that would be more work than we really want to take
on.

> An alternative idea could be duplicating init code and global
> vrariables in rhide.

I think this is your best bet.

Re: none

[Jim Blandy]

> Some global symbols are defined in gdb/main.c (eg. gdb_stdout,
> gdb-stderr, etc). As the result if I'm building all except main.c in
> object library to use with some IDE that uses gdb for debugging 
> (rhide-1.4.7),  I'm getting unresolved references. 

Um, wow.  It never occurred to me that anyone would try that.

Specifically, we can't include GCC-specific things like the
constructor attribute in GDB's source code.  Lots of people build GDB
with compilers other than GCC.

I'm not the GDB Maintainer --- that'd be Dr. Shebs --- but my feeling
is that we don't want to get into maintaining GDB with this kind of
application in mind.  If we turn GDB into a library, we should do it
right --- design an interface that makes sense, document the
interface, make sure that future changes preserve the boundaries, etc.
My guess is that that would be more work than we really want to take
on.

> An alternative idea could be duplicating init code and global
> vrariables in rhide.

I think this is your best bet.

Re: none

[Stan Shebs]

   From: Jim Blandy <jimb@cygnus.com>
   Date: 08 Mar 1999 14:15:47 -0500

   [...] my feeling
   is that we don't want to get into maintaining GDB with this kind of
   application in mind.

I agree with Jim.  Globals in main.c are just the tip of the iceberg!

I'd like to understand more about how rhide works with GDB.  Does
anybody have a pointer to something that goes into more depth?

							Stan

Re: none

[Stan Shebs]

   From: Jim Blandy <jimb@cygnus.com>
   Date: 08 Mar 1999 14:15:47 -0500

   [...] my feeling
   is that we don't want to get into maintaining GDB with this kind of
   application in mind.

I agree with Jim.  Globals in main.c are just the tip of the iceberg!

I'd like to understand more about how rhide works with GDB.  Does
anybody have a pointer to something that goes into more depth?

							Stan

Re: none

[Robert Hoehne]

> I'd like to understand more about how rhide works with GDB.  Does
> anybody have a pointer to something that goes into more depth?

http://www.tu-chemnitz.de/~sho/rho/rhide.html

RHIDE is in look and feel similar to the old known Borland 3.1
IDE but based on the GNU compilers and of course as its
builtin debugger GDB.

Robert

******************************************************
* email:   Robert Hoehne <robert.hoehne@gmx.net>     *
* Post:    Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW:     http://www.tu-chemnitz.de/~sho/rho        *
******************************************************

Re: none

[Robert Hoehne]

> I'd like to understand more about how rhide works with GDB.  Does
> anybody have a pointer to something that goes into more depth?

http://www.tu-chemnitz.de/~sho/rho/rhide.html

RHIDE is in look and feel similar to the old known Borland 3.1
IDE but based on the GNU compilers and of course as its
builtin debugger GDB.

Robert

******************************************************
* email:   Robert Hoehne <robert.hoehne@gmx.net>     *
* Post:    Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW:     http://www.tu-chemnitz.de/~sho/rho        *
******************************************************

Re: libgdb (was none)

[Robert Hoehne]

> > Some global symbols are defined in gdb/main.c (eg. gdb_stdout,
> > gdb-stderr, etc). As the result if I'm building all except main.c in
> > object library to use with some IDE that uses gdb for debugging 
> > (rhide-1.4.7),  I'm getting unresolved references. 
> 
> Um, wow.  It never occurred to me that anyone would try that.

I did that already since years in RHIDE and it worked perfectly.

Now I have reviewed the latest gdb sources and saw that the
problem really exists and I'm not happy about this change.

> is that we don't want to get into maintaining GDB with this kind of
> application in mind.  If we turn GDB into a library, we should do it
> right --- design an interface that makes sense, document the
> interface, make sure that future changes preserve the boundaries, etc.
> My guess is that that would be more work than we really want to take
> on.

So my question is now: Why does exist there a file called libgdb.texi
in the doc directory? I know now, that this file describes only an
imaginary library which does not exist, but if there exists such a
description of a libgdb the maintainer of gdb should think also a little
bit about that people, who did the hard job to integrate the gdb functionality
also in other programs even when it is not the described libgdb but a
lib with the same goal.

> > An alternative idea could be duplicating init code and global
> > vrariables in rhide.
> 
> I think this is your best bet.

This is not the best but only for now the shortest solution, since it
will force me to change every time my duplicated code when something
related to it will change in the future in the gdb sources.

BTW: There is not only an describtion of the imaginary libgdb, but there
is also a target in the Makefile which is called libgdb-files, which creates
a file containing all the names of the object files for the libgdb. So if, main.o
is not part of it, but main.o conatains code which is refered by other
files, than this is a bug.

Robert

******************************************************
* email:   Robert Hoehne <robert.hoehne@gmx.net>     *
* Post:    Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW:     http://www.tu-chemnitz.de/~sho/rho        *
******************************************************

Re: libgdb (was none)

[Robert Hoehne]

> > Some global symbols are defined in gdb/main.c (eg. gdb_stdout,
> > gdb-stderr, etc). As the result if I'm building all except main.c in
> > object library to use with some IDE that uses gdb for debugging 
> > (rhide-1.4.7),  I'm getting unresolved references. 
> 
> Um, wow.  It never occurred to me that anyone would try that.

I did that already since years in RHIDE and it worked perfectly.

Now I have reviewed the latest gdb sources and saw that the
problem really exists and I'm not happy about this change.

> is that we don't want to get into maintaining GDB with this kind of
> application in mind.  If we turn GDB into a library, we should do it
> right --- design an interface that makes sense, document the
> interface, make sure that future changes preserve the boundaries, etc.
> My guess is that that would be more work than we really want to take
> on.

So my question is now: Why does exist there a file called libgdb.texi
in the doc directory? I know now, that this file describes only an
imaginary library which does not exist, but if there exists such a
description of a libgdb the maintainer of gdb should think also a little
bit about that people, who did the hard job to integrate the gdb functionality
also in other programs even when it is not the described libgdb but a
lib with the same goal.

> > An alternative idea could be duplicating init code and global
> > vrariables in rhide.
> 
> I think this is your best bet.

This is not the best but only for now the shortest solution, since it
will force me to change every time my duplicated code when something
related to it will change in the future in the gdb sources.

BTW: There is not only an describtion of the imaginary libgdb, but there
is also a target in the Makefile which is called libgdb-files, which creates
a file containing all the names of the object files for the libgdb. So if, main.o
is not part of it, but main.o conatains code which is refered by other
files, than this is a bug.

Robert

******************************************************
* email:   Robert Hoehne <robert.hoehne@gmx.net>     *
* Post:    Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW:     http://www.tu-chemnitz.de/~sho/rho        *
******************************************************

Re: libgdb (was none)

[Stan Shebs]

   From: Robert Hoehne <robert.hoehne@gmx.net>
   Date: Mon, 8 Mar 1999 23:34:05 +0100

   I did that already since years in RHIDE and it worked perfectly.

   Now I have reviewed the latest gdb sources and saw that the
   problem really exists and I'm not happy about this change.

But how is anybody supposed to know what can be changed and what not?
This is a perfect example of why things have to be at least documented.
I had no idea that RHIDE did anything tricky with GDB main files, nor
I imagine did HP or anybody else, so we'll assume that things can be
rearranged or restructured as necessary.

   > is that we don't want to get into maintaining GDB with this kind of
   > application in mind.  If we turn GDB into a library, we should do it
   > right --- design an interface that makes sense, document the
   > interface, make sure that future changes preserve the boundaries, etc.
   > My guess is that that would be more work than we really want to take
   > on.

   So my question is now: Why does exist there a file called libgdb.texi
   in the doc directory?

I just left it there because I thought it would be useful guidance for
anyone wanting to undertake the project, because it *is* a worthwhile
project.  However, it seems to have been more misleading than helpful,
so now I'm thinking it should just be whacked out.  (Questions about
libgdb come up about twice/year, but nobody does anything to make it
work.)

   I know now, that this file describes only an
   imaginary library which does not exist, but if there exists such a
   description of a libgdb the maintainer of gdb should think also a little
   bit about that people, who did the hard job to integrate the gdb functionality
   also in other programs even when it is not the described libgdb but a
   lib with the same goal.

Propose a structure and the changes to go with it, and I will tell you
if it seems reasonable or not.  If it is reasonable, then we can look
at documenting it so future GDB hackers will know what the rules are,
and make any needed changes to support it.

   BTW: There is not only an describtion of the imaginary libgdb, but there
   is also a target in the Makefile which is called libgdb-files, which creates
   a file containing all the names of the object files for the libgdb. So if, main.o
   is not part of it, but main.o conatains code which is refered by other
   files, than this is a bug.

I thought all the libgdb crud in the makefile was gone, thanks for
pointing it out.  I'll delete it if nobody comes up with a good reason
for saving it - incomplete and/or broken code in the source never seems
to do anything except cause confusion and thus waste people's time, so
it's better just to make it go away.

							Stan

Re: libgdb (was none)

[Stan Shebs]

   From: Robert Hoehne <robert.hoehne@gmx.net>
   Date: Mon, 8 Mar 1999 23:34:05 +0100

   I did that already since years in RHIDE and it worked perfectly.

   Now I have reviewed the latest gdb sources and saw that the
   problem really exists and I'm not happy about this change.

But how is anybody supposed to know what can be changed and what not?
This is a perfect example of why things have to be at least documented.
I had no idea that RHIDE did anything tricky with GDB main files, nor
I imagine did HP or anybody else, so we'll assume that things can be
rearranged or restructured as necessary.

   > is that we don't want to get into maintaining GDB with this kind of
   > application in mind.  If we turn GDB into a library, we should do it
   > right --- design an interface that makes sense, document the
   > interface, make sure that future changes preserve the boundaries, etc.
   > My guess is that that would be more work than we really want to take
   > on.

   So my question is now: Why does exist there a file called libgdb.texi
   in the doc directory?

I just left it there because I thought it would be useful guidance for
anyone wanting to undertake the project, because it *is* a worthwhile
project.  However, it seems to have been more misleading than helpful,
so now I'm thinking it should just be whacked out.  (Questions about
libgdb come up about twice/year, but nobody does anything to make it
work.)

   I know now, that this file describes only an
   imaginary library which does not exist, but if there exists such a
   description of a libgdb the maintainer of gdb should think also a little
   bit about that people, who did the hard job to integrate the gdb functionality
   also in other programs even when it is not the described libgdb but a
   lib with the same goal.

Propose a structure and the changes to go with it, and I will tell you
if it seems reasonable or not.  If it is reasonable, then we can look
at documenting it so future GDB hackers will know what the rules are,
and make any needed changes to support it.

   BTW: There is not only an describtion of the imaginary libgdb, but there
   is also a target in the Makefile which is called libgdb-files, which creates
   a file containing all the names of the object files for the libgdb. So if, main.o
   is not part of it, but main.o conatains code which is refered by other
   files, than this is a bug.

I thought all the libgdb crud in the makefile was gone, thanks for
pointing it out.  I'll delete it if nobody comes up with a good reason
for saving it - incomplete and/or broken code in the source never seems
to do anything except cause confusion and thus waste people's time, so
it's better just to make it go away.

							Stan

Re: libgdb (was none)

[Todd Whitesel]

> I thought all the libgdb crud in the makefile was gone, thanks for
> pointing it out.  I'll delete it if nobody comes up with a good reason
> for saving it - incomplete and/or broken code in the source never seems
> to do anything except cause confusion and thus waste people's time, so
> it's better just to make it go away.

I vote for deleting it; principle of least confusion. Don't go out of your
way to make it harder for someone to do a real implementation later though.

Actually it might be fine to just comment it out, with a note to the effect
of "this functionality was never completely implemented" ...

Personally, I prefer protocol-based approaches to "lib" implementations.
I maintain the WRS/vxWorks commercial patches to GDB, and really need to
clean them up so they can go back in; unfortunately I came down with a
tenacious illness at the turn of the year, and since then I have been
struggling just to keep up with release deadlines.

-- 
Todd Whitesel
toddpw @ wrs.com

Re: libgdb (was none)

[Todd Whitesel]

> I thought all the libgdb crud in the makefile was gone, thanks for
> pointing it out.  I'll delete it if nobody comes up with a good reason
> for saving it - incomplete and/or broken code in the source never seems
> to do anything except cause confusion and thus waste people's time, so
> it's better just to make it go away.

I vote for deleting it; principle of least confusion. Don't go out of your
way to make it harder for someone to do a real implementation later though.

Actually it might be fine to just comment it out, with a note to the effect
of "this functionality was never completely implemented" ...

Personally, I prefer protocol-based approaches to "lib" implementations.
I maintain the WRS/vxWorks commercial patches to GDB, and really need to
clean them up so they can go back in; unfortunately I came down with a
tenacious illness at the turn of the year, and since then I have been
struggling just to keep up with release deadlines.

-- 
Todd Whitesel
toddpw @ wrs.com

Re: libgdb (was none)

[Robert Hoehne]

> But how is anybody supposed to know what can be changed and what not?
Of course nobody can imagine what the mainatainer
of GDB will do with the sources (except of course the mainatiner itself).

> This is a perfect example of why things have to be at least documented.
> I had no idea that RHIDE did anything tricky with GDB main files, nor

That's true, but since it is not documented I thougt to assume some
things which are there since ages. For instance most of the global
variables declared in top.c and not in main.c.

The next is: I did not some tricky things with GDB main files, I simply
used them in a way so that many other people which don't like the
default commanline interface of GDB to use an other interface but
the power of GDB.

I really don't understand, why you are against such small changes
which doesn't affect any behaviour of GDB but which will help the
programming of others. (for instance simply moving the newly
introduced global variables from main.c to top.c)

> I imagine did HP or anybody else, so we'll assume that things can be
> rearranged or restructured as necessary.

I have leaned that already :-( But at this point I really don't understand,
why the the mainatainers of GNU tools nearly ever forget when introducing
new features, that there are also people, which use the GNU environment
for DOS called DJGPP where are some limitations exist. And as I have
heared, the GNU cdrom with DJGPP on it was a hit.

Sometimes I think, the GNU mainatiner have something against DJGPP.
Only as an example with the filenames in the GNU packages. There exists
a tool called doschk which is available on the GNU mirrors written by DJ Delorie.
This tool can be used to chack, if the filenames are valid for DOS. But currently
I don't know any package, which takes care of this so the people, who do
the job to port the GNU programs for DJGPP have to do for any new version
the same annoing work to convert the filenames. To illustrate it, I append
here the output of dosck on the filenames for gdb-4.17.86:


The following files are not valid DOS file names:
gdb-4.17.86/gdb/c-exp.tab.c - too many dots
gdb-4.17.86/gdb/jv-exp.tab.c - too many dots
gdb-4.17.86/gdb/f-exp.tab.c - too many dots
gdb-4.17.86/gdb/m2-exp.tab.c - too many dots
gdb-4.17.86/gdb/nindy-share/b.out.h - too many dots
gdb-4.17.86/gdb/testsuite/.gdbinit - file name cannot start with dot
gdb-4.17.86/readline/config.h.bot - too many dots
gdb-4.17.86/readline/config.h.in - too many dots
gdb-4.17.86/sim/ppc/.gdbinit - file name cannot start with dot
gdb-4.17.86/intl/intlh.inst.in - too many dots
gdb-4.17.86/intl/po2tbl.sed.in - too many dots

The following resolve to the same DOS file names:
   ALPHA-OS.MH : gdb-4.17.86/gdb/config/alpha/alpha-osf1.mh
		 gdb-4.17.86/gdb/config/alpha/alpha-osf2.mh
		 gdb-4.17.86/gdb/config/alpha/alpha-osf3.mh
   APOLLO68.MH : gdb-4.17.86/gdb/config/m68k/apollo68b.mh
		 gdb-4.17.86/gdb/config/m68k/apollo68v.mh
       BFD.INF : gdb-4.17.86/bfd/doc/bfd.info
		 gdb-4.17.86/bfd/doc/bfd.info-1
		 gdb-4.17.86/bfd/doc/bfd.info-2
		 gdb-4.17.86/bfd/doc/bfd.info-3
		 gdb-4.17.86/bfd/doc/bfd.info-4
		 gdb-4.17.86/bfd/doc/bfd.info-5
		 gdb-4.17.86/bfd/doc/bfd.info-6
    CALLFUNC.C : gdb-4.17.86/gdb/testsuite/gdb.base/callfuncs.c
		 gdb-4.17.86/gdb/testsuite/gdb.base/callfuncs2.c
  CALLFUNC.EXP : gdb-4.17.86/gdb/testsuite/gdb.base/callfuncs.exp
		 gdb-4.17.86/gdb/testsuite/gdb.base/callfuncs2.exp
      CHANGELO : gdb-4.17.86/bfd/ChangeLog
		 gdb-4.17.86/bfd/ChangeLog-9193
		 gdb-4.17.86/bfd/ChangeLog-9495
		 gdb-4.17.86/bfd/ChangeLog-9697
      CHANGELO : gdb-4.17.86/gdb/ChangeLog
		 gdb-4.17.86/gdb/ChangeLog-9091
		 gdb-4.17.86/gdb/ChangeLog-92
		 gdb-4.17.86/gdb/ChangeLog-93
		 gdb-4.17.86/gdb/ChangeLog-94
		 gdb-4.17.86/gdb/ChangeLog-95
		 gdb-4.17.86/gdb/ChangeLog-96
		 gdb-4.17.86/gdb/ChangeLog-97
		 gdb-4.17.86/gdb/ChangeLog-98
      CHANGELO : gdb-4.17.86/readline/CHANGELOG
		 gdb-4.17.86/readline/ChangeLog
    CMA_STAC.H : gdb-4.17.86/gdb/osf-share/cma_stack.h
		 gdb-4.17.86/gdb/osf-share/cma_stack_int.h
    COREFILE.H : gdb-4.17.86/sim/ppc/corefile-n.h
		 gdb-4.17.86/sim/ppc/corefile.h
   CTTI-ADD.CC : gdb-4.17.86/gdb/testsuite/gdb.hp/ctti-add.cc
		 gdb-4.17.86/gdb/testsuite/gdb.hp/ctti-add1.cc
		 gdb-4.17.86/gdb/testsuite/gdb.hp/ctti-add2.cc
		 gdb-4.17.86/gdb/testsuite/gdb.hp/ctti-add3.cc
    DV-MN103.C : gdb-4.17.86/sim/mn10300/dv-mn103cpu.c
		 gdb-4.17.86/sim/mn10300/dv-mn103int.c
		 gdb-4.17.86/sim/mn10300/dv-mn103iop.c
		 gdb-4.17.86/sim/mn10300/dv-mn103ser.c
		 gdb-4.17.86/sim/mn10300/dv-mn103tim.c
    DV-TX390.C : gdb-4.17.86/sim/mips/dv-tx3904cpu.c
		 gdb-4.17.86/sim/mips/dv-tx3904irc.c
		 gdb-4.17.86/sim/mips/dv-tx3904sio.c
		 gdb-4.17.86/sim/mips/dv-tx3904tmr.c
   EXTSTRUC.CH : gdb-4.17.86/gdb/testsuite/gdb.chill/extstruct-grt.ch
		 gdb-4.17.86/gdb/testsuite/gdb.chill/extstruct.ch
       GDB.INF : gdb-4.17.86/gdb/doc/gdb.info
		 gdb-4.17.86/gdb/doc/gdb.info-1
		 gdb-4.17.86/gdb/doc/gdb.info-10
		 gdb-4.17.86/gdb/doc/gdb.info-2
		 gdb-4.17.86/gdb/doc/gdb.info-3
		 gdb-4.17.86/gdb/doc/gdb.info-4
		 gdb-4.17.86/gdb/doc/gdb.info-5
		 gdb-4.17.86/gdb/doc/gdb.info-6
		 gdb-4.17.86/gdb/doc/gdb.info-7
		 gdb-4.17.86/gdb/doc/gdb.info-8
		 gdb-4.17.86/gdb/doc/gdb.info-9
    GDBINT.INF : gdb-4.17.86/gdb/doc/gdbint.info
		 gdb-4.17.86/gdb/doc/gdbint.info-1
		 gdb-4.17.86/gdb/doc/gdbint.info-2
		 gdb-4.17.86/gdb/doc/gdbint.info-3
    IDECODE_.H : gdb-4.17.86/sim/ppc/idecode_branch.h
		 gdb-4.17.86/sim/ppc/idecode_expression.h
		 gdb-4.17.86/sim/ppc/idecode_fields.h
    LS-LD4BH.S : gdb-4.17.86/sim/testsuite/d30v-elf/ls-ld4bh.S
		 gdb-4.17.86/sim/testsuite/d30v-elf/ls-ld4bhu.S
    M68K-AOU.U : gdb-4.17.86/gdb/testsuite/gdb.base/m68k-aout.u
		 gdb-4.17.86/gdb/testsuite/gdb.base/m68k-aout2.u
    NM-APOLL.H : gdb-4.17.86/gdb/config/m68k/nm-apollo68b.h
		 gdb-4.17.86/gdb/config/m68k/nm-apollo68v.h
    NM-HP300.H : gdb-4.17.86/gdb/config/m68k/nm-hp300bsd.h
		 gdb-4.17.86/gdb/config/m68k/nm-hp300hpux.h
    NM-HPPAH.H : gdb-4.17.86/gdb/config/pa/nm-hppah.h
		 gdb-4.17.86/gdb/config/pa/nm-hppah11.h
    NM-I386S.H : gdb-4.17.86/gdb/config/i386/nm-i386sco.h
		 gdb-4.17.86/gdb/config/i386/nm-i386sco4.h
		 gdb-4.17.86/gdb/config/i386/nm-i386sco5.h
		 gdb-4.17.86/gdb/config/i386/nm-i386sol2.h
    NM-I386V.H : gdb-4.17.86/gdb/config/i386/nm-i386v.h
		 gdb-4.17.86/gdb/config/i386/nm-i386v4.h
		 gdb-4.17.86/gdb/config/i386/nm-i386v42mp.h
    NM-RS600.H : gdb-4.17.86/gdb/config/rs6000/nm-rs6000.h
		 gdb-4.17.86/gdb/config/rs6000/nm-rs6000ly.h
    POINTERS.C : gdb-4.17.86/gdb/testsuite/gdb.base/pointers.c
		 gdb-4.17.86/gdb/testsuite/gdb.base/pointers2.c
  POINTERS.EXP : gdb-4.17.86/gdb/testsuite/gdb.base/pointers.exp
		 gdb-4.17.86/gdb/testsuite/gdb.base/pointers2.exp
   REF-TYPE.CC : gdb-4.17.86/gdb/testsuite/gdb.c++/ref-types.cc
		 gdb-4.17.86/gdb/testsuite/gdb.c++/ref-types2.cc
  REF-TYPE.EXP : gdb-4.17.86/gdb/testsuite/gdb.c++/ref-types.exp
		 gdb-4.17.86/gdb/testsuite/gdb.c++/ref-types2.exp
    REMOTE-A.C : gdb-4.17.86/gdb/remote-adapt.c
		 gdb-4.17.86/gdb/remote-array.c
    REMOTE-E.C : gdb-4.17.86/gdb/remote-e7000.c
		 gdb-4.17.86/gdb/remote-eb.c
		 gdb-4.17.86/gdb/remote-es.c
		 gdb-4.17.86/gdb/remote-est.c
    REMOTE-M.C : gdb-4.17.86/gdb/remote-mips.c
		 gdb-4.17.86/gdb/remote-mm.c
    REMOTE-N.C : gdb-4.17.86/gdb/remote-nindy.c
		 gdb-4.17.86/gdb/remote-nrom.c
    REMOTE-R.C : gdb-4.17.86/gdb/remote-rdi.c
		 gdb-4.17.86/gdb/remote-rdp.c
    REMOTE-S.C : gdb-4.17.86/gdb/remote-sds.c
		 gdb-4.17.86/gdb/remote-sim.c
		 gdb-4.17.86/gdb/remote-st.c
    REMOTE-U.C : gdb-4.17.86/gdb/remote-udi.c
		 gdb-4.17.86/gdb/remote-utils.c
    REMOTE-V.C : gdb-4.17.86/gdb/remote-vx.c
		 gdb-4.17.86/gdb/remote-vx29k.c
		 gdb-4.17.86/gdb/remote-vx68.c
		 gdb-4.17.86/gdb/remote-vx960.c
		 gdb-4.17.86/gdb/remote-vxmips.c
		 gdb-4.17.86/gdb/remote-vxsparc.c
    SIM-ENDI.H : gdb-4.17.86/sim/ppc/sim-endian-n.h
		 gdb-4.17.86/sim/ppc/sim-endian.h
    SPARCLET.C : gdb-4.17.86/gdb/sparclet-rom.c
		 gdb-4.17.86/gdb/sparclet-stub.c
     STABS.INF : gdb-4.17.86/gdb/doc/stabs.info
		 gdb-4.17.86/gdb/doc/stabs.info-1
		 gdb-4.17.86/gdb/doc/stabs.info-2
		 gdb-4.17.86/gdb/doc/stabs.info-3
		 gdb-4.17.86/gdb/doc/stabs.info-4
    TM-ALPHA.H : gdb-4.17.86/gdb/config/alpha/tm-alpha.h
		 gdb-4.17.86/gdb/config/alpha/tm-alphalinux.h
    TM-BIGMI.H : gdb-4.17.86/gdb/config/mips/tm-bigmips.h
		 gdb-4.17.86/gdb/config/mips/tm-bigmips64.h
    TM-DELTA.H : gdb-4.17.86/gdb/config/m88k/tm-delta88.h
		 gdb-4.17.86/gdb/config/m88k/tm-delta88v4.h
    TM-EMBED.H : gdb-4.17.86/gdb/config/mips/tm-embed.h
		 gdb-4.17.86/gdb/config/mips/tm-embed64.h
		 gdb-4.17.86/gdb/config/mips/tm-embedl.h
		 gdb-4.17.86/gdb/config/mips/tm-embedl64.h
    TM-HP300.H : gdb-4.17.86/gdb/config/m68k/tm-hp300bsd.h
		 gdb-4.17.86/gdb/config/m68k/tm-hp300hpux.h
    TM-I386M.H : gdb-4.17.86/gdb/config/i386/tm-i386m3.h
		 gdb-4.17.86/gdb/config/i386/tm-i386mk.h
    TM-I386S.H : gdb-4.17.86/gdb/config/i386/tm-i386sco5.h
		 gdb-4.17.86/gdb/config/i386/tm-i386sol2.h
    TM-I386V.H : gdb-4.17.86/gdb/config/i386/tm-i386v.h
		 gdb-4.17.86/gdb/config/i386/tm-i386v4.h
		 gdb-4.17.86/gdb/config/i386/tm-i386v42mp.h
    TM-PPCLE.H : gdb-4.17.86/gdb/config/powerpc/tm-ppcle-eabi.h
		 gdb-4.17.86/gdb/config/powerpc/tm-ppcle-sim.h
    TM-RS600.H : gdb-4.17.86/gdb/config/rs6000/tm-rs6000-aix4.h
		 gdb-4.17.86/gdb/config/rs6000/tm-rs6000.h
		 gdb-4.17.86/gdb/config/rs6000/tm-rs6000ly.h
    TM-SPARC.H : gdb-4.17.86/gdb/config/sparc/tm-sparc.h
		 gdb-4.17.86/gdb/config/sparc/tm-sparclet.h
		 gdb-4.17.86/gdb/config/sparc/tm-sparclite.h
		 gdb-4.17.86/gdb/config/sparc/tm-sparclynx.h
    TM-VR430.H : gdb-4.17.86/gdb/config/mips/tm-vr4300.h
		 gdb-4.17.86/gdb/config/mips/tm-vr4300el.h
    TM-VR500.H : gdb-4.17.86/gdb/config/mips/tm-vr5000.h
		 gdb-4.17.86/gdb/config/mips/tm-vr5000el.h
    TUISOURC.C : gdb-4.17.86/gdb/tui/tuiSource.c
		 gdb-4.17.86/gdb/tui/tuiSourceWin.c
    TUISOURC.H : gdb-4.17.86/gdb/tui/tuiSource.h
		 gdb-4.17.86/gdb/tui/tuiSourceWin.h
    XM-ALPHA.H : gdb-4.17.86/gdb/config/alpha/xm-alphalinux.h
		 gdb-4.17.86/gdb/config/alpha/xm-alphaosf.h
    XM-APOLL.H : gdb-4.17.86/gdb/config/m68k/xm-apollo68b.h
		 gdb-4.17.86/gdb/config/m68k/xm-apollo68v.h
    XM-DELTA.H : gdb-4.17.86/gdb/config/m88k/xm-delta88.h
		 gdb-4.17.86/gdb/config/m88k/xm-delta88v4.h
    XM-HP300.H : gdb-4.17.86/gdb/config/m68k/xm-hp300bsd.h
		 gdb-4.17.86/gdb/config/m68k/xm-hp300hpux.h
    XM-I386M.H : gdb-4.17.86/gdb/config/i386/xm-i386m3.h
		 gdb-4.17.86/gdb/config/i386/xm-i386mach.h
		 gdb-4.17.86/gdb/config/i386/xm-i386mk.h
    XM-I386V.H : gdb-4.17.86/gdb/config/i386/xm-i386v.h
		 gdb-4.17.86/gdb/config/i386/xm-i386v32.h
		 gdb-4.17.86/gdb/config/i386/xm-i386v4.h
    XM-RS600.H : gdb-4.17.86/gdb/config/rs6000/xm-rs6000.h
		 gdb-4.17.86/gdb/config/rs6000/xm-rs6000ly.h
    XM-SPARC.H : gdb-4.17.86/gdb/config/sparc/xm-sparc.h
		 gdb-4.17.86/gdb/config/sparc/xm-sparclynx.h
    XM-VAXUL.H : gdb-4.17.86/gdb/config/vax/xm-vaxult.h
		 gdb-4.17.86/gdb/config/vax/xm-vaxult2.h

The following resolve to the same SysV file names:
filter_filenam : gdb-4.17.86/sim/ppc/filter_filename.c
		 gdb-4.17.86/sim/ppc/filter_filename.h
gen-semantics. : gdb-4.17.86/sim/igen/gen-semantics.c
		 gdb-4.17.86/sim/igen/gen-semantics.h
gen-semantics. : gdb-4.17.86/sim/ppc/gen-semantics.c
		 gdb-4.17.86/sim/ppc/gen-semantics.h
hw-properties. : gdb-4.17.86/sim/common/hw-properties.c
		 gdb-4.17.86/sim/common/hw-properties.h
tuiGeneralWin. : gdb-4.17.86/gdb/tui/tuiGeneralWin.c
		 gdb-4.17.86/gdb/tui/tuiGeneralWin.h

The following file names are too long for SysV:
ChangeLog.Cygn : gdb-4.17.86/intl/ChangeLog.Cygnus
a1-selftest.ex : gdb-4.17.86/gdb/testsuite/gdb.base/a1-selftest.exp
cma_debug_clie : gdb-4.17.86/gdb/osf-share/cma_debug_client.h
cma_semaphore_ : gdb-4.17.86/gdb/osf-share/cma_semaphore_defs.h
cma_stack_int. : gdb-4.17.86/gdb/osf-share/cma_stack_int.h
cma_thread_io. : gdb-4.17.86/gdb/osf-share/AT386/cma_thread_io.h
cma_thread_io. : gdb-4.17.86/gdb/osf-share/HP800/cma_thread_io.h
cma_thread_io. : gdb-4.17.86/gdb/osf-share/RIOS/cma_thread_io.h
emc-support.ex : gdb-4.17.86/gdb/testsuite/lib/emc-support.exp
exc_request.de : gdb-4.17.86/gdb/exc_request.defs
execd-program. : gdb-4.17.86/gdb/testsuite/gdb.hp/execd-program.c
extstruct-grt. : gdb-4.17.86/gdb/testsuite/gdb.chill/extstruct-grt.ch
forward-includ : gdb-4.17.86/config/mpw/forward-include
gen-so-thresh. : gdb-4.17.86/gdb/testsuite/gdb.hp/gen-so-thresh.c
hp-psymtab-rea : gdb-4.17.86/gdb/hp-psymtab-read.c
hp-symtab-read : gdb-4.17.86/gdb/hp-symtab-read.c
idecode_branch : gdb-4.17.86/sim/ppc/idecode_branch.h
idecode_expres : gdb-4.17.86/sim/ppc/idecode_expression.h
idecode_fields : gdb-4.17.86/sim/ppc/idecode_fields.h
m68klinux-nat. : gdb-4.17.86/gdb/m68klinux-nat.c
mn10300-eval.e : gdb-4.17.86/gdb/testsuite/config/mn10300-eval.exp
ns32knbsd-nat. : gdb-4.17.86/gdb/ns32knbsd-nat.c
ppc-cache-rule : gdb-4.17.86/sim/ppc/ppc-cache-rules
ppc-instructio : gdb-4.17.86/sim/ppc/ppc-instructions
process_reply. : gdb-4.17.86/gdb/process_reply.defs
remote-vxmips. : gdb-4.17.86/gdb/remote-vxmips.c
remote-vxsparc : gdb-4.17.86/gdb/remote-vxsparc.c
reply_mig_hack : gdb-4.17.86/gdb/reply_mig_hack.awk
sim_callbacks. : gdb-4.17.86/sim/ppc/sim_callbacks.h
so-thresh.link : gdb-4.17.86/gdb/testsuite/gdb.hp/so-thresh.linkopts
sparclet-stub. : gdb-4.17.86/gdb/sparclet-stub.c
tm-alphalinux. : gdb-4.17.86/gdb/config/alpha/tm-alphalinux.h
tm-ppcle-eabi. : gdb-4.17.86/gdb/config/powerpc/tm-ppcle-eabi.h
tm-rs6000-aix4 : gdb-4.17.86/gdb/config/rs6000/tm-rs6000-aix4.h
trace-support. : gdb-4.17.86/gdb/testsuite/lib/trace-support.exp
vforked-progra : gdb-4.17.86/gdb/testsuite/gdb.hp/vforked-program.c
while-stepping : gdb-4.17.86/gdb/testsuite/gdb.trace/while-stepping.exp
xm-alphalinux. : gdb-4.17.86/gdb/config/alpha/xm-alphalinux.h
******************************************************
* email:   Robert Hoehne <robert.hoehne@gmx.net>     *
* Post:    Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW:     http://www.tu-chemnitz.de/~sho/rho        *
******************************************************

Re: libgdb (was none)

[Robert Hoehne]

> But how is anybody supposed to know what can be changed and what not?
Of course nobody can imagine what the mainatainer
of GDB will do with the sources (except of course the mainatiner itself).

> This is a perfect example of why things have to be at least documented.
> I had no idea that RHIDE did anything tricky with GDB main files, nor

That's true, but since it is not documented I thougt to assume some
things which are there since ages. For instance most of the global
variables declared in top.c and not in main.c.

The next is: I did not some tricky things with GDB main files, I simply
used them in a way so that many other people which don't like the
default commanline interface of GDB to use an other interface but
the power of GDB.

I really don't understand, why you are against such small changes
which doesn't affect any behaviour of GDB but which will help the
programming of others. (for instance simply moving the newly
introduced global variables from main.c to top.c)

> I imagine did HP or anybody else, so we'll assume that things can be
> rearranged or restructured as necessary.

I have leaned that already :-( But at this point I really don't understand,
why the the mainatainers of GNU tools nearly ever forget when introducing
new features, that there are also people, which use the GNU environment
for DOS called DJGPP where are some limitations exist. And as I have
heared, the GNU cdrom with DJGPP on it was a hit.

Sometimes I think, the GNU mainatiner have something against DJGPP.
Only as an example with the filenames in the GNU packages. There exists
a tool called doschk which is available on the GNU mirrors written by DJ Delorie.
This tool can be used to chack, if the filenames are valid for DOS. But currently
I don't know any package, which takes care of this so the people, who do
the job to port the GNU programs for DJGPP have to do for any new version
the same annoing work to convert the filenames. To illustrate it, I append
here the output of dosck on the filenames for gdb-4.17.86:


The following files are not valid DOS file names:
gdb-4.17.86/gdb/c-exp.tab.c - too many dots
gdb-4.17.86/gdb/jv-exp.tab.c - too many dots
gdb-4.17.86/gdb/f-exp.tab.c - too many dots
gdb-4.17.86/gdb/m2-exp.tab.c - too many dots
gdb-4.17.86/gdb/nindy-share/b.out.h - too many dots
gdb-4.17.86/gdb/testsuite/.gdbinit - file name cannot start with dot
gdb-4.17.86/readline/config.h.bot - too many dots
gdb-4.17.86/readline/config.h.in - too many dots
gdb-4.17.86/sim/ppc/.gdbinit - file name cannot start with dot
gdb-4.17.86/intl/intlh.inst.in - too many dots
gdb-4.17.86/intl/po2tbl.sed.in - too many dots

The following resolve to the same DOS file names:
   ALPHA-OS.MH : gdb-4.17.86/gdb/config/alpha/alpha-osf1.mh
		 gdb-4.17.86/gdb/config/alpha/alpha-osf2.mh
		 gdb-4.17.86/gdb/config/alpha/alpha-osf3.mh
   APOLLO68.MH : gdb-4.17.86/gdb/config/m68k/apollo68b.mh
		 gdb-4.17.86/gdb/config/m68k/apollo68v.mh
       BFD.INF : gdb-4.17.86/bfd/doc/bfd.info
		 gdb-4.17.86/bfd/doc/bfd.info-1
		 gdb-4.17.86/bfd/doc/bfd.info-2
		 gdb-4.17.86/bfd/doc/bfd.info-3
		 gdb-4.17.86/bfd/doc/bfd.info-4
		 gdb-4.17.86/bfd/doc/bfd.info-5
		 gdb-4.17.86/bfd/doc/bfd.info-6
    CALLFUNC.C : gdb-4.17.86/gdb/testsuite/gdb.base/callfuncs.c
		 gdb-4.17.86/gdb/testsuite/gdb.base/callfuncs2.c
  CALLFUNC.EXP : gdb-4.17.86/gdb/testsuite/gdb.base/callfuncs.exp
		 gdb-4.17.86/gdb/testsuite/gdb.base/callfuncs2.exp
      CHANGELO : gdb-4.17.86/bfd/ChangeLog
		 gdb-4.17.86/bfd/ChangeLog-9193
		 gdb-4.17.86/bfd/ChangeLog-9495
		 gdb-4.17.86/bfd/ChangeLog-9697
      CHANGELO : gdb-4.17.86/gdb/ChangeLog
		 gdb-4.17.86/gdb/ChangeLog-9091
		 gdb-4.17.86/gdb/ChangeLog-92
		 gdb-4.17.86/gdb/ChangeLog-93
		 gdb-4.17.86/gdb/ChangeLog-94
		 gdb-4.17.86/gdb/ChangeLog-95
		 gdb-4.17.86/gdb/ChangeLog-96
		 gdb-4.17.86/gdb/ChangeLog-97
		 gdb-4.17.86/gdb/ChangeLog-98
      CHANGELO : gdb-4.17.86/readline/CHANGELOG
		 gdb-4.17.86/readline/ChangeLog
    CMA_STAC.H : gdb-4.17.86/gdb/osf-share/cma_stack.h
		 gdb-4.17.86/gdb/osf-share/cma_stack_int.h
    COREFILE.H : gdb-4.17.86/sim/ppc/corefile-n.h
		 gdb-4.17.86/sim/ppc/corefile.h
   CTTI-ADD.CC : gdb-4.17.86/gdb/testsuite/gdb.hp/ctti-add.cc
		 gdb-4.17.86/gdb/testsuite/gdb.hp/ctti-add1.cc
		 gdb-4.17.86/gdb/testsuite/gdb.hp/ctti-add2.cc
		 gdb-4.17.86/gdb/testsuite/gdb.hp/ctti-add3.cc
    DV-MN103.C : gdb-4.17.86/sim/mn10300/dv-mn103cpu.c
		 gdb-4.17.86/sim/mn10300/dv-mn103int.c
		 gdb-4.17.86/sim/mn10300/dv-mn103iop.c
		 gdb-4.17.86/sim/mn10300/dv-mn103ser.c
		 gdb-4.17.86/sim/mn10300/dv-mn103tim.c
    DV-TX390.C : gdb-4.17.86/sim/mips/dv-tx3904cpu.c
		 gdb-4.17.86/sim/mips/dv-tx3904irc.c
		 gdb-4.17.86/sim/mips/dv-tx3904sio.c
		 gdb-4.17.86/sim/mips/dv-tx3904tmr.c
   EXTSTRUC.CH : gdb-4.17.86/gdb/testsuite/gdb.chill/extstruct-grt.ch
		 gdb-4.17.86/gdb/testsuite/gdb.chill/extstruct.ch
       GDB.INF : gdb-4.17.86/gdb/doc/gdb.info
		 gdb-4.17.86/gdb/doc/gdb.info-1
		 gdb-4.17.86/gdb/doc/gdb.info-10
		 gdb-4.17.86/gdb/doc/gdb.info-2
		 gdb-4.17.86/gdb/doc/gdb.info-3
		 gdb-4.17.86/gdb/doc/gdb.info-4
		 gdb-4.17.86/gdb/doc/gdb.info-5
		 gdb-4.17.86/gdb/doc/gdb.info-6
		 gdb-4.17.86/gdb/doc/gdb.info-7
		 gdb-4.17.86/gdb/doc/gdb.info-8
		 gdb-4.17.86/gdb/doc/gdb.info-9
    GDBINT.INF : gdb-4.17.86/gdb/doc/gdbint.info
		 gdb-4.17.86/gdb/doc/gdbint.info-1
		 gdb-4.17.86/gdb/doc/gdbint.info-2
		 gdb-4.17.86/gdb/doc/gdbint.info-3
    IDECODE_.H : gdb-4.17.86/sim/ppc/idecode_branch.h
		 gdb-4.17.86/sim/ppc/idecode_expression.h
		 gdb-4.17.86/sim/ppc/idecode_fields.h
    LS-LD4BH.S : gdb-4.17.86/sim/testsuite/d30v-elf/ls-ld4bh.S
		 gdb-4.17.86/sim/testsuite/d30v-elf/ls-ld4bhu.S
    M68K-AOU.U : gdb-4.17.86/gdb/testsuite/gdb.base/m68k-aout.u
		 gdb-4.17.86/gdb/testsuite/gdb.base/m68k-aout2.u
    NM-APOLL.H : gdb-4.17.86/gdb/config/m68k/nm-apollo68b.h
		 gdb-4.17.86/gdb/config/m68k/nm-apollo68v.h
    NM-HP300.H : gdb-4.17.86/gdb/config/m68k/nm-hp300bsd.h
		 gdb-4.17.86/gdb/config/m68k/nm-hp300hpux.h
    NM-HPPAH.H : gdb-4.17.86/gdb/config/pa/nm-hppah.h
		 gdb-4.17.86/gdb/config/pa/nm-hppah11.h
    NM-I386S.H : gdb-4.17.86/gdb/config/i386/nm-i386sco.h
		 gdb-4.17.86/gdb/config/i386/nm-i386sco4.h
		 gdb-4.17.86/gdb/config/i386/nm-i386sco5.h
		 gdb-4.17.86/gdb/config/i386/nm-i386sol2.h
    NM-I386V.H : gdb-4.17.86/gdb/config/i386/nm-i386v.h
		 gdb-4.17.86/gdb/config/i386/nm-i386v4.h
		 gdb-4.17.86/gdb/config/i386/nm-i386v42mp.h
    NM-RS600.H : gdb-4.17.86/gdb/config/rs6000/nm-rs6000.h
		 gdb-4.17.86/gdb/config/rs6000/nm-rs6000ly.h
    POINTERS.C : gdb-4.17.86/gdb/testsuite/gdb.base/pointers.c
		 gdb-4.17.86/gdb/testsuite/gdb.base/pointers2.c
  POINTERS.EXP : gdb-4.17.86/gdb/testsuite/gdb.base/pointers.exp
		 gdb-4.17.86/gdb/testsuite/gdb.base/pointers2.exp
   REF-TYPE.CC : gdb-4.17.86/gdb/testsuite/gdb.c++/ref-types.cc
		 gdb-4.17.86/gdb/testsuite/gdb.c++/ref-types2.cc
  REF-TYPE.EXP : gdb-4.17.86/gdb/testsuite/gdb.c++/ref-types.exp
		 gdb-4.17.86/gdb/testsuite/gdb.c++/ref-types2.exp
    REMOTE-A.C : gdb-4.17.86/gdb/remote-adapt.c
		 gdb-4.17.86/gdb/remote-array.c
    REMOTE-E.C : gdb-4.17.86/gdb/remote-e7000.c
		 gdb-4.17.86/gdb/remote-eb.c
		 gdb-4.17.86/gdb/remote-es.c
		 gdb-4.17.86/gdb/remote-est.c
    REMOTE-M.C : gdb-4.17.86/gdb/remote-mips.c
		 gdb-4.17.86/gdb/remote-mm.c
    REMOTE-N.C : gdb-4.17.86/gdb/remote-nindy.c
		 gdb-4.17.86/gdb/remote-nrom.c
    REMOTE-R.C : gdb-4.17.86/gdb/remote-rdi.c
		 gdb-4.17.86/gdb/remote-rdp.c
    REMOTE-S.C : gdb-4.17.86/gdb/remote-sds.c
		 gdb-4.17.86/gdb/remote-sim.c
		 gdb-4.17.86/gdb/remote-st.c
    REMOTE-U.C : gdb-4.17.86/gdb/remote-udi.c
		 gdb-4.17.86/gdb/remote-utils.c
    REMOTE-V.C : gdb-4.17.86/gdb/remote-vx.c
		 gdb-4.17.86/gdb/remote-vx29k.c
		 gdb-4.17.86/gdb/remote-vx68.c
		 gdb-4.17.86/gdb/remote-vx960.c
		 gdb-4.17.86/gdb/remote-vxmips.c
		 gdb-4.17.86/gdb/remote-vxsparc.c
    SIM-ENDI.H : gdb-4.17.86/sim/ppc/sim-endian-n.h
		 gdb-4.17.86/sim/ppc/sim-endian.h
    SPARCLET.C : gdb-4.17.86/gdb/sparclet-rom.c
		 gdb-4.17.86/gdb/sparclet-stub.c
     STABS.INF : gdb-4.17.86/gdb/doc/stabs.info
		 gdb-4.17.86/gdb/doc/stabs.info-1
		 gdb-4.17.86/gdb/doc/stabs.info-2
		 gdb-4.17.86/gdb/doc/stabs.info-3
		 gdb-4.17.86/gdb/doc/stabs.info-4
    TM-ALPHA.H : gdb-4.17.86/gdb/config/alpha/tm-alpha.h
		 gdb-4.17.86/gdb/config/alpha/tm-alphalinux.h
    TM-BIGMI.H : gdb-4.17.86/gdb/config/mips/tm-bigmips.h
		 gdb-4.17.86/gdb/config/mips/tm-bigmips64.h
    TM-DELTA.H : gdb-4.17.86/gdb/config/m88k/tm-delta88.h
		 gdb-4.17.86/gdb/config/m88k/tm-delta88v4.h
    TM-EMBED.H : gdb-4.17.86/gdb/config/mips/tm-embed.h
		 gdb-4.17.86/gdb/config/mips/tm-embed64.h
		 gdb-4.17.86/gdb/config/mips/tm-embedl.h
		 gdb-4.17.86/gdb/config/mips/tm-embedl64.h
    TM-HP300.H : gdb-4.17.86/gdb/config/m68k/tm-hp300bsd.h
		 gdb-4.17.86/gdb/config/m68k/tm-hp300hpux.h
    TM-I386M.H : gdb-4.17.86/gdb/config/i386/tm-i386m3.h
		 gdb-4.17.86/gdb/config/i386/tm-i386mk.h
    TM-I386S.H : gdb-4.17.86/gdb/config/i386/tm-i386sco5.h
		 gdb-4.17.86/gdb/config/i386/tm-i386sol2.h
    TM-I386V.H : gdb-4.17.86/gdb/config/i386/tm-i386v.h
		 gdb-4.17.86/gdb/config/i386/tm-i386v4.h
		 gdb-4.17.86/gdb/config/i386/tm-i386v42mp.h
    TM-PPCLE.H : gdb-4.17.86/gdb/config/powerpc/tm-ppcle-eabi.h
		 gdb-4.17.86/gdb/config/powerpc/tm-ppcle-sim.h
    TM-RS600.H : gdb-4.17.86/gdb/config/rs6000/tm-rs6000-aix4.h
		 gdb-4.17.86/gdb/config/rs6000/tm-rs6000.h
		 gdb-4.17.86/gdb/config/rs6000/tm-rs6000ly.h
    TM-SPARC.H : gdb-4.17.86/gdb/config/sparc/tm-sparc.h
		 gdb-4.17.86/gdb/config/sparc/tm-sparclet.h
		 gdb-4.17.86/gdb/config/sparc/tm-sparclite.h
		 gdb-4.17.86/gdb/config/sparc/tm-sparclynx.h
    TM-VR430.H : gdb-4.17.86/gdb/config/mips/tm-vr4300.h
		 gdb-4.17.86/gdb/config/mips/tm-vr4300el.h
    TM-VR500.H : gdb-4.17.86/gdb/config/mips/tm-vr5000.h
		 gdb-4.17.86/gdb/config/mips/tm-vr5000el.h
    TUISOURC.C : gdb-4.17.86/gdb/tui/tuiSource.c
		 gdb-4.17.86/gdb/tui/tuiSourceWin.c
    TUISOURC.H : gdb-4.17.86/gdb/tui/tuiSource.h
		 gdb-4.17.86/gdb/tui/tuiSourceWin.h
    XM-ALPHA.H : gdb-4.17.86/gdb/config/alpha/xm-alphalinux.h
		 gdb-4.17.86/gdb/config/alpha/xm-alphaosf.h
    XM-APOLL.H : gdb-4.17.86/gdb/config/m68k/xm-apollo68b.h
		 gdb-4.17.86/gdb/config/m68k/xm-apollo68v.h
    XM-DELTA.H : gdb-4.17.86/gdb/config/m88k/xm-delta88.h
		 gdb-4.17.86/gdb/config/m88k/xm-delta88v4.h
    XM-HP300.H : gdb-4.17.86/gdb/config/m68k/xm-hp300bsd.h
		 gdb-4.17.86/gdb/config/m68k/xm-hp300hpux.h
    XM-I386M.H : gdb-4.17.86/gdb/config/i386/xm-i386m3.h
		 gdb-4.17.86/gdb/config/i386/xm-i386mach.h
		 gdb-4.17.86/gdb/config/i386/xm-i386mk.h
    XM-I386V.H : gdb-4.17.86/gdb/config/i386/xm-i386v.h
		 gdb-4.17.86/gdb/config/i386/xm-i386v32.h
		 gdb-4.17.86/gdb/config/i386/xm-i386v4.h
    XM-RS600.H : gdb-4.17.86/gdb/config/rs6000/xm-rs6000.h
		 gdb-4.17.86/gdb/config/rs6000/xm-rs6000ly.h
    XM-SPARC.H : gdb-4.17.86/gdb/config/sparc/xm-sparc.h
		 gdb-4.17.86/gdb/config/sparc/xm-sparclynx.h
    XM-VAXUL.H : gdb-4.17.86/gdb/config/vax/xm-vaxult.h
		 gdb-4.17.86/gdb/config/vax/xm-vaxult2.h

The following resolve to the same SysV file names:
filter_filenam : gdb-4.17.86/sim/ppc/filter_filename.c
		 gdb-4.17.86/sim/ppc/filter_filename.h
gen-semantics. : gdb-4.17.86/sim/igen/gen-semantics.c
		 gdb-4.17.86/sim/igen/gen-semantics.h
gen-semantics. : gdb-4.17.86/sim/ppc/gen-semantics.c
		 gdb-4.17.86/sim/ppc/gen-semantics.h
hw-properties. : gdb-4.17.86/sim/common/hw-properties.c
		 gdb-4.17.86/sim/common/hw-properties.h
tuiGeneralWin. : gdb-4.17.86/gdb/tui/tuiGeneralWin.c
		 gdb-4.17.86/gdb/tui/tuiGeneralWin.h

The following file names are too long for SysV:
ChangeLog.Cygn : gdb-4.17.86/intl/ChangeLog.Cygnus
a1-selftest.ex : gdb-4.17.86/gdb/testsuite/gdb.base/a1-selftest.exp
cma_debug_clie : gdb-4.17.86/gdb/osf-share/cma_debug_client.h
cma_semaphore_ : gdb-4.17.86/gdb/osf-share/cma_semaphore_defs.h
cma_stack_int. : gdb-4.17.86/gdb/osf-share/cma_stack_int.h
cma_thread_io. : gdb-4.17.86/gdb/osf-share/AT386/cma_thread_io.h
cma_thread_io. : gdb-4.17.86/gdb/osf-share/HP800/cma_thread_io.h
cma_thread_io. : gdb-4.17.86/gdb/osf-share/RIOS/cma_thread_io.h
emc-support.ex : gdb-4.17.86/gdb/testsuite/lib/emc-support.exp
exc_request.de : gdb-4.17.86/gdb/exc_request.defs
execd-program. : gdb-4.17.86/gdb/testsuite/gdb.hp/execd-program.c
extstruct-grt. : gdb-4.17.86/gdb/testsuite/gdb.chill/extstruct-grt.ch
forward-includ : gdb-4.17.86/config/mpw/forward-include
gen-so-thresh. : gdb-4.17.86/gdb/testsuite/gdb.hp/gen-so-thresh.c
hp-psymtab-rea : gdb-4.17.86/gdb/hp-psymtab-read.c
hp-symtab-read : gdb-4.17.86/gdb/hp-symtab-read.c
idecode_branch : gdb-4.17.86/sim/ppc/idecode_branch.h
idecode_expres : gdb-4.17.86/sim/ppc/idecode_expression.h
idecode_fields : gdb-4.17.86/sim/ppc/idecode_fields.h
m68klinux-nat. : gdb-4.17.86/gdb/m68klinux-nat.c
mn10300-eval.e : gdb-4.17.86/gdb/testsuite/config/mn10300-eval.exp
ns32knbsd-nat. : gdb-4.17.86/gdb/ns32knbsd-nat.c
ppc-cache-rule : gdb-4.17.86/sim/ppc/ppc-cache-rules
ppc-instructio : gdb-4.17.86/sim/ppc/ppc-instructions
process_reply. : gdb-4.17.86/gdb/process_reply.defs
remote-vxmips. : gdb-4.17.86/gdb/remote-vxmips.c
remote-vxsparc : gdb-4.17.86/gdb/remote-vxsparc.c
reply_mig_hack : gdb-4.17.86/gdb/reply_mig_hack.awk
sim_callbacks. : gdb-4.17.86/sim/ppc/sim_callbacks.h
so-thresh.link : gdb-4.17.86/gdb/testsuite/gdb.hp/so-thresh.linkopts
sparclet-stub. : gdb-4.17.86/gdb/sparclet-stub.c
tm-alphalinux. : gdb-4.17.86/gdb/config/alpha/tm-alphalinux.h
tm-ppcle-eabi. : gdb-4.17.86/gdb/config/powerpc/tm-ppcle-eabi.h
tm-rs6000-aix4 : gdb-4.17.86/gdb/config/rs6000/tm-rs6000-aix4.h
trace-support. : gdb-4.17.86/gdb/testsuite/lib/trace-support.exp
vforked-progra : gdb-4.17.86/gdb/testsuite/gdb.hp/vforked-program.c
while-stepping : gdb-4.17.86/gdb/testsuite/gdb.trace/while-stepping.exp
xm-alphalinux. : gdb-4.17.86/gdb/config/alpha/xm-alphalinux.h
******************************************************
* email:   Robert Hoehne <robert.hoehne@gmx.net>     *
* Post:    Am Berg 3, D-09573 Dittmannsdorf, Germany *
* WWW:     http://www.tu-chemnitz.de/~sho/rho        *
******************************************************

Re: DJGPP support (was libgdb)

[Stan Shebs]

   From: Robert Hoehne <robert.hoehne@gmx.net>
   Date: Sun, 14 Mar 1999 13:20:40 +0100

   > But how is anybody supposed to know what can be changed and what not?
   Of course nobody can imagine what the mainatainer
   of GDB will do with the sources (except of course the mainatiner itself).

True, although if something is a documented requirement, maintainers
should be loath to remove it.  I can't remember the last time a command
documented in the manual was taken out, for instance, even though there
are some pretty dubious things in there.

   I really don't understand, why you are against such small changes
   which doesn't affect any behaviour of GDB but which will help the
   programming of others. (for instance simply moving the newly
   introduced global variables from main.c to top.c)

I'm not personally against doing this, in fact it seems like an easy
and reasonable thing to do.  However, I also need to be able to
document this adequately somewhere, so that the next ambitious person
who comes along doesn't unknowingly undo this change.  For instance,
HP now has a newly-formed GDB group in Cupertino - how will they know
what they can change freely and what to leave alone?

   I have leaned that already :-( But at this point I really don't understand,
   why the the mainatainers of GNU tools nearly ever forget when introducing
   new features, that there are also people, which use the GNU environment
   for DOS called DJGPP where are some limitations exist. And as I have
   heared, the GNU cdrom with DJGPP on it was a hit.

   Sometimes I think, the GNU mainatiner have something against DJGPP.

I'm sorry if you have that impression, it's certainly not the case.
Hey, back when I was doing Mac ports, a lot of people disapproved of
*me*! so I know what it feels like to port to and support a
non-standard configuration.

But I'm glad you brought this issue up.  For a long time, it has been
the policy of the FSF not to expend much effort on DOS support.  For
instance, there is this bit in etc/standards.texi:

"As for systems that are not like Unix, such as MSDOS, Windows, the
Macintosh, VMS, and MVS, supporting them is usually so much work that it
is better if you don't."

Although later on there is this, in a discussion of packaging for
release:

"Try to make sure that all the file names will be unique on MS-DOS."

And as you say, DJGPP is a popular port of GNU, and is being actively
maintained.

Since I'm a portability fanatic, I'm all in favor of making GDB
support DJGPP, and making any changes necessary to enable this in the
standard version of GDB.  However, since GDB includes modules like
readline and bfd, it's also important to have at least the GDB-related
package maintainers agree to support DJGPP, if not GCC, GAS, LD, etc.

I would also like to get the FSF coding standards modified.  RMS owns
the standard, so you or DJ or somebody should send him mail pointing
out that the standards would seem to discourage support for packages
like DJGPP, and could he please modify it to provide better guidance
for maintainers on this point.

							Stan

Re: DJGPP support (was libgdb)

[Stan Shebs]

   From: Robert Hoehne <robert.hoehne@gmx.net>
   Date: Sun, 14 Mar 1999 13:20:40 +0100

   > But how is anybody supposed to know what can be changed and what not?
   Of course nobody can imagine what the mainatainer
   of GDB will do with the sources (except of course the mainatiner itself).

True, although if something is a documented requirement, maintainers
should be loath to remove it.  I can't remember the last time a command
documented in the manual was taken out, for instance, even though there
are some pretty dubious things in there.

   I really don't understand, why you are against such small changes
   which doesn't affect any behaviour of GDB but which will help the
   programming of others. (for instance simply moving the newly
   introduced global variables from main.c to top.c)

I'm not personally against doing this, in fact it seems like an easy
and reasonable thing to do.  However, I also need to be able to
document this adequately somewhere, so that the next ambitious person
who comes along doesn't unknowingly undo this change.  For instance,
HP now has a newly-formed GDB group in Cupertino - how will they know
what they can change freely and what to leave alone?

   I have leaned that already :-( But at this point I really don't understand,
   why the the mainatainers of GNU tools nearly ever forget when introducing
   new features, that there are also people, which use the GNU environment
   for DOS called DJGPP where are some limitations exist. And as I have
   heared, the GNU cdrom with DJGPP on it was a hit.

   Sometimes I think, the GNU mainatiner have something against DJGPP.

I'm sorry if you have that impression, it's certainly not the case.
Hey, back when I was doing Mac ports, a lot of people disapproved of
*me*! so I know what it feels like to port to and support a
non-standard configuration.

But I'm glad you brought this issue up.  For a long time, it has been
the policy of the FSF not to expend much effort on DOS support.  For
instance, there is this bit in etc/standards.texi:

"As for systems that are not like Unix, such as MSDOS, Windows, the
Macintosh, VMS, and MVS, supporting them is usually so much work that it
is better if you don't."

Although later on there is this, in a discussion of packaging for
release:

"Try to make sure that all the file names will be unique on MS-DOS."

And as you say, DJGPP is a popular port of GNU, and is being actively
maintained.

Since I'm a portability fanatic, I'm all in favor of making GDB
support DJGPP, and making any changes necessary to enable this in the
standard version of GDB.  However, since GDB includes modules like
readline and bfd, it's also important to have at least the GDB-related
package maintainers agree to support DJGPP, if not GCC, GAS, LD, etc.

I would also like to get the FSF coding standards modified.  RMS owns
the standard, so you or DJ or somebody should send him mail pointing
out that the standards would seem to discourage support for packages
like DJGPP, and could he please modify it to provide better guidance
for maintainers on this point.

							Stan

Re: libgdb.a

[Andrew Cagney]

Andris Pavenis wrote:

> Maybe it would be usefull to implement init functions of higher priority that
> are executed before ones which names begins with _initialize_.
> So we would be able to avoid gcc related extensions such as
> __attribute__((constructor)).
>
> For that we should use a different name prefix (eg. _preinit_ or something like)
> and require that these functions are independent one from another one (should
> not use results of other similar init functions).

This has been discussed before (but on another list) and on the last occasion it
was actually me suggested something along similar lines to your proposal.  I lost
the the discussion :-)

The consensus was that if GDB started down the path of having two initialization
levels it could quickly find itself heading for a situtation where there were N
initialization levels and a really confused startup sequence.  It was thought that,
if anything, we should be trying to discourage additional complexity being
introduced during startup.

As an example, consider the idea (that was recently floated) of GDB suporting
several target-architectures.  Instead of fully initializing the code for all the
target-architectures during startup, it would probably be more prudent to leave
most of that task until the point where GDB knew exactly which architecture was
being debugged.

    enjoy,
        Andrew

Re: libgdb.a

[J.T. Conklin]

>>>>> "cagney" == Andrew Cagney <ac131313@cygnus.com> writes:
cagney> Andris Pavenis wrote:
>> Maybe it would be usefull to implement init functions of higher
>> priority that are executed before ones which names begins with
>> _initialize_.  So we would be able to avoid gcc related extensions
>> such as __attribute__((constructor)).
>> 
>> For that we should use a different name prefix (eg. _preinit_ or
>> something like) and require that these functions are independent
>> one from another one (should not use results of other similar init
>> functions).

cagney> This has been discussed before (but on another list) and on
cagney> the last occasion it was actually me suggested something along
cagney> similar lines to your proposal.  I lost the the discussion :-)

cagney> The consensus was that if GDB started down the path of having
cagney> two initialization levels it could quickly find itself heading
cagney> for a situtation where there were N initialization levels and
cagney> a really confused startup sequence.  It was thought that, if
cagney> anything, we should be trying to discourage additional
cagney> complexity being introduced during startup.

I'd have to agree that adding another layer of initialization starts
down a slippery slope.  But taken to its logical conclusion, perhaps
its a slope worth sliding down.

GDB is built from a "core" set of code which is common to all hosts
and targets, and assorted modules that may or may not be bound into
the image.  Neither the core nor the modules have any knowledge of
each other.  

Module initialization functions are identified by a script (embedded
in the Makefile) that extracts names of functions with names of the
form `_initialize_*' from the objects that will be linked into GDB.
These names are used to construct a C file, init.c.  When compiled and
linked with the rest of the objects, GDB iterates through the array of
init functions calling each in sequence.  That sequence is essentially
random -- it depends on which order the objects are processed.

But what if instead of collecting the names of init functions, init.c
was constructed by collecting the names of module identifiers.  A
module identifier struct might look something like follows:

	struct module_id {
		int magic;
		char *module_name;
		char *req;
		char *pre;
		void (*func)(void);
	};

A module instance might be something like this:

	struct module_id _module_ser_tcp = {
		MODULE_MAGIC,
		"ser_tcp",
		"ser, foo, bar, baz",
		"ser",
		_initialize_ser_tcp
	};

To explain, this defines a module "ser_tcp", it requires the modules
"ser", "foo", "bar", and "baz" to be present in the image; and it
requires from the constructor for the module "ser" be run before it's
own constructor.  A simple dependency engine could 1) determine that
all required modules are present; 2) determine that there are no
circular dependencies; and then 3) execute the init functions in the
desired order.

There are obvious avenues for improvement for this idea (e.g, you
might want some way to indicate a module is optional, but if it is
present its init function must be run first; a mechanism for
dynamically loading GDB modules; versioning modules; etc).

I've worked on systems with a similar mechanism, and believe that it
could be made to work for GDB if someone wanted to go down this path.
IMO it is much superior to simply adding another layer (or layers) of
init functions.

cagney> As an example, consider the idea (that was recently floated)
cagney> of GDB suporting several target-architectures.  Instead of
cagney> fully initializing the code for all the target-architectures
cagney> during startup, it would probably be more prudent to leave
cagney> most of that task until the point where GDB knew exactly which
cagney> architecture was being debugged.

	--jtc

-- 
J.T. Conklin
RedBack Networks

Re: libgdb.a

[J.T. Conklin]

>>>>> "cagney" == Andrew Cagney <ac131313@cygnus.com> writes:
cagney> Andris Pavenis wrote:
>> Maybe it would be usefull to implement init functions of higher
>> priority that are executed before ones which names begins with
>> _initialize_.  So we would be able to avoid gcc related extensions
>> such as __attribute__((constructor)).
>> 
>> For that we should use a different name prefix (eg. _preinit_ or
>> something like) and require that these functions are independent
>> one from another one (should not use results of other similar init
>> functions).

cagney> This has been discussed before (but on another list) and on
cagney> the last occasion it was actually me suggested something along
cagney> similar lines to your proposal.  I lost the the discussion :-)

cagney> The consensus was that if GDB started down the path of having
cagney> two initialization levels it could quickly find itself heading
cagney> for a situtation where there were N initialization levels and
cagney> a really confused startup sequence.  It was thought that, if
cagney> anything, we should be trying to discourage additional
cagney> complexity being introduced during startup.

I'd have to agree that adding another layer of initialization starts
down a slippery slope.  But taken to its logical conclusion, perhaps
its a slope worth sliding down.

GDB is built from a "core" set of code which is common to all hosts
and targets, and assorted modules that may or may not be bound into
the image.  Neither the core nor the modules have any knowledge of
each other.  

Module initialization functions are identified by a script (embedded
in the Makefile) that extracts names of functions with names of the
form `_initialize_*' from the objects that will be linked into GDB.
These names are used to construct a C file, init.c.  When compiled and
linked with the rest of the objects, GDB iterates through the array of
init functions calling each in sequence.  That sequence is essentially
random -- it depends on which order the objects are processed.

But what if instead of collecting the names of init functions, init.c
was constructed by collecting the names of module identifiers.  A
module identifier struct might look something like follows:

	struct module_id {
		int magic;
		char *module_name;
		char *req;
		char *pre;
		void (*func)(void);
	};

A module instance might be something like this:

	struct module_id _module_ser_tcp = {
		MODULE_MAGIC,
		"ser_tcp",
		"ser, foo, bar, baz",
		"ser",
		_initialize_ser_tcp
	};

To explain, this defines a module "ser_tcp", it requires the modules
"ser", "foo", "bar", and "baz" to be present in the image; and it
requires from the constructor for the module "ser" be run before it's
own constructor.  A simple dependency engine could 1) determine that
all required modules are present; 2) determine that there are no
circular dependencies; and then 3) execute the init functions in the
desired order.

There are obvious avenues for improvement for this idea (e.g, you
might want some way to indicate a module is optional, but if it is
present its init function must be run first; a mechanism for
dynamically loading GDB modules; versioning modules; etc).

I've worked on systems with a similar mechanism, and believe that it
could be made to work for GDB if someone wanted to go down this path.
IMO it is much superior to simply adding another layer (or layers) of
init functions.

cagney> As an example, consider the idea (that was recently floated)
cagney> of GDB suporting several target-architectures.  Instead of
cagney> fully initializing the code for all the target-architectures
cagney> during startup, it would probably be more prudent to leave
cagney> most of that task until the point where GDB knew exactly which
cagney> architecture was being debugged.

	--jtc

-- 
J.T. Conklin
RedBack Networks

Re: libgdb.a

[Andrew Cagney]

Andris Pavenis wrote:

> Maybe it would be usefull to implement init functions of higher priority that
> are executed before ones which names begins with _initialize_.
> So we would be able to avoid gcc related extensions such as
> __attribute__((constructor)).
>
> For that we should use a different name prefix (eg. _preinit_ or something like)
> and require that these functions are independent one from another one (should
> not use results of other similar init functions).

This has been discussed before (but on another list) and on the last occasion it
was actually me suggested something along similar lines to your proposal.  I lost
the the discussion :-)

The consensus was that if GDB started down the path of having two initialization
levels it could quickly find itself heading for a situtation where there were N
initialization levels and a really confused startup sequence.  It was thought that,
if anything, we should be trying to discourage additional complexity being
introduced during startup.

As an example, consider the idea (that was recently floated) of GDB suporting
several target-architectures.  Instead of fully initializing the code for all the
target-architectures during startup, it would probably be more prudent to leave
most of that task until the point where GDB knew exactly which architecture was
being debugged.

    enjoy,
        Andrew

Re: libgdb.a

[Todd Whitesel]

>target-architectures during startup, it would probably be more prudent to leave
>most of that task until the point where GDB knew exactly which architecture was
>being debugged.

Yes, and this sounds like an example where multi-level initialization is a
Good Thing(TM).

I would love it if more things in GDB were "constructored" and not #define'd
or hardcoded. Right now (read 4.17) with many remote targets you can't know
the exact register list until you probe the target to find out what it is,
yet the reg_names[] array is statically initialized (because on ptrace unix
platforms that Just Worked), and we're just lucky that the rest of GDB adapts
well to having reg_names[] edited after initialization.

-- 
Todd Whitesel
toddpw @ wrs.com

Re: libgdb.a

[Todd Whitesel]

>target-architectures during startup, it would probably be more prudent to leave
>most of that task until the point where GDB knew exactly which architecture was
>being debugged.

Yes, and this sounds like an example where multi-level initialization is a
Good Thing(TM).

I would love it if more things in GDB were "constructored" and not #define'd
or hardcoded. Right now (read 4.17) with many remote targets you can't know
the exact register list until you probe the target to find out what it is,
yet the reg_names[] array is statically initialized (because on ptrace unix
platforms that Just Worked), and we're just lucky that the rest of GDB adapts
well to having reg_names[] edited after initialization.

-- 
Todd Whitesel
toddpw @ wrs.com

Re: libgdb.a

[Stan Shebs]

   From: toddpw@wrs.com (Todd Whitesel)
   Date: Wed, 10 Mar 1999 16:56:04 -0800 (PST)

   I would love it if more things in GDB were "constructored" and not #define'd
   or hardcoded. Right now (read 4.17) with many remote targets you can't know
   the exact register list until you probe the target to find out what it is,
   yet the reg_names[] array is statically initialized (because on ptrace unix
   platforms that Just Worked), and we're just lucky that the rest of GDB adapts
   well to having reg_names[] edited after initialization.

As I mentioned a couple weeks ago to one of the lists, more dynamic
construction is the way to go in the future.  One thing that individuals
can do now to ease the transition is to avoid ifdefs in their patches.
It should be clear to everyone that a GDB littered with target ifdefs
is not going to be able to make runtime choices about anything.  So,
avoid the ifdef!

								Stan

Re: libgdb.a

[Stan Shebs]

   From: toddpw@wrs.com (Todd Whitesel)
   Date: Wed, 10 Mar 1999 16:56:04 -0800 (PST)

   I would love it if more things in GDB were "constructored" and not #define'd
   or hardcoded. Right now (read 4.17) with many remote targets you can't know
   the exact register list until you probe the target to find out what it is,
   yet the reg_names[] array is statically initialized (because on ptrace unix
   platforms that Just Worked), and we're just lucky that the rest of GDB adapts
   well to having reg_names[] edited after initialization.

As I mentioned a couple weeks ago to one of the lists, more dynamic
construction is the way to go in the future.  One thing that individuals
can do now to ease the transition is to avoid ifdefs in their patches.
It should be clear to everyone that a GDB littered with target ifdefs
is not going to be able to make runtime choices about anything.  So,
avoid the ifdef!

								Stan

Re: libgdb.a

[Andris Pavenis]

On Thu, 11 Mar 1999, Andrew Cagney wrote:
>Andris Pavenis wrote:
>
>> Maybe it would be usefull to implement init functions of higher priority that
>> are executed before ones which names begins with _initialize_.
>> So we would be able to avoid gcc related extensions such as
>> __attribute__((constructor)).
>>
>> For that we should use a different name prefix (eg. _preinit_ or something like)
>> and require that these functions are independent one from another one (should
>> not use results of other similar init functions).
>
>This has been discussed before (but on another list) and on the last occasion it
>was actually me suggested something along similar lines to your proposal.  I lost
>the the discussion :-)
>
>The consensus was that if GDB started down the path of having two initialization
>levels it could quickly find itself heading for a situtation where there were N
>initialization levels and a really confused startup sequence.  It was thought that,
>if anything, we should be trying to discourage additional complexity being
>introduced during startup.
>
>As an example, consider the idea (that was recently floated) of GDB suporting
>several target-architectures.  Instead of fully initializing the code for all the
>target-architectures during startup, it would probably be more prudent to leave
>most of that task until the point where GDB knew exactly which architecture was
>being debugged.
>

Yes I agree that introducing more initialization levels maybe not acceptable. 
Anyway if we should change interface for libgdb.a then it's best do
do it now in such way we probably won't need to do it again soon (Introducing 
typedef GDB_FILE is already such change) . I suggest follwing:

	1) move definitions of such variables to separate file out of main.c
	2) move initialization of these variables to the same file and create 
                procedure that initializes tham.
            3) call this newly introduced procedure from very begin of main

As the result we'll be able to place newly introduced file in libgdb.a. Perhaps
it would be best to add some C preprocessor macro so programs that uses
libgdb.a could found that at compile time.

So we could move such initialization to a separate file that could be included
in libgdb.a. Of course programs that uses libgdb.a will have to call init
function at first. 

Andris

PS. I'm not subscribed to this list. So please CC: answer to me


 

Re: libgdb.a

[Andris Pavenis]

On Thu, 11 Mar 1999, Andrew Cagney wrote:
>Andris Pavenis wrote:
>
>> Maybe it would be usefull to implement init functions of higher priority that
>> are executed before ones which names begins with _initialize_.
>> So we would be able to avoid gcc related extensions such as
>> __attribute__((constructor)).
>>
>> For that we should use a different name prefix (eg. _preinit_ or something like)
>> and require that these functions are independent one from another one (should
>> not use results of other similar init functions).
>
>This has been discussed before (but on another list) and on the last occasion it
>was actually me suggested something along similar lines to your proposal.  I lost
>the the discussion :-)
>
>The consensus was that if GDB started down the path of having two initialization
>levels it could quickly find itself heading for a situtation where there were N
>initialization levels and a really confused startup sequence.  It was thought that,
>if anything, we should be trying to discourage additional complexity being
>introduced during startup.
>
>As an example, consider the idea (that was recently floated) of GDB suporting
>several target-architectures.  Instead of fully initializing the code for all the
>target-architectures during startup, it would probably be more prudent to leave
>most of that task until the point where GDB knew exactly which architecture was
>being debugged.
>

Yes I agree that introducing more initialization levels maybe not acceptable. 
Anyway if we should change interface for libgdb.a then it's best do
do it now in such way we probably won't need to do it again soon (Introducing 
typedef GDB_FILE is already such change) . I suggest follwing:

	1) move definitions of such variables to separate file out of main.c
	2) move initialization of these variables to the same file and create 
                procedure that initializes tham.
            3) call this newly introduced procedure from very begin of main

As the result we'll be able to place newly introduced file in libgdb.a. Perhaps
it would be best to add some C preprocessor macro so programs that uses
libgdb.a could found that at compile time.

So we could move such initialization to a separate file that could be included
in libgdb.a. Of course programs that uses libgdb.a will have to call init
function at first. 

Andris

PS. I'm not subscribed to this list. So please CC: answer to me


 

Re: libgdb.a

[Andris Pavenis]

On Mon, 08 Mar 1999, Andris Pavenis wrote:
>Hi!
>
>Tried gdb-4.17.85 on i586-pc-linux-gnu (with glibc-2.1) and met following
>problem that was no with gdb-4.17:
>
>Some global symbols are defined in gdb/main.c (eg. gdb_stdout,
>gdb-stderr, etc). As the result if I'm building all except main.c in
>object library to use with some IDE that uses gdb for debugging 
>(rhide-1.4.7),  I'm getting unresolved references. 
>
>So I'm suggesting rather ugly hack (moving these definitions to top.c
>and puting there static constructor that initializes gdb_std*). I agree does
>not look nice, but I'm sending it only to point to possible problem.
>I cannot use _initialize_* here as files must be defined before running
>all _initialize_* procedures.
>

Maybe it would be usefull to implement init functions of higher priority that
are executed before ones which names begins with _initialize_. 
So we would be able to avoid gcc related extensions such as 
__attribute__((constructor)). 

For that we should use a different name prefix (eg. _preinit_ or something like)
and require that these functions are independent one from another one (should
not use results of other similar init functions).

Andris

Please send answers also to me as I'm not subscribed to gdb-patches

Re: libgdb.a

[Andris Pavenis]

On Mon, 08 Mar 1999, Andris Pavenis wrote:
>Hi!
>
>Tried gdb-4.17.85 on i586-pc-linux-gnu (with glibc-2.1) and met following
>problem that was no with gdb-4.17:
>
>Some global symbols are defined in gdb/main.c (eg. gdb_stdout,
>gdb-stderr, etc). As the result if I'm building all except main.c in
>object library to use with some IDE that uses gdb for debugging 
>(rhide-1.4.7),  I'm getting unresolved references. 
>
>So I'm suggesting rather ugly hack (moving these definitions to top.c
>and puting there static constructor that initializes gdb_std*). I agree does
>not look nice, but I'm sending it only to point to possible problem.
>I cannot use _initialize_* here as files must be defined before running
>all _initialize_* procedures.
>

Maybe it would be usefull to implement init functions of higher priority that
are executed before ones which names begins with _initialize_. 
So we would be able to avoid gcc related extensions such as 
__attribute__((constructor)). 

For that we should use a different name prefix (eg. _preinit_ or something like)
and require that these functions are independent one from another one (should
not use results of other similar init functions).

Andris

Please send answers also to me as I'm not subscribed to gdb-patches

No Subject

[Andris Pavenis]

Hi!

Tried gdb-4.17.85 on i586-pc-linux-gnu (with glibc-2.1) and met following
problem that was no with gdb-4.17:

Some global symbols are defined in gdb/main.c (eg. gdb_stdout,
gdb-stderr, etc). As the result if I'm building all except main.c in
object library to use with some IDE that uses gdb for debugging 
(rhide-1.4.7),  I'm getting unresolved references. 

So I'm suggesting rather ugly hack (moving these definitions to top.c
and puting there static constructor that initializes gdb_std*). I agree does
not look nice, but I'm sending it only to point to possible problem.
I cannot use _initialize_* here as files must be defined before running
all _initialize_* procedures.

An alternative idea could be duplicating init code and global vrariables in
rhide.

Andris


--- main.c~1	Wed Feb 24 22:55:05 1999
+++ main.c	Mon Mar  8 16:38:44 1999
@@ -54,18 +54,6 @@
 
 int display_space;
 
-/* Whether this is the command line version or not */
-int tui_version = 0;
-
-/* Whether xdb commands will be handled */
-int xdb_commands = 0;
-
-/* Whether dbx commands will be handled */
-int dbx_commands = 0;
-
-GDB_FILE *gdb_stdout;
-GDB_FILE *gdb_stderr;
-
 /* Whether to enable writing into executable and core files */
 extern int write_files;
 
@@ -161,20 +149,6 @@
 
   getcwd (gdb_dirbuf, sizeof (gdb_dirbuf));
   current_directory = gdb_dirbuf;
-
-  gdb_file_size = sizeof(GDB_FILE);
-
-  gdb_stdout = (GDB_FILE *)xmalloc (gdb_file_size);
-  gdb_stdout->ts_streamtype = afile;
-  gdb_stdout->ts_filestream = stdout;
-  gdb_stdout->ts_strbuf = NULL;
-  gdb_stdout->ts_buflen = 0;
-
-  gdb_stderr = (GDB_FILE *)xmalloc (gdb_file_size);
-  gdb_stderr->ts_streamtype = afile;
-  gdb_stderr->ts_filestream = stderr;
-  gdb_stderr->ts_strbuf = NULL;
-  gdb_stderr->ts_buflen = 0;
 
   /* Parse arguments and options.  */
   {
--- top.c~1	Fri Jan 29 11:46:03 1999
+++ top.c	Mon Mar  8 16:37:03 1999
@@ -53,6 +53,19 @@
 
 extern void initialize_utils PARAMS ((void));
 
+
+/* Whether this is the command line version or not */
+int tui_version = 0;
+
+/* Whether xdb commands will be handled */
+int xdb_commands = 0;
+
+/* Whether dbx commands will be handled */
+int dbx_commands = 0;
+
+GDB_FILE *gdb_stdout;
+GDB_FILE *gdb_stderr;
+
 /* Prototypes for local functions */
 
 static void dont_repeat_command PARAMS ((char *, int));
@@ -467,6 +480,28 @@
 SIGJMP_BUF error_return;
 /* Where to go for return_to_top_level (RETURN_QUIT).  */
 SIGJMP_BUF quit_return;
+
+
+
+void __attribute__((constructor))
+_init_gdb_stdio (void)
+{
+  int gdb_file_size;
+  gdb_file_size = sizeof(GDB_FILE);
+
+  gdb_stdout = (GDB_FILE *)xmalloc (gdb_file_size);
+  gdb_stdout->ts_streamtype = afile;
+  gdb_stdout->ts_filestream = stdout;
+  gdb_stdout->ts_strbuf = NULL;
+  gdb_stdout->ts_buflen = 0;
+
+  gdb_stderr = (GDB_FILE *)xmalloc (gdb_file_size);
+  gdb_stderr->ts_streamtype = afile;
+  gdb_stderr->ts_filestream = stderr;
+  gdb_stderr->ts_strbuf = NULL;
+  gdb_stderr->ts_buflen = 0;
+}
+
 
 /* Return for reason REASON.  This generally gets back to the command
    loop, but can be caught via catch_errors.  */