GDB in C++

GDB in C++

[Michael Eager]

I'd like to bring up what I think will be regarded as
heresy:  converting GDB to C++.

First, let me say that I'm not a fan of C++.  It's an
overly complex language with many faults.

That said, when I read and step through GDB code I see
significant portions which are clearly written in a way
which attempts to emulate classes, objects, and both
data and member encapsulation.

I also see some flaws in this emulation, some of which
affect performance, others which affect logic.  There
are also places where the encapsulation is broken.  All of
this makes debugging more difficult.

For example, in gdbarch handling, all (or almost all)
routines start with one or more asserts which check that
the routine is passed a pointer to an gdbarch specification.
Actually, they don't validate that this is a gdbarch, only
that the pointer is not NULL.  These routines and the asserts
are executed tens of thousands of times when running GDB.
If this were a real class, many of these asserts would be
unnecessary, since by construction, the "this" pointer would
be valid. Inlining would also improve performance, since it
would eliminate many function calls.

I'm repeatedly surprised to step over an assert and find
that either the state has changed or I hit a previously
set breakpoint.  There are significant side effects to
executing these asserts, which changes the apparent flow
of the program.  While asserts are a "good thing", hidden
side effects and especially side effects in asserts are a
"bad thing".  I think that many of these side effects would
disappear or at least become apparent if real classes were
used.

Some additional history:  many years ago I participated in
a major re-write of Sun Microsystem's DBX.  We converted
it from K&R style C to ANSI C which was compatible with C++.
I then re-wrote about 1/3 of DBX in a constrained subset of
C++, essentially C with Classes.  The handling of object files
(a.out and ELF), symbols, stabs, and shared libraries was
all converted to use classes.  The rewrite was quite successful
in adding new functionality and eliminating many bugs.

There are vestiges of K&R support in GDB, such as the PARAMS
function, but I believe that this is not universally used and
is out of date.  I think that concerns about availability of
C++ on currently supported hosts are also out of date.  As
a side effect, if GDB were written in C++, I think that the
support for C++ debugging would be forced to improve.

I'm out of town at the moment, being fitted with asbestos
undergarments and armor, getting ready for the anticipated
flames and brickbats.  I may be a bit slow in responding.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: GDB in C++

[Daniel Jacobowitz]

On Sat, Jun 30, 2007 at 07:56:32AM -0700, Michael Eager wrote:
> That said, when I read and step through GDB code I see
> significant portions which are clearly written in a way
> which attempts to emulate classes, objects, and both
> data and member encapsulation.
> 
> I also see some flaws in this emulation, some of which
> affect performance, others which affect logic.  There
> are also places where the encapsulation is broken.  All of
> this makes debugging more difficult.

I've seen this complain from at least three different people.

I'm in favor of switching to C++.  I'm not going to argue about it if
others disagree, but I'll offer to do most of the work if the
consensus is positive.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB in C++

[Joel Brobecker]

> I'm in favor of switching to C++.  I'm not going to argue about it if
> others disagree, but I'll offer to do most of the work if the
> consensus is positive.

I am against this change. I'm not going to argue either, because there
are some technical merits on both sides, and they have been discussed
to death.

However, I think that requiring a C++ compiler will make it harder
for some users to build GDB, just because C++ compilers are not
always as readily available as C compilers.

(like Daniel, end of discussion for me - we've already argued on this)

-- 
Joel

Re: GDB in C++

[Michael Eager]

Quoting Joel Brobecker <brobecker@adacore.com>:

> > I'm in favor of switching to C++.  I'm not going to argue about it if
> > others disagree, but I'll offer to do most of the work if the
> > consensus is positive.
>
> I am against this change. I'm not going to argue either, because there
> are some technical merits on both sides, and they have been discussed
> to death.
>
> However, I think that requiring a C++ compiler will make it harder
> for some users to build GDB, just because C++ compilers are not
> always as readily available as C compilers.

What currently supported hosts do not have a C++ compiler?

I think that this may have been a valid concern several years
ago, but I think the lack of C++ compilers is no longer the case.

--
Michael Eager     eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: GDB in C++

[Mark Kettenis]

> Date: Mon,  2 Jul 2007 20:45:10 -0700
> From: Michael Eager <eager@eagercon.com>
> 
> Quoting Joel Brobecker <brobecker@adacore.com>:
> 
> > > I'm in favor of switching to C++.  I'm not going to argue about it if
> > > others disagree, but I'll offer to do most of the work if the
> > > consensus is positive.
> >
> > I am against this change. I'm not going to argue either, because there
> > are some technical merits on both sides, and they have been discussed
> > to death.
> >
> > However, I think that requiring a C++ compiler will make it harder
> > for some users to build GDB, just because C++ compilers are not
> > always as readily available as C compilers.
> 
> What currently supported hosts do not have a C++ compiler?

If you consider GCC 2.95.3 a proper C++ compiler, probably none.  And
don't expect exception handling to work reliable.

> I think that this may have been a valid concern several years
> ago, but I think the lack of C++ compilers is no longer the case.

The lack of a standards compliant C++ compiler still is though.  You
can probably find a subset of the language that will work on all major
C++ compilers, but how are you going to enforce people to restrict
themselves to that subset?

Then there is the problem that with C++ compilers are generally slower
and need more memory than C compilers.  This is certainly true for
GCC.  We can currently build GDB on OpenBSD/mac68k and OpenBSD/vax on
machines with less than 32 MB of memory.  

Anyway, end of discussion as far as I'm concerned.

Re: GDB in C++

[Jan Kratochvil]

On Mon, 02 Jul 2007 03:35:29 +0200, Joel Brobecker wrote:
...
> However, I think that requiring a C++ compiler will make it harder
> for some users to build GDB, just because C++ compilers are not
> always as readily available as C compilers.

For a completeness pointing out there exists GObject - OO system of Gnome,
built on a plain crossplatform C, with rich OO features incl. multiple
inheritance by interfaces, reference counting, weak references,
messaging/notifications (called signals/closures) etc.

http://developer.gnome.org/doc/API/2.0/gobject/
sample of GtkVBox inheriting GtkBox:
	http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtkvbox.c?view=markup

It has full runtime assertion based type checking for developers
(--enable-debug=yes) while it has zero user-visible overhead as it is turned
off for the final releases.

It misses the C++-native exceptions / cleanups during the unwinding, though.
Also the developers are usually Gnome unaware and so I found out using such
Gnome standard OO systems does not make the code more friendly to them anyway.
Therefore I do not think it would be worth porting GDB on top of GObject.


Regards,
Jan

Re: GDB in C++

[Mark Kettenis]

> Date: Sun, 1 Jul 2007 16:53:55 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sat, Jun 30, 2007 at 07:56:32AM -0700, Michael Eager wrote:
> > That said, when I read and step through GDB code I see
> > significant portions which are clearly written in a way
> > which attempts to emulate classes, objects, and both
> > data and member encapsulation.
> > 
> > I also see some flaws in this emulation, some of which
> > affect performance, others which affect logic.  There
> > are also places where the encapsulation is broken.  All of
> > this makes debugging more difficult.
> 
> I've seen this complain from at least three different people.
> 
> I'm in favor of switching to C++.  I'm not going to argue about it if
> others disagree, but I'll offer to do most of the work if the
> consensus is positive.

My position on this subject has not been changed.  The more C++ code I
see, the more convinced I get that the language should die.

Mark

Re: GDB in C++

[Michael Eager]

Quoting Mark Kettenis <mark.kettenis@xs4all.nl>:

> > Date: Sun, 1 Jul 2007 16:53:55 -0400
> > From: Daniel Jacobowitz <drow@false.org>

> > I'm in favor of switching to C++.  I'm not going to argue about it if
> > others disagree, but I'll offer to do most of the work if the
> > consensus is positive.
>
> My position on this subject has not been changed.  The more C++ code I
> see, the more convinced I get that the language should die.

I, too, have worked on convoluted and poorly written C++ programs.
That's partially poor programming practices, rather than the language.
Trying to use every feature in the language is not a good plan.

The features which recommend C++ are classes and the encapsulation
and data hiding which it offers.  Along with this comes inlining
and error checking.  A limited use of inheritance is useful.

Features which I would avoid are templates, overloading, and the STL.

I think that implementing the parts of GDB which attempt to emulate
classes in C++ would have benefits in clarity and performance.

--
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: GDB in C++

[Fabian Cenedese]

At 20:53 02.07.2007 -0700, Michael Eager wrote:
>Quoting Mark Kettenis <mark.kettenis@xs4all.nl>:
>> > From: Daniel Jacobowitz <drow@false.org>
>
>> > I'm in favor of switching to C++.  I'm not going to argue about it if
>> > others disagree, but I'll offer to do most of the work if the
>> > consensus is positive.
>>
>> My position on this subject has not been changed.  The more C++ code I
>> see, the more convinced I get that the language should die.
>
>I, too, have worked on convoluted and poorly written C++ programs.
>That's partially poor programming practices, rather than the language.
>Trying to use every feature in the language is not a good plan.
>
>The features which recommend C++ are classes and the encapsulation
>and data hiding which it offers.  Along with this comes inlining
>and error checking.  A limited use of inheritance is useful.
>
>Features which I would avoid are templates, overloading, and the STL.
>
>I think that implementing the parts of GDB which attempt to emulate
>classes in C++ would have benefits in clarity and performance.

I'm not a gdb-developer, so I don't have a vote on this, I just speak as
an outsider. I occasionally look into the gdb sources when I'm trying
to find an error (of course mostly in my code :) I find the gdb source
code very difficult to understand with function pointers, that look
like C++ member functions (as described), the overuse of macros
(e.g. to access structure members or to create function names),
the cleanup mechanism and some other things I haven't understood
yet. I know that gdb has grown over years and part of this comes
from the versatility of hosts and targets it needs to work with. But
still most C++ code I looked at or wrote myself is far easier to
understand if templates and STL are left aside.

>Trying to use every feature in the language is not a good plan.

This is valid for both C++ and C.

Sorry for my mumbling, going back to where I came from...

bye  Fabi

Re: GDB in C++

[Robert Dewar]

To me, in this discussion, what is missing is a recognition
that this discussion has been carried out before. In order
to make a change here, it is not sufficient just to recycle
the old familiar arguments. What is needed is to make a case
that for some reason, the situation has changed, and so the
decision made previously to avoid switching to C++ should be
revisited. If all the proponents can do is to reargue the
general case, repeating what has been said before, I don't
see any basis for changing the previous decision.

My own view is that there may be some gain if the resulting
style was well policed, but there is a major negative in
making the transition, really three negatives:

1. A lot of effort is expended in the transition

2. The transition is bound to cause some instabilities

3. There may be people who just are not comfortable with
the language change, and will not contribute as effectively
or at all. Of course there may be others who are more
inclined to contribute, but this factor needs analysis.

What is needed is an argument that the advantages outweigh
the disadvantages. Arguments based solely on the value of
the resulting style improvements are inadequate for me
unless framed in these terms.

RE: GDB in C++

[Gary Funck]

Robert Dewar wrote (in part):
> What is needed is an argument that the advantages outweigh
> the disadvantages. Arguments based solely on the value of
> the resulting style improvements are inadequate for me
> unless framed in these terms.

Although I am sympathetic to the idea of re-implementing GDB in C++,
and have mentioned this to Mike Eager off-list, perhaps it would
be worth understanding why this change is being recommended now,
and why it has been recommended previously.  Based on my experience
working on GDB, I relate the suggestion to re-implement GDB in C++
to the suggestion that the internal documentation be improved.  I think
that both suggestions are motivated by the desire to make it is easier
to understand GDB's source code, and to modify and improve it.
In the long run, anything that makes GDB easier to understand and
to improve will lead to a faster pace of development,
and likely improvements in usability and reliability.

If we agree that making GDB easier to understand and to change are
worthwhile goals, then perhaps the discussion should focus on what
are the best and least expensive (in time, effort, and impact
on reliability) methods for achieving those goals?  I think that one
of the appeals of recasting some of GDB's internal object-like
constructs into C++, using a C++ object-oriented style is that this
activity is seen as something that a small group of individuals
can do in a reasonable amount of time and that it might result in
an infrastructure that is easier to understand and to extend.  Further,
there may be reliability improvements because C++ will better enforce
the object-oriented constraints.

If C++ isn't the answer, and keeping all of GDB in "C" is a fixed
point, what changes would the developers recommend that would
offer similar (perceived) improvements in understandability
and extensibility?

RE: GDB in C++

[Thiago Jung Bauermann]

On Tue, 2007-07-03 at 12:09 -0700, Gary Funck wrote:
> If C++ isn't the answer, and keeping all of GDB in "C" is a fixed
> point, what changes would the developers recommend that would
> offer similar (perceived) improvements in understandability
> and extensibility?

Speaking as a newcomer who's trying to grasp GDB code, I think you made
very good points. IMHO having reasonable internals documentation is a
very good way to give an overview of GDB's organization and pitfalls.

If GDB Internal's contents was transferred to the GDB wiki, maybe people
would feel more compelled to update and expand it. I know I would try to
contribute to it as I learn new stuff. The downside when comparing to
patches against the existing documentation sources would be that peer
review would be a bit more awkward (but there are ways around it).
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

RE: GDB in C++

[Paul Koning]

>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:

 Thiago> On Tue, 2007-07-03 at 12:09 -0700, Gary Funck wrote:
 >> If C++ isn't the answer, and keeping all of GDB in "C" is a fixed
 >> point, what changes would the developers recommend that would
 >> offer similar (perceived) improvements in understandability and
 >> extensibility?

 Thiago> Speaking as a newcomer who's trying to grasp GDB code, I
 Thiago> think you made very good points. IMHO having reasonable
 Thiago> internals documentation is a very good way to give an
 Thiago> overview of GDB's organization and pitfalls.

Yes.  

 Thiago> If GDB Internal's contents was transferred to the GDB wiki,
 Thiago> maybe people would feel more compelled to update and expand
 Thiago> it. I know I would try to contribute to it as I learn new
 Thiago> stuff.

Excellent suggestion!

	  paul

Re: GDB in C++

[Jim Blandy]

Paul Koning <pkoning@equallogic.com> writes:
>>>>>> "Thiago" == Thiago Jung Bauermann <bauerman@br.ibm.com> writes:
>
>  Thiago> On Tue, 2007-07-03 at 12:09 -0700, Gary Funck wrote:
>  >> If C++ isn't the answer, and keeping all of GDB in "C" is a fixed
>  >> point, what changes would the developers recommend that would
>  >> offer similar (perceived) improvements in understandability and
>  >> extensibility?
>
>  Thiago> Speaking as a newcomer who's trying to grasp GDB code, I
>  Thiago> think you made very good points. IMHO having reasonable
>  Thiago> internals documentation is a very good way to give an
>  Thiago> overview of GDB's organization and pitfalls.
>
> Yes.  
>
>  Thiago> If GDB Internal's contents was transferred to the GDB wiki,
>  Thiago> maybe people would feel more compelled to update and expand
>  Thiago> it. I know I would try to contribute to it as I learn new
>  Thiago> stuff.
>
> Excellent suggestion!

We have a GDB wiki: http://sourceware.org/gdb/wiki/

I wouldn't object to moving the internals documentation there.
High-level organization is pretty key to effective documentation,
though, so the wiki would need aggressive gardening.  It would
probably be good for it to have an appointed editor, to avoid ending
up with two or three competing theories for the overall organization.

RE: GDB in C++

[Gary Funck]

 

> -----Original Message-----
> From: Jim Blandy
> Sent: Wednesday, July 11, 2007 1:41 PM
[...]
> 
> We have a GDB wiki: http://sourceware.org/gdb/wiki/
> 
> I wouldn't object to moving the internals documentation there.
> High-level organization is pretty key to effective documentation,
> though, so the wiki would need aggressive gardening.  It would
> probably be good for it to have an appointed editor, to avoid ending
> up with two or three competing theories for the overall organization.

If the GDB internals document were maintained as part of the
GDB source tree, then presumably each version of that document
will closely track the state of the source tree that it is part of.

If the GDB internals document is maintained in the GDB WIKI
then it likely tracks the state of the trunk of the development
source tree.

There are pros/cons to both approaches.

What are the advantages of moving the internal documentation to
the WIKI?  Is there an idea that by being in WIKI format that
developers (even casual developers) will be more likely contribute
to the internal documentation, rather than marking up the internal
document as it currently exists?

I notice that the WIKI
http://sourceware.org/gdb/wiki/
doesn't appear to have a discussion page (ala Wikipedia).  I think
there may be value in such a thing, because developers and users
can discuss internals documentation issues before committing to
updating the document.  Thus, some internals info. can be made
available before the time is taken to rework that information into
prose.

In my opinion, it likely isn't the current format of the internals
documentation that is holding back further development of that
documentation,
but I would be interested in hearing counter-opinions.

  - Gary

Re: GDB in C++

[Daniel Jacobowitz]

On Wed, Jul 11, 2007 at 01:41:11PM -0700, Jim Blandy wrote:
> I wouldn't object to moving the internals documentation there.
> High-level organization is pretty key to effective documentation,
> though, so the wiki would need aggressive gardening.  It would
> probably be good for it to have an appointed editor, to avoid ending
> up with two or three competing theories for the overall organization.

For the record, I would object.  I think the internals manual is fine
where it is, and would be no more likely to be expanded and kept up to
date if it were moved.

I think the wiki is best taken advantage of as a tool for collecting
new information, which can then be added to the internals manual
through the normal review process.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB in C++

[Robert Dewar]

Daniel Jacobowitz wrote:
> On Wed, Jul 11, 2007 at 01:41:11PM -0700, Jim Blandy wrote:
>> I wouldn't object to moving the internals documentation there.
>> High-level organization is pretty key to effective documentation,
>> though, so the wiki would need aggressive gardening.  It would
>> probably be good for it to have an appointed editor, to avoid ending
>> up with two or three competing theories for the overall organization.
> 
> For the record, I would object.  I think the internals manual is fine
> where it is, and would be no more likely to be expanded and kept up to
> date if it were moved.
> 
> I think the wiki is best taken advantage of as a tool for collecting
> new information, which can then be added to the internals manual
> through the normal review process.

I agree with this suggestion ...
> 

Re: GDB in C++

[Eli Zaretskii]

> Date: Wed, 11 Jul 2007 17:31:53 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Wed, Jul 11, 2007 at 01:41:11PM -0700, Jim Blandy wrote:
> > I wouldn't object to moving the internals documentation there.
> > High-level organization is pretty key to effective documentation,
> > though, so the wiki would need aggressive gardening.  It would
> > probably be good for it to have an appointed editor, to avoid ending
> > up with two or three competing theories for the overall organization.
> 
> For the record, I would object.  I think the internals manual is fine
> where it is, and would be no more likely to be expanded and kept up to
> date if it were moved.

Agreed.

Re: GDB in C++

[Michael Eager]

Thiago Jung Bauermann wrote:

> If GDB Internal's contents was transferred to the GDB wiki, maybe people
> would feel more compelled to update and expand it. I know I would try to
> contribute to it as I learn new stuff. The downside when comparing to
> patches against the existing documentation sources would be that peer
> review would be a bit more awkward (but there are ways around it).

The problems with the GDB documentation are not whether it lives
in a .texi file or in a .html file.  The problem is in the content.

The problem is that the GDB docs are, to a large degree, incomplete,
obsolete, unclear, cryptic, and several other adjectives I'll have to
search for in my thesaurus.

While a wiki has some nice features, it would be not closely tied to
any particular GDB version, nor are changes likely to be reviewed for
correctness as would be the case with a patch to the docs in the
source tree.  GDB has been undergoing a number of significant changes
between versions.  The information on a wiki would have no more
likelihood of being accurate than the current docs.

There are two related fixes for this problem.  (Possibly three,
with the first one being recognition that there is a problem.)

1)  The knowledge that the experienced GDB developers have about the
     program needs to be added to the documentation.  This can either be
     by them writing the docs or by them working with a less experienced
     developer who writes the docs.  (You might remember that I offered
     to be the latter a short while ago, but I got no takers.)

