From: Robert Hoehne <robert.hoehne@gmx.net>
To: gdb-patches@cygnus.com
Subject: Re: libgdb (was none)
Date: Thu, 01 Apr 1999 00:00:00 -0000 [thread overview]
Message-ID: <199903082231.OAA14675@cygnus.com> (raw)
In-Reply-To: <nppv6jvllo.fsf@zwingli.cygnus.com>
> > 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 *
******************************************************
WARNING: multiple messages have this Message-ID
From: Robert Hoehne <robert.hoehne@gmx.net>
To: gdb-patches@cygnus.com
Subject: Re: libgdb (was none)
Date: Mon, 08 Mar 1999 14:31:00 -0000 [thread overview]
Message-ID: <199903082231.OAA14675@cygnus.com> (raw)
Message-ID: <19990308143100.REV99qA6aM9i5ToomFg_n05MTZnELMX_VVMI8guCs_Y@z> (raw)
In-Reply-To: <nppv6jvllo.fsf@zwingli.cygnus.com>
> > 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 *
******************************************************
next prev parent reply other threads:[~1999-04-01 0:00 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-08 7:10 No Subject Andris Pavenis
1999-03-08 11:15 ` none Jim Blandy
1999-04-01 0:00 ` none Jim Blandy
1999-04-01 0:00 ` Robert Hoehne [this message]
1999-03-08 14:31 ` libgdb (was none) Robert Hoehne
1999-04-01 0:00 ` Stan Shebs
1999-03-10 15:39 ` Stan Shebs
1999-03-10 16:29 ` Todd Whitesel
1999-04-01 0:00 ` Todd Whitesel
1999-03-14 4:18 ` Robert Hoehne
1999-04-01 0:00 ` Robert Hoehne
1999-04-01 0:00 ` DJGPP support (was libgdb) Stan Shebs
1999-03-14 14:41 ` Stan Shebs
1999-04-01 0:00 ` none Stan Shebs
1999-03-08 13:09 ` none Stan Shebs
1999-03-09 12:54 ` none Robert Hoehne
1999-04-01 0:00 ` none Robert Hoehne
[not found] ` <99031011141900.03735.cygnus.patches.gdb@hal>
1999-03-10 16:31 ` libgdb.a Andrew Cagney
1999-04-01 0:00 ` libgdb.a J.T. Conklin
1999-03-11 14:29 ` libgdb.a J.T. Conklin
1999-04-01 0:00 ` libgdb.a Andris Pavenis
1999-03-11 0:27 ` libgdb.a Andris Pavenis
1999-04-01 0:00 ` libgdb.a Todd Whitesel
1999-03-10 16:56 ` libgdb.a Todd Whitesel
1999-03-11 12:40 ` libgdb.a Stan Shebs
1999-04-01 0:00 ` libgdb.a Stan Shebs
1999-04-01 0:00 ` libgdb.a Andrew Cagney
1999-04-01 0:00 ` libgdb.a Andris Pavenis
1999-03-10 1:14 ` libgdb.a Andris Pavenis
1999-04-01 0:00 ` No Subject Andris Pavenis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199903082231.OAA14675@cygnus.com \
--to=robert.hoehne@gmx.net \
--cc=gdb-patches@cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox