* Re: Next release of GDB
1999-09-02 18:20 Next release of GDB Stan Shebs
@ 1999-09-08 12:54 ` J. Kean Johnston
0 siblings, 0 replies; 2+ messages in thread
From: J. Kean Johnston @ 1999-09-08 12:54 UTC (permalink / raw)
To: Stan Shebs, gdb
On Thu, Sep 02, 1999 at 06:20:49PM -0700, Stan Shebs wrote:
> There are probably many other important things that I'm forgetting,
> please speak up and remind me about them!
Completed SCO OpenServer and SCO UnixWare 7 support, especially
hardware assisted watch/breakpoints on UW7, thread support on UW7
and other general things I never got done in time for 4.18. The
tentative schedule you mentioned suits me fine, as I now have
official sanction from SCO to work in this and a few EGCS bugs.
If you (or anyone else) on this list is capable of (or even just
willing to) help out, I can provide copies of UnixWare 7 and even
refer to our own debugger source if I have to. I try to remain
uncontaminated though, and all my patches are approved by my own
management before submission, so everything is "safe" and covered
by my copyright assignment. I really would *LIKE* to see someone
else help out, especially with UnixWare 7, which is a good UNIX
and worth attention (and I say that as a UNIX biggot, not as an
SCO employee) :-)
--
J. Kean Johnston | "Only the dead have seen an end to war"
Engineer, SPG | -- Plato
Santa Cruz, CA +----------------------------------------------------------
Tel: 831-427-7569 Fax: 831-429-1887 E-mail: jkj@sco.com
From jimb@cygnus.com Wed Sep 08 16:25:00 1999
From: Jim Blandy <jimb@cygnus.com>
To: Jake Colman <colman@ppllc.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb performance is impossible!!
Date: Wed, 08 Sep 1999 16:25:00 -0000
Message-id: <npaeqxdm2z.fsf@zwingli.cygnus.com>
References: <76hfl6olbx.fsf@ppllc.com>
X-SW-Source: 1999-q3/msg00314.html
Content-length: 403
> We just switched our large application from the SunPro compiler to
> GCC 2.95.1. This required us to switch from dbx to gdb 4.18. We
> have found that gdb's performance is incredibly slow - so much so as
> to make it pretty much unusable. I've got to beleive that this is
> something unique to us since I know that gdb is considered an
> excellent debugger.
What operation, specifically, is slow?
From ovidiu@cup.hp.com Wed Sep 08 18:10:00 1999
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: libGDB architecture
Date: Wed, 08 Sep 1999 18:10:00 -0000
Message-id: <199909090109.SAA00500@hpcll563.cup.hp.com>
References: <199909081917.MAA12432@andros.cygnus.com>
X-SW-Source: 1999-q3/msg00315.html
Content-length: 5125
Stan,
I don't plan to export all the idiosyncrasies used internally in GDB, I never
said that. I think however that we can safely expose things that are generic
enough so that they don't change over time (or at least we don't expect them to
;-).
To be sure that people don't actually use our internal private data members, we
can simply make the structures opaque pointers and provide functions that take
them as an argument and perform the appropriate action. We can now come up with
a header file, libgdb.h (that doesn't include any other GDB header file) and
that defines the API we're exporting.
In the case of breakpoints for example, we would have something like this in
libgdb.h:
typedef void * CORE_ADDR;
struct breakpoint *new_breakpoint_at (CORE_ADDR address);
void enable_breakpoint (struct breakpoint *breakpoint);
boolean breakpoint_enabled_p (struct breakpoint *breakpoint);
void disable_breakpoint (struct breakpoint *breakpoint);
boolean breakpoint_disabled_p (struct breakpoint *breakpoint);
int breakpoint_number (struct breakpoint *breakpoint);
CORE_ADDR breakpoint_address (struct breakpoint *breakpoint);
int breakpoint_line_number (struct breakpoint *breakpoint);
const char *breakpoint_source_file (struct breakpoint *breakpoint);
struct breakpoint **all_breakpoints (void);
And so on for all the functionality that we want to export.
The functionality that we export should be sufficient to be able to write
programs in an interpreted language that could drive a full debugging session.
Imagine that you would have to rewrite the whole testsuite in the interpreted
language of your choice using this API, and you get a feeling of what needs to
be exported.
The important thing here is that we need to make sure that all the functions in
the API don't have any side effect of printing to any of the streams. The
printing should be done instead in another set of functions, specifically
designed for the GDB's interaction with the command line.
The breakpoint example above is pretty simplistic, but most of the API looks
like this. There are some questions that we still need to ask when we come down
to values and types, depending on what level of manipulation we want to have
here.
I will post a design design document in the next few days describing this
proposal.
Regards,
Ovidiu
On Wed, 8 Sep 1999 12:17:59 -0700, Stan Shebs <shebs@cygnus.com> wrote:
>
> Date: Mon, 06 Sep 1999 22:51:48 -0700
> From: Ovidiu Predescu <ovidiu@cup.hp.com>
>
> My proposal is essentially the same set of C functions as yours but this time
> they live in the GDB process. The API includes functions to access the GDB's
> functionality and, in addition, it exports some of the internal GDB's
> structures either as opaque pointers or as structures that contain general
> enough members that don't modify over time. (So the answer to your question
> "how close is close?" is "very close" ;-)
>
> The flaw in the ointment here is that GDB's internal data structures
> are just that - internal. They were not designed to be exposed
> outside of GDB's control structure. Now in practice, some things are
> easy, such as the enable bit for breakpoints. But what about
> breakpoint numbers? Should every libgdb client be expected to deal
> with negative numbers, and to know that these are "internal"
> breakpoints? What about the extra frame info? Its format varies
> wildly depending on target arch, and varies from release to release as
> well, and yet for many architectures you can't make sense of a frame
> without it.
>
> So while I think we want to make the interface as close to GDB
> internals as possible, it would be irresponsible to say "here, just
> include frame.h and breakpoint.h". We do need to define an API that
> can remain fairly stable while things churn underneath. You will need
> this in order to cope with the next round of GDB changes; for
> instance, ideas on the horizon include multi-process debug (inferior
> state globals disappear) and non-flat memory maps (CORE_ADDR becomes a
> struct). I'm not willing to be told "you can't change anything
> anymore because it would break libgdb", and I don't think you want to
> be stuck with an old version of GDB because you don't have the
> resources to update client code that depends on evolving internals.
>
> One thing that I'd like to see at this point is a more concrete
> description of what libgdb clients ought to have at their disposal.
> Does the set of objects and operations look more like an abstractified
> version of the command-line interface, and more like an abstraction of
> existing internals? It's going to be hard to make a good choice
> unless we have a concrete list of object types and a concrete list of
> desired properties/operations. Also, the list needs to be fairly
> complete, so that one's analysis isn't misdirected by single cases,
> such as breakpoint objects. My intuition is that the overall list
> should look more like the command-line interface, but I've never yet
> seen a complete list that I can pore over and understand.
>
> Stan
>
>
^ permalink raw reply [flat|nested] 2+ messages in thread