2)  The recognition that some of the problems with the documentation
     stem from the fact that GDB is complex, cryptic, unclear and
     convoluted.  There are a number of ways to address this with
     significant refactoring of the code into separate modules with
     well defined interfaces being one, as well as my previous
     suggestion to convert to using real object oriented code instead
     of awkwardly trying to simulate it.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: GDB in C++

[Thiago Jung Bauermann]

On Wed, 2007-07-11 at 19:24 -0700, Michael Eager wrote:
> Thiago Jung Bauermann wrote:
> > If GDB Internal's contents was transferred to the GDB wiki, maybe people
> > would feel more compelled to update and expand it. I know I would try to
> > contribute to it as I learn new stuff. The downside when comparing to
> > patches against the existing documentation sources would be that peer
> > review would be a bit more awkward (but there are ways around it).
> 
> The problems with the GDB documentation are not whether it lives
> in a .texi file or in a .html file.  The problem is in the content.

It seems most people here don't see much of an advantadge in moving docs
to the wiki. That's fine for me, I don't have a strong opinion about
that. As you say, the main problem is that the documentation is not
being given much priority.

> There are two related fixes for this problem.  (Possibly three,
> with the first one being recognition that there is a problem.)
> 
> 1)  The knowledge that the experienced GDB developers have about the
>      program needs to be added to the documentation.  This can either be
>      by them writing the docs or by them working with a less experienced
>      developer who writes the docs.  (You might remember that I offered
>      to be the latter a short while ago, but I got no takers.)
> 
> 2)  The recognition that some of the problems with the documentation
>      stem from the fact that GDB is complex, cryptic, unclear and
>      convoluted.  There are a number of ways to address this with
>      significant refactoring of the code into separate modules with
>      well defined interfaces being one, as well as my previous
>      suggestion to convert to using real object oriented code instead
>      of awkwardly trying to simulate it.

I think this thread is important because it brings forward the issue
that there is a barrier for new folks who would like to contribute code
to the GDB project. I think that both of the fixes you mention above
should be implemented. Regarding point 2: GDB is such an old project,
and because of this there's a lot of cruft which is not easily
identifiable by those who are not familiar with the code or the historic
issues behind it. (that's why I mentioned "pitfalls" in my earlier
e-mail).

I hope we can get to some conclusion regarding this. Even if it is that
the interested parties (me, for instance) should just send patches to
the internals texinfo file.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: GDB in C++

[Eli Zaretskii]

> From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> Cc: gdb@sources.redhat.com, Gary Funck <gary@intrepid.com>
> Date: Fri, 13 Jul 2007 17:19:26 -0300
> 
> I hope we can get to some conclusion regarding this. Even if it is that
> the interested parties (me, for instance) should just send patches to
> the internals texinfo file.

Let me say again that I will gratefully accept and promptly review any
patches to the GDB manuals, including gdbint.texinfo.  If you do not
feel like writing in Texinfo, I'm prepared to accept plain text and
add the Texinfo markup for you.

Thanks in advance!

Re: GDB in C++

[Thiago Jung Bauermann]

On Fri, 2007-07-13 at 23:54 +0300, Eli Zaretskii wrote:
> > From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> > Cc: gdb@sources.redhat.com, Gary Funck <gary@intrepid.com>
> > Date: Fri, 13 Jul 2007 17:19:26 -0300
> > 
> > I hope we can get to some conclusion regarding this. Even if it is that
> > the interested parties (me, for instance) should just send patches to
> > the internals texinfo file.
> 
> Let me say again that I will gratefully accept and promptly review any
> patches to the GDB manuals, including gdbint.texinfo.  If you do not
> feel like writing in Texinfo, I'm prepared to accept plain text and
> add the Texinfo markup for you.

I didn't mean to say that I don't want to send patches to the texinfo
file. But thanks for the offer!
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: GDB in C++

[Eli Zaretskii]

> From: Thiago Jung Bauermann <bauerman@br.ibm.com>
> Cc: gdb@sourceware.org
> Date: Wed, 11 Jul 2007 16:47:33 -0300
> 
> If GDB Internal's contents was transferred to the GDB wiki, maybe people
> would feel more compelled to update and expand it.

If there are people who want to contribute, let them send their
contributions here.  I promise that every description in plain text
that is manual-worthy will be converted to Texinfo (by myself) and
admitted.  In fact, I already wrote this several times here and on
gdb-patches.

> I know I would try to contribute to it as I learn new stuff.

Please do, and thanks in advance.  You don't need a wiki for that.

RE: GDB in C++

[Gary Funck]

> From: Robert Dewar
> Sent: Tuesday, July 03, 2007 5:15 AM
> 
> To me, in this discussion, what is missing is a recognition
> that this discussion has been carried out before. In order
> to make a change here, it is not sufficient just to recycle
> the old familiar arguments. What is needed is to make a case
> that for some reason, the situation has changed, and so the
> decision made previously to avoid switching to C++ should be
> revisited.

Since this thread seems to have taken on a bit of new life,
I'd like to ask if you/others can point to a past GDB mailing
list thread/two (or even a timefreame) when this issue was
discussed?  I made a quick pass through the GDB mailing list
archives dating back to 2000, and found only a few oblique
references to recoding parts of GDB back into C++ with
selective use of its OO facilities.

thanks,
  - Gary

Re: GDB in C++

[David Daney]

Daniel Jacobowitz wrote:
> On Sat, Jun 30, 2007 at 07:56:32AM -0700, Michael Eager wrote:
>> That said, when I read and step through GDB code I see
>> significant portions which are clearly written in a way
>> which attempts to emulate classes, objects, and both
>> data and member encapsulation.
>>
>> I also see some flaws in this emulation, some of which
>> affect performance, others which affect logic.  There
>> are also places where the encapsulation is broken.  All of
>> this makes debugging more difficult.
> 
> I've seen this complain from at least three different people.
> 
> I'm in favor of switching to C++.  I'm not going to argue about it if
> others disagree, but I'll offer to do most of the work if the
> consensus is positive.
> 
IIRC in the case of GCC, RMS (among others) is opposed to conversion to C++.

My question is:  Does RMS have any say in the matter, and what are his 
thoughts on it?

David Daney

Re: GDB in C++

[Daniel Jacobowitz]

On Mon, Jul 02, 2007 at 01:21:15PM -0700, David Daney wrote:
> My question is:  Does RMS have any say in the matter, and what are his thoughts 
> on it?

With Joel and Mark in favor of staying with C, I think it's
irrelevant.

My two cents: no, this is a decision for the GDB developers.

-- 
Daniel Jacobowitz
CodeSourcery