Move GDB to C++ ?

Move GDB to C++ ?

[Stan Shebs]

As many know, there is a project afoot to investigate the recoding of 
GCC from C into C++. I believe the C++ idea was briefly touched on for 
GDB at the summit, although I don't remember much discussion. Anyway, 
this would be a good time to start thinking about it, and if people are 
generally in favor of the idea, we can start small by tweaking the 
sources to be C++-friendly, avoiding keywords and so forth; GCC has a 
new warning flag -Wcxx-compat that can help.

For my part, I think we should do it. GDB has quite a bit of object-like 
structure internally, and while in the past it was taking a bit of a 
chance to rely on the availability and reliability of C++ compilers, 
those concerns are now generally outdated; I'm not sure any of the 
potential problem hosts are even supported any longer.

Stan

Re: Move GDB to C++ ?

[Mark Kettenis]

> Date: Thu, 10 Jul 2008 11:46:15 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
> 
> As many know, there is a project afoot to investigate the recoding of 
> GCC from C into C++. I believe the C++ idea was briefly touched on for 
> GDB at the summit, although I don't remember much discussion. Anyway, 
> this would be a good time to start thinking about it, and if people are 
> generally in favor of the idea, we can start small by tweaking the 
> sources to be C++-friendly, avoiding keywords and so forth; GCC has a 
> new warning flag -Wcxx-compat that can help.

I think this is an absolutely retarded idea.  C++ is a horrible
programming language.

Re: Move GDB to C++ ?

[Stan Shebs]

Mark Kettenis wrote:
>> Date: Thu, 10 Jul 2008 11:46:15 -0700
>> From: Stan Shebs <stanshebs@earthlink.net>
>>
>> As many know, there is a project afoot to investigate the recoding of 
>> GCC from C into C++. I believe the C++ idea was briefly touched on for 
>> GDB at the summit, although I don't remember much discussion. Anyway, 
>> this would be a good time to start thinking about it, and if people are 
>> generally in favor of the idea, we can start small by tweaking the 
>> sources to be C++-friendly, avoiding keywords and so forth; GCC has a 
>> new warning flag -Wcxx-compat that can help.
>>     
>
> I think this is an absolutely retarded idea.  C++ is a horrible
> programming language.
>   
Okay... so, uh, since C++ is basically a superset of C, presumably the 
horribleness you are thinking of relates to specific extensions. The 
basic idea of classes? Templates? Overloading? Exception handling? We 
would get to codify the set of C++ features that we will allow, 
certainly I'd never want to allow in patches that used arcane features 
of the language in twisted ways.

Stan

Re: Move GDB to C++ ?

[Paul Koning]

>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:

 Stan> Mark Kettenis wrote:
 >>  I think this is an absolutely retarded idea.  C++ is a horrible
 >> programming language.
 >> 
 Stan> Okay... so, uh, since C++ is basically a superset of C,
 Stan> presumably the horribleness you are thinking of relates to
 Stan> specific extensions.

Maybe not.  C is horrible, too.  But I'm afraid it's unlikely that GDB
will get ported to, say, Modula-2.

:-)

	paul

Re: Move GDB to C++ ?

[Andrew Cagney]

Paul Koning wrote:
>>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:
>>>>>>             
>
>  Stan> Mark Kettenis wrote:
>  >>  I think this is an absolutely retarded idea.  C++ is a horrible
>  >> programming language.
>  >> 
>  Stan> Okay... so, uh, since C++ is basically a superset of C,
>  Stan> presumably the horribleness you are thinking of relates to
>  Stan> specific extensions.
>
> Maybe not.  C is horrible, too.  But I'm afraid it's unlikely that GDB
> will get ported to, say, Modula-2.
>   

True, on the other hand we do now have an example of what a true object 
oriented debugging and monitoring tool (written in Java) can look 
like.   While C and C++ have serious limitations (I'm being polite :-), 
I think, for GDB, C++ does offer a way forward for modernising its 
architecture.

The one question I would pose though, is bashing up the current GDB code 
base until it compiles with C++ a reasonable approach?  Each time C++ 
has been suggested previously, that has been the proposed path forward, 
and each time it has not moved (I've even tried it my self).  Perhaps, 
instead, we should approach this more on a component basis - stack, 
expr, type, proc, debug-info, ..., and convert each chunk in turn.  And 
also make use of newer technology such as some of the technology that 
accompanied GOLD.  This would suggest working in parallel, in a 
src/gdbxx (gdb++) directory; while this is of course longer and harder, 
I believe we'll see better results.

-

Re: Move GDB to C++ ?

[Stan Shebs]

Andrew Cagney wrote:
> The one question I would pose though, is bashing up the current GDB 
> code base until it compiles with C++ a reasonable approach?  Each time 
> C++ has been suggested previously, that has been the proposed path 
> forward, and each time it has not moved (I've even tried it my self).  
> Perhaps, instead, we should approach this more on a component basis - 
> stack, expr, type, proc, debug-info, ..., and convert each chunk in 
> turn.  And also make use of newer technology such as some of the 
> technology that accompanied GOLD.  This would suggest working in 
> parallel, in a src/gdbxx (gdb++) directory; while this is of course 
> longer and harder, I believe we'll see better results.
It's certainly an approach worth thinking about. Presumably the point of 
working in a different directory is that the code might be expected to 
be broken or nonportable for a period of time, but when that happens you 
can run afoul of limited commitment levels, with people only able to 
work on gdbxx when they don't have regular gdb tasks. If everyone is 
forced into the same straitj^Wsource tree, dealing with mid-transition 
brokenness is (usually :-) ) justifiable as part of the job.

An intermediate strategy might be to enable C++ in the trunk, then do 
component replacement on branches. GCC has been having some success with 
this; if a branch has something like rewritten symbol handling, then 
regular merges will go pretty quickly, and people that don't want to 
deal with symbol stuff can continue to work on trunk, knowing that the 
branch code will come in when it's ready.

Stan

Re: Move GDB to C++ ?

[Nick Roberts]

 > It's certainly an approach worth thinking about. Presumably the point of 
 > working in a different directory is that the code might be expected to 
 > be broken or nonportable for a period of time, but when that happens you 
 > can run afoul of limited commitment levels, with people only able to 
 > work on gdbxx when they don't have regular gdb tasks. If everyone is 
 > forced into the same straitj^Wsource tree, dealing with mid-transition 
 > brokenness is (usually :-) ) justifiable as part of the job.

Mid-transition brokenness only seems justifiable if there is unanimous
agreement that the transition is desirable.  Imposing a change on people who
may not want it and then telling them that have to put up with the ensuing
brokeness, or fix it, seems quite unreasonable, expecially to those who have
contributed to it's previous state.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Move GDB to C++ ?

[Stan Shebs]

Nick Roberts wrote:
>  > It's certainly an approach worth thinking about. Presumably the point of 
>  > working in a different directory is that the code might be expected to 
>  > be broken or nonportable for a period of time, but when that happens you 
>  > can run afoul of limited commitment levels, with people only able to 
>  > work on gdbxx when they don't have regular gdb tasks. If everyone is 
>  > forced into the same straitj^Wsource tree, dealing with mid-transition 
>  > brokenness is (usually :-) ) justifiable as part of the job.
>
> Mid-transition brokenness only seems justifiable if there is unanimous
> agreement that the transition is desirable.  Imposing a change on people who
> may not want it and then telling them that have to put up with the ensuing
> brokeness, or fix it, seems quite unreasonable, expecially to those who have
> contributed to it's previous state.
>
>   
Yes, I think one should have general agreement on the desirability of a 
transition in the first place. Everyone needs to be able to justify that 
additional overhead both in their own minds, and to colleagues, 
employers, etc. To me that's one of the strengths of open-source 
projects, is that we can mutually agree to undergo some temporary pain 
in order to modernize or extend the software, whereas proprietary 
projects often become fossilized because worthwhile improvements can't 
be proven to increase profits immediately.

Stan

Re: Move GDB to C++ ?

[Vladimir Prus]

Stan Shebs wrote:

> Andrew Cagney wrote:
>> The one question I would pose though, is bashing up the current GDB
>> code base until it compiles with C++ a reasonable approach?  Each time
>> C++ has been suggested previously, that has been the proposed path
>> forward, and each time it has not moved (I've even tried it my self).
>> Perhaps, instead, we should approach this more on a component basis -
>> stack, expr, type, proc, debug-info, ..., and convert each chunk in
>> turn.  And also make use of newer technology such as some of the
>> technology that accompanied GOLD.  This would suggest working in
>> parallel, in a src/gdbxx (gdb++) directory; while this is of course
>> longer and harder, I believe we'll see better results.
> It's certainly an approach worth thinking about. Presumably the point of
> working in a different directory is that the code might be expected to
> be broken or nonportable for a period of time, but when that happens you
> can run afoul of limited commitment levels, with people only able to
> work on gdbxx when they don't have regular gdb tasks. If everyone is
> forced into the same straitj^Wsource tree, dealing with mid-transition
> brokenness is (usually :-) ) justifiable as part of the job.
> 
> An intermediate strategy might be to enable C++ in the trunk, then do
> component replacement on branches. GCC has been having some success with
> this; if a branch has something like rewritten symbol handling, then
> regular merges will go pretty quickly, and people that don't want to
> deal with symbol stuff can continue to work on trunk, knowing that the
> branch code will come in when it's ready.

I think we should use branches only for really terrible changes that
absolutely cannot be done in trunk without making everybody very
unhappy. I think most big changes are also fairly mechanical in nature,
so are not likely to cause serious instability.

- Volodya

Re: Move GDB to C++ ?

[Andrew Cagney]

Stan Shebs wrote:
> Andrew Cagney wrote:
>> The one question I would pose though, is bashing up the current GDB 
>> code base until it compiles with C++ a reasonable approach?  Each 
>> time C++ has been suggested previously, that has been the proposed 
>> path forward, and each time it has not moved (I've even tried it my 
>> self).  Perhaps, instead, we should approach this more on a component 
>> basis - stack, expr, type, proc, debug-info, ..., and convert each 
>> chunk in turn.  And also make use of newer technology such as some of 
>> the technology that accompanied GOLD.  This would suggest working in 
>> parallel, in a src/gdbxx (gdb++) directory; while this is of course 
>> longer and harder, I believe we'll see better results.
> It's certainly an approach worth thinking about. Presumably the point 
> of working in a different directory is that the code might be expected 
> to be broken or nonportable for a period of time, but when that 
> happens you can run afoul of limited commitment levels, with people 
> only able to work on gdbxx when they don't have regular gdb tasks. If 
> everyone is forced into the same straitj^Wsource tree, dealing with 
> mid-transition brokenness is (usually :-) ) justifiable as part of the 
> job.
I don't think it is reasonable to allow mod-transition brokenness, a 
code base, allowing for the usual fubars, should always build and pass 
its testsuite.
>
> An intermediate strategy might be to enable C++ in the trunk, then do 
> component replacement on branches. GCC has been having some success 
> with this; if a branch has something like rewritten symbol handling, 
> then regular merges will go pretty quickly, and people that don't want 
> to deal with symbol stuff can continue to work on trunk, knowing that 
> the branch code will come in when it's ready.
>

While I agree that this looks reasonable, I've reservations as to its 
apparent simplicity.  Lets consider a moment GDB's vs GCC's 
architectures (the high level view):

-> a compiler such as GCC has a pipeline architecture: each pass or 
filter implementing a specific algorithm and working in relative 
isolation; communication with the next pass being through simple (ok in 
theory :-) and tight interfaces.  (There are exceptions such as the 
symbol table of course :-) For instance the front-end churns out GIMPLE, 
while the back-end continues to be fed RTL.  A filter, the bulk of its 
code being an algorithm, can be re-implemented in C++ without modifying 
the interfaces it uses; and a structure can be changed to C++ while 
retaining compatible C/MACRO interfaces. 

-> a debugger such as gdb has an object-oriented architecture: there are 
a number of objects and relationships that reflect the system it is 
modelling.  For instance, a stack has-a frame, a variable has-a 
location|type, and so on.  When talking about changing GDB to C++ we're 
in fact talking about changing the implementation of each of these 
objects from a struct/union to a classes.  I would consider that a far 
more invasive change.

As a way of getting a better feel for this, lets consider two previous 
structural efforts: the unwinder and the architecture vector.  I mention 
them as they are obvious first candidates for switching to C++.  For 
each project the work was largely implemented incrementally in the 
mainline, consequently I would suggest, each project also took, not 
weeks or months, but years of effort.   I suspect that, when we're 
talking about that sort of time scale for an incremental approach, it 
too runs the risk of limited commitment levels, and GDB finding itself 
in a C vs C++ no-where land.

If only life were simple.

-

Re: Move GDB to C++ ?

[Robert Dewar]

Andrew Cagney wrote:

>> Maybe not.  C is horrible, too.  But I'm afraid it's unlikely that GDB
>> will get ported to, say, Modula-2.

or Ada :-)

RE: Move GDB to C++ ?

[Dave Korn]

Paul Koning wrote on 10 July 2008 21:04:

>>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:
> 
>  Stan> Mark Kettenis wrote:
>  >>  I think this is an absolutely retarded idea.  C++ is a horrible
>  >> programming language.
>  >>
>  Stan> Okay... so, uh, since C++ is basically a superset of C,
>  Stan> presumably the horribleness you are thinking of relates to
>  Stan> specific extensions.
> 
> Maybe not.  C is horrible, too.  But I'm afraid it's unlikely that GDB
> will get ported to, say, Modula-2.
> 
> :-)
> 
> 	paul

  On the other hand, Modula-2 is horrible also.  But I'm afraid it's
unlikely that GDB will get ported to, say, befunge.

;-)

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Move GDB to C++ ?

[Mark Kettenis]

> Date: Thu, 10 Jul 2008 13:01:12 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
> 
> Mark Kettenis wrote:
> >> Date: Thu, 10 Jul 2008 11:46:15 -0700
> >> From: Stan Shebs <stanshebs@earthlink.net>
> >>
> >> As many know, there is a project afoot to investigate the recoding of 
> >> GCC from C into C++. I believe the C++ idea was briefly touched on for 
> >> GDB at the summit, although I don't remember much discussion. Anyway, 
> >> this would be a good time to start thinking about it, and if people are 
> >> generally in favor of the idea, we can start small by tweaking the 
> >> sources to be C++-friendly, avoiding keywords and so forth; GCC has a 
> >> new warning flag -Wcxx-compat that can help.
> >>     
> >
> > I think this is an absolutely retarded idea.  C++ is a horrible
> > programming language.
> >   
> Okay... so, uh, since C++ is basically a superset of C, presumably the 
> horribleness you are thinking of relates to specific extensions. The 
> basic idea of classes? Templates? Overloading? Exception handling? We 
> would get to codify the set of C++ features that we will allow, 
> certainly I'd never want to allow in patches that used arcane features 
> of the language in twisted ways.

Classes are mostly ok, but they tend to distract people in doing
architectures, and stupid programming paradigms like setter/getter.

Templates are absolutely horrible syntactically and make it almost
impossible to debug your code.

Function overloading is unecessary syntactic sugar that confuses
compilers and humans alike.

Exception handling is an excellent idea, but I've never seen it used
properly in any non-trivial C++ code.

The subset of C++ that I like is pretty much that what is called C.  I
don't think the benefits of using a few C++ outweighs the loss of the
ability to compile GDB with a bog standard C compiler.

I also don't really want to waste much time on discussing this topic.
If people really want to waste their time on moving GDB to C++, I'll
probably find mysef another project to spend my spare time on.

Mark

Re: Move GDB to C++ ?

[Joel Brobecker]

(I agree with Tom: Very Brave :)

> The subset of C++ that I like is pretty much that what is called C.  I
> don't think the benefits of using a few C++ outweighs the loss of the
> ability to compile GDB with a bog standard C compiler.

That would be my concern #1. I really think that it's a huge plus
to be able to build GDB with a C compiler. C++ compiler are just
not as common as C compilers, particularly on more exotic platforms.

My other major concern is debugability - I want to make sure that
if we agree on the transition, GDB will be as easy to debug as before.
I am way out of my league on this, but isn't it the case that:
  - there's still some progress to be made to help debugging C++
    in general (I might be VERY wrong on that one)
  - that stabs is not good enough to provide full C++ debugging support
?

I think that it's premature to transition GDB to C++. I am not going
to oppose patches that make the code more C++ friendly, these should
be harmless and help prepare the transition if we ever decide to
take that route.

Also, should a consensus in favor of C++ be reached, the Steering
Committee should be given an opportunity to say what they think.
I suspect that the SC's stance will be similar for both GCC and
GDB.

-- 
Joel

Re: Move GDB to C++ ?

[Vladimir Prus]

Joel Brobecker wrote:

> I am way out of my league on this, but isn't it the case that:
>   - there's still some progress to be made to help debugging C++
>     in general (I might be VERY wrong on that one)

I think that the biggest issue with debugging C++ is that whenever you
have pointer to class Base, which actually points to object of class
Derived, and you want GDB to print the real type, GDB gives fits.
(Or maybe, I'm not sufficiently trained in asking GDB politely).

Second issue is that I don't think "step" via throw statement works -- you
need "catch catch".

I don't think the above issues are showstoppers -- there are workarounds,
and the issues must be fixed anyway.

The inline functions are not specific to C++, and templates -- well, there
are no issues debugging templates, and who needs templates outside of 
(well-debugged already) STL, anyway (*)?

Last time I checked, GDB had some bizarre logic to handle C++ namespaces,
but well, who needs namespaces (*)?

- Volodya

(*) Both templates and namespaces have important uses; but it does not seem
GDB, specifically, has much need of them.

Re: Move GDB to C++ ?

[Andreas Schwab]

Vladimir Prus <vladimir@codesourcery.com> writes:

> The inline functions are not specific to C++, and templates -- well, there
> are no issues debugging templates, and who needs templates outside of 
> (well-debugged already) STL, anyway (*)?
>
> Last time I checked, GDB had some bizarre logic to handle C++ namespaces,
> but well, who needs namespaces (*)?

FWIW, if you look at gold, it uses templates and namespaces quite
extensively. :-)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Move GDB to C++ ?

[Vladimir Prus]

On Friday 11 July 2008 13:23:34 Andreas Schwab wrote:
> Vladimir Prus <vladimir@codesourcery.com> writes:
> 
> > The inline functions are not specific to C++, and templates -- well, there
> > are no issues debugging templates, and who needs templates outside of 
> > (well-debugged already) STL, anyway (*)?
> >
> > Last time I checked, GDB had some bizarre logic to handle C++ namespaces,
> > but well, who needs namespaces (*)?
> 
> FWIW, if you look at gold, it uses templates and namespaces quite
> extensively. :-)

I know. I've no opinion how reasonable it is there; but I don't know
any piece of GDB that cries for those language features.

- Volodya

Re: Move GDB to C++ ?

[Andrew Cagney]

Vladimir Prus wrote:
> Joel Brobecker wrote:
>
>   
>> I am way out of my league on this, but isn't it the case that:
>>   - there's still some progress to be made to help debugging C++
>>     in general (I might be VERY wrong on that one)
>>     
>
>   

These are good points.  They offer pointers to some of the areas that 
GDB is lacking.  The cheap comment to make here though is that, were GDB 
written in C++ and used these features, we'd have these debugging 
problems fixed - of course, for instance, GDB is managing to be a good 
Ada debugger, without being written in Ada :-)

This does, I think, raise an interesting question: is, or should, be 
being the a good (best?) C++ debugger be a high priority for GDB?


> I think that the biggest issue with debugging C++ is that whenever you
> have pointer to class Base, which actually points to object of class
> Derived, and you want GDB to print the real type, GDB gives fits.
> (Or maybe, I'm not sufficiently trained in asking GDB politely).
>
> Second issue is that I don't think "step" via throw statement works -- you
> need "catch catch".
>
> I don't think the above issues are showstoppers -- there are workarounds,
> and the issues must be fixed anyway.
>
> The inline functions are not specific to C++, and templates -- well, there
> are no issues debugging templates, and who needs templates outside of 
> (well-debugged already) STL, anyway (*)?
>
> Last time I checked, GDB had some bizarre logic to handle C++ namespaces,
> but well, who needs namespaces (*)?
>
> - Volodya
>
> (*) Both templates and namespaces have important uses; but it does not seem
> GDB, specifically, has much need of them.
>
>
>
>
>   

Re: Move GDB to C++ ?

[Daniel Jacobowitz]

On Fri, Jul 11, 2008 at 10:27:13AM -0400, Andrew Cagney wrote:
> This does, I think, raise an interesting question: is, or should, be  
> being the a good (best?) C++ debugger be a high priority for GDB?

Well, it's one of my priorities for GDB.  I would love to see more
people working on it and I do what I can make time for.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Move GDB to C++ ?

[Paul Koning]

>>>>> "Andrew" == Andrew Cagney <cagney@gnu.org> writes:

 Andrew> This does, I think, raise an interesting question: is, or
 Andrew> should, be being the a good (best?) C++ debugger be a high
 Andrew> priority for GDB?

Yes.  For one thing, C++ is one of the main languages of GCC (and will
be more so).  And C++ is widely used, and that will increase.

   paul

Re: Move GDB to C++ ?

[Pedro Alves]

A Friday 11 July 2008 15:27:13, Andrew Cagney write:
> This does, I think, raise an interesting question: is, or should, be
> being the a good (best?) C++ debugger be a high priority for GDB?

I can't think of why anyone would object to good changes to make GDB be
a better C++ debugger.

(Good in the sense of technically sound, and doesn't regress support
for other languages in unfixable ways).

If someone, or some entity wants to make his/its priority making
that happen, that's a different issue.

GDB doesn't need to be the "best" C++ debugger in the world
to debug itself.  Unless we consider GDB's support so awful that
we won't be able to debug GDB -- I don't, and I support the
change --, I consider that goal independent of the switch to
implementing GDB in C++.

-- 
Pedro Alves

RE: Move GDB to C++ ?

[Dave Korn]

Joel Brobecker wrote on 11 July 2008 07:26:

> (I agree with Tom: Very Brave :)
> 
>> The subset of C++ that I like is pretty much that what is called C.  I
>> don't think the benefits of using a few C++ outweighs the loss of the
>> ability to compile GDB with a bog standard C compiler.
> 
> That would be my concern #1. I really think that it's a huge plus
> to be able to build GDB with a C compiler. C++ compiler are just
> not as common as C compilers, particularly on more exotic platforms.
 
  Then again, how many such platforms even run C compilers, as opposed to
being entirely cross-targeted?

  I think the real issue is that GDB has to be able to debug itself and GDB
is currently weak in a few important areas of C++ support.  I think that
should be resolved before we consider porting the code.

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....

Re: Move GDB to C++ ?

[Daniel Jacobowitz]

On Fri, Jul 11, 2008 at 05:08:39PM +0100, Dave Korn wrote:
>   I think the real issue is that GDB has to be able to debug itself and GDB
> is currently weak in a few important areas of C++ support.  I think that
> should be resolved before we consider porting the code.

I don't think it's a big issue.  The biggest problems have been
resolved; additional problems are mostly in bits of C++ that we would
probably avoid anyway.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Move GDB to C++ ?

[Robert Dewar]

Daniel Jacobowitz wrote:
> On Fri, Jul 11, 2008 at 05:08:39PM +0100, Dave Korn wrote:
>>   I think the real issue is that GDB has to be able to debug itself and GDB
>> is currently weak in a few important areas of C++ support.  I think that
>> should be resolved before we consider porting the code.
> 
> I don't think it's a big issue.  The biggest problems have been
> resolved; additional problems are mostly in bits of C++ that we would
> probably avoid anyway.

In fact it can just be a criterion for what features in C++ to allow
that they must be easily debuggable.

If a move to C++ for GDB and possibly other similar projects is made,
and a well established subset prescribed, it may well be worth having
a switch built into g++ to enforce this subset (similar to the use of
-gnatg in Ada, although that does not go as far as it might in enforcing
the use of the allowed Ada subset for the compiler itself.
> 

Re: Move GDB to C++ ?

[Andrew Cagney]

Mark Kettenis wrote:
>> Date: Thu, 10 Jul 2008 11:46:15 -0700
>> From: Stan Shebs <stanshebs@earthlink.net>
>>
>> As many know, there is a project afoot to investigate the recoding of 
>> GCC from C into C++. I believe the C++ idea was briefly touched on for 
>> GDB at the summit, although I don't remember much discussion. Anyway, 
>> this would be a good time to start thinking about it, and if people are 
>> generally in favor of the idea, we can start small by tweaking the 
>> sources to be C++-friendly, avoiding keywords and so forth; GCC has a 
>> new warning flag -Wcxx-compat that can help.
>>     
>
> I think this is an absolutely retarded idea.  C++ is a horrible
> programming language.
>   
Mark,

I appreciate your pain here - as some would put it "C++ is the answer, 
now what was the question? :-)" - and having considered this further, 
wonder if both this thread and a proposed implementation as part of the 
archer project are being too quick to put the C++ cart before the 
architectural horse :-)

Instead of changing GDB to C++ and hoping the change will magically 
transform GDB's code base into a clean ideal design; should we instead 
be focused on trying to address what I suspect is the underlying 
motivation here - a desire to clean up and re-structure GDB's code base 
so that it more clearly corresponds to a more modern Object Oriented design?

If we consider this as an important goal, and find a way to more 
smoothly facilitate this development (multi-arch, at 9 years, in my not 
so humble opinion, was too slow)  we'll be able to improve GDB's 
internal architecture without using C++.  Then, in time, with a clearer 
O-O design, we can re-consider choices such as language.

Thoughts?

Re: Move GDB to C++ ?

[Vladimir Prus]

Andrew Cagney wrote:

> Instead of changing GDB to C++ and hoping the change will magically
> transform GDB's code base into a clean ideal design; should we instead
> be focused on trying to address what I suspect is the underlying
> motivation here - a desire to clean up and re-structure GDB's code base
> so that it more clearly corresponds to a more modern Object Oriented design?

I think that trying to use better design without support of a language for which
such design is a native one, would be considerably harder. GNOME is a perfect 
example -- in attempt to use OOP in C, they have this GObject thing which is an
approximation of real classes, only harder to use. Ah, and there's even separate
tool, called GOP, that takes class definition in some meta-language and produces
.h and .c file. So, there's fairly complicate non-standard solution for
an already-solved problem.

Let's use one example in GDB -- values. Presently, struct value has a 
field lval_type, and in a number of places, a switch over lval_type is
made. This switch-over-type is a typical red-flag in OOP programs; in case
of GDB this makes it hard to understand what is exact behaviour of 
lval_register, for example. CodeSourcery's implementation of register browing
required extending struct value, so that fetching a value goes via special
remote protocol packet. This ended up been not exactly nice. If struct value
was a base class with a defined interface, and each kind of value (rvalue, lvalue,
register, etc) were a derived class, then the internal logic of GDB would be
more clear, and adding new kinds of values would be much simpler.

I'd be happy to actually refactor struct value in this way, but only when using
the proper tool, namely C++. I don't want to complicate things by emulating
classes in C.

Actually, it appears that this C++ discussion got a bit stalled, apparently since
nobody wants to make the first step. So, how about his plan of action:

1. GDB is made compiled with C++ compiler, with resulting errors removed.
2. I refactor struct value, and folks get to comment if the resulting code
is better, or worse, than what we have.

Comments?

-  Volodya

Re: Move GDB to C++ ?

[Thiago Jung Bauermann]

On Tue, 2008-07-29 at 21:28 +0400, Vladimir Prus wrote:
> Actually, it appears that this C++ discussion got a bit stalled,
> apparently since
> nobody wants to make the first step.

I liked Michael Eager's idea of "C with classes". That would be a
minimal subset of C++ which hopefuly brings the least dissonance, and at
the same time already provides significant value. So I suggest starting
with that?

>  So, how about his plan of action:
> 
> 1. GDB is made compiled with C++ compiler, with resulting errors
> removed.
> 2. I refactor struct value, and folks get to comment if the resulting
> code
> is better, or worse, than what we have.
> 
> Comments?

Sounds great to me!

-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: Move GDB to C++ ?

[Andrew Cagney]

Vladimir Prus wrote:
> Andrew Cagney wrote:
>
>   
>> Instead of changing GDB to C++ and hoping the change will magically
>> transform GDB's code base into a clean ideal design; should we instead
>> be focused on trying to address what I suspect is the underlying
>> motivation here - a desire to clean up and re-structure GDB's code base
>> so that it more clearly corresponds to a more modern Object Oriented design?
>>     
>
> I think that trying to use better design without support of a language for which
> such design is a native one, would be considerably harder. GNOME is a perfect 
> example -- in attempt to use OOP in C, they have this GObject thing which is an
> approximation of real classes, only harder to use. Ah, and there's even separate
> tool, called GOP, that takes class definition in some meta-language and produces
> .h and .c file. So, there's fairly complicate non-standard solution for
> an already-solved problem.
>   

The question I'm asking here is are we focusing on C++ as a solution, 
and mistakenly trying to rely on its features as a solution, when we 
should instead be first focusing on the design, what ever the 
implementation language?

> Let's use one example in GDB -- values. Presently, struct value has a 
> field lval_type, and in a number of places, a switch over lval_type is
> made. This switch-over-type is a typical red-flag in OOP programs; in case
> of GDB this makes it hard to understand what is exact behaviour of 
> lval_register, for example. CodeSourcery's implementation of register browing
> required extending struct value, so that fetching a value goes via special
> remote protocol packet. This ended up been not exactly nice. If struct value
> was a base class with a defined interface, and each kind of value (rvalue, lvalue,
> register, etc) were a derived class, then the internal logic of GDB would be
> more clear, and adding new kinds of values would be much simpler.
>   

For instance, an alternative value relationship we've seen proposed:

     value
         has-a type
         has-a location

     location
         has-a 1:N piece

    piece
        is-a memory piece
        is-a register piece
        is-a constant piece

(credit to tthomas for this refined design) which removes gdb's 
limitation of a value having a single [register] location.  This is a 
design alternative, not an implementation alternative.  Once we've 
concurred on the design we can implement it using language-of-the-day.

If, in attempting to make these changes we find that the C 
implementation truly cumbersome then we've a compelling story for 
language change.    This is assuming that the intent here is find ways 
to allow greater architectural reform in GDB (and a language change is 
just an aid to that goal).  You seem to at least be agreeing with this?

> I'd be happy to actually refactor struct value in this way, but only when using
> the proper tool, namely C++. I don't want to complicate things by emulating
> classes in C.
>
> Actually, it appears that this C++ discussion got a bit stalled, apparently since
> nobody wants to make the first step. So, how about his plan of action:
>
> 1. GDB is made compiled with C++ compiler, with resulting errors removed.
> 2. I refactor struct value, and folks get to comment if the resulting code
> is better, or worse, than what we have.
>
> Comments?
>
> -  Volodya
>
>
>
>
>   

Re: Move GDB to C++ ?

[Thiago Jung Bauermann]

Andrew Cagney wrote:
> The question I'm asking here is are we focusing on C++ as a solution,
> and mistakenly trying to rely on its features as a solution, when we
> should instead be first focusing on the design, what ever the
> implementation language?

<snip>

> If, in attempting to make these changes we find that the C
> implementation truly cumbersome then we've a compelling story for
> language change.

IMHO one of the reasons that this thread keeps coming up is that current GDB
design already begs for implementation in an OO language (witness the
home-brewed implementation of exceptions). So if one agrees with that (I
do), then it is not out of place to discuss a move to an OO language.

> This is assuming that the intent here is find ways 
> to allow greater architectural reform in GDB (and a language change is
> just an aid to that goal).  You seem to at least be agreeing with this?

I'd be surprised if anyone said no to that. :-)

But there's at least one other goal: lower the barrier to entry for would-be
GDB hackers (or one which are at the beginning of their journey and still
didn't grasp the whole picture of the GDB internals).

It has been said already that needing to learn the GDB in-house equivalent
of estabished OO features and/or idioms (like cleanups, GDB exceptions and
others) is a significant obstacle to new contributors. I agree with that.

-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: Move GDB to C++ ?

[Thiago Jung Bauermann]

Just a clarification which I forgot to make...

On Tue, 2008-07-29 at 15:58 -0300, Thiago Jung Bauermann wrote:
> Andrew Cagney wrote:
> > The question I'm asking here is are we focusing on C++ as a solution,
> > and mistakenly trying to rely on its features as a solution, when we
> > should instead be first focusing on the design, what ever the
> > implementation language?
> 
> <snip>
> 
> > If, in attempting to make these changes we find that the C
> > implementation truly cumbersome then we've a compelling story for
> > language change.
> 
> IMHO one of the reasons that this thread keeps coming up is that current GDB
> design already begs for implementation in an OO language (witness the
> home-brewed implementation of exceptions). So if one agrees with that (I
> do), then it is not out of place to discuss a move to an OO language.

Which is not to say that I am against discussions about redesigning GDB.
If such discussions occur in the mailing list I will follow the threads
with great interest and provide input if I can.

I just think that they are not a prerequisite for this C++ discussion.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: Move GDB to C++ ?

[Vladimir Prus]

Andrew Cagney wrote:

> Vladimir Prus wrote:
>> Andrew Cagney wrote:
>>
>>   
>>> Instead of changing GDB to C++ and hoping the change will magically
>>> transform GDB's code base into a clean ideal design; should we instead
>>> be focused on trying to address what I suspect is the underlying
>>> motivation here - a desire to clean up and re-structure GDB's code base
>>> so that it more clearly corresponds to a more modern Object Oriented design?
>>>     
>>
>> I think that trying to use better design without support of a language for which
>> such design is a native one, would be considerably harder. GNOME is a perfect
>> example -- in attempt to use OOP in C, they have this GObject thing which is an
>> approximation of real classes, only harder to use. Ah, and there's even separate
>> tool, called GOP, that takes class definition in some meta-language and produces
>> .h and .c file. So, there's fairly complicate non-standard solution for
>> an already-solved problem.
>>   
> 
> The question I'm asking here is are we focusing on C++ as a solution,
> and mistakenly trying to rely on its features as a solution, when we
> should instead be first focusing on the design, what ever the
> implementation language?
> 
>> Let's use one example in GDB -- values. Presently, struct value has a
>> field lval_type, and in a number of places, a switch over lval_type is
>> made. This switch-over-type is a typical red-flag in OOP programs; in case
>> of GDB this makes it hard to understand what is exact behaviour of
>> lval_register, for example. CodeSourcery's implementation of register browing
>> required extending struct value, so that fetching a value goes via special
>> remote protocol packet. This ended up been not exactly nice. If struct value
>> was a base class with a defined interface, and each kind of value (rvalue, lvalue,
>> register, etc) were a derived class, then the internal logic of GDB would be
>> more clear, and adding new kinds of values would be much simpler.
>>   
> 
> For instance, an alternative value relationship we've seen proposed:
> 
>      value
>          has-a type
>          has-a location
> 
>      location
>          has-a 1:N piece
> 
>     piece
>         is-a memory piece
>         is-a register piece
>         is-a constant piece
> 
> (credit to tthomas for this refined design) which removes gdb's
> limitation of a value having a single [register] location.  This is a
> design alternative, not an implementation alternative.  Once we've
> concurred on the design we can implement it using language-of-the-day.
> 
> If, in attempting to make these changes we find that the C
> implementation truly cumbersome then we've a compelling story for
> language change.    This is assuming that the intent here is find ways
> to allow greater architectural reform in GDB (and a language change is
> just an aid to that goal).  You seem to at least be agreeing with this?

The intent, at least for me, is to be more productive hacking on GDB. One
approach to that goal is replacing emulation of classes and exceptions with
native language constructs. Another approach is to change internal architecture.
And when changing internal architecture, it's desirable to have the help of 
implementation language.

We already have existing architecture that works, and the implementation is
truly cumbersome in my opinion. So why spend even more time first
redesigning bits of GDB, then implementing new design in C, and then decide
that, oh, yes, this is truly truly cumbersome.

- Volodya

Re: Move GDB to C++ ?

[André Pönitz]

On Tuesday 29 July 2008 20:08:42 Andrew Cagney wrote:
> The question I'm asking here is are we focusing on C++ as a solution, 
> and mistakenly trying to rely on its features as a solution, when we 
> should instead be first focusing on the design, what ever the 
> implementation language?

I've seen a few code reviews on gdb-patches pointing out improper
(like missing) use, of, say, 'xfree'. Getting these right seems 
straightforward from a conceptional point of view, yet humans
err, and there's a lot of time spent in creating such code and
reviewing it. Also, it adds a certain level of "line noise" to the code
making it at least for the casual reader of the code hard to distinguish
what the actual meaning of a chunk of code is, and what belongs
to the "house keeping". 

This is one of the things C++ or  (- better also in my opinion -)
"C with classes" can solve. Destructors are friends. So, yes,
C++ can help to solve proble like the problem of limited developer
resources.

It also can help to lower the entrance barrier, as less project
specific maintanance processes need to be learned when
less "maintanance" code is needed. Less time might be spent
on reading (the then un-needed) maintanance code, too.

Note that I said "can", not "will". Whether it will depends on the kind
of code that is accepted. Clearly, C++ _can_ be abused. It does
not have to, though, and I have still to see a project in that limbo
between C and C++ that did not gain from going at least to 
"C with classes"....

Not sure this was helpful for anyone, but I simply could not resist ;-}

Andre'

PS: Incidentally, I came across the discussion because I was looking
for a place to ask a few "gdb user questions".

The list descriptions at http://sourceware.org/gdb/mailing-lists/
all seem to be a bit development-centric. Would this list here be ok
nevertheless?

Re: Move GDB to C++ ?

[Mark Kettenis]

> From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= <apoenitz@trolltech.com>
> Date: Wed, 30 Jul 2008 13:56:56 +0200
> 
> On Tuesday 29 July 2008 20:08:42 Andrew Cagney wrote:
> > The question I'm asking here is are we focusing on C++ as a solution, 
> > and mistakenly trying to rely on its features as a solution, when we 
> > should instead be first focusing on the design, what ever the 
> > implementation language?
> 
> I've seen a few code reviews on gdb-patches pointing out improper
> (like missing) use, of, say, 'xfree'. Getting these right seems 
> straightforward from a conceptional point of view, yet humans
> err, and there's a lot of time spent in creating such code and
> reviewing it. Also, it adds a certain level of "line noise" to the code
> making it at least for the casual reader of the code hard to distinguish
> what the actual meaning of a chunk of code is, and what belongs
> to the "house keeping". 
> 
> This is one of the things C++ or  (- better also in my opinion -)
> "C with classes" can solve. Destructors are friends. So, yes,
> C++ can help to solve proble like the problem of limited developer
> resources.

Dream on.  How is xfree() different from delete?  Oh you have smart
pointers.  You'd better make sure you use them consistently in your
code, otherwise you end up getting yourself in the confused state
where you can't even tell whether there's a missing delete or not.
And then you decide to use a third-party C++ library.  Now you're
almost certainly using your smart pointer inconsistently, or worse,
have smart pointers with different semantics.

Yes, C++ has some features that make memory management easier in
theory.  But they're not the magic bullet that their proponents claim
them to be.

Re: Move GDB to C++ ?

[André Pönitz]

On Wednesday 30 July 2008 14:12:45 Mark Kettenis wrote:
> Dream on. 

Well, I was not trying to get to a personal level.

> How is xfree() different from delete? Oh you have smart  
> pointers.  

Depends on whether you consider, say, std::string a smart pointer.

> You'd better make sure you use them consistently in your 
> code, otherwise you end up getting yourself in the confused state
> where you can't even tell whether there's a missing delete or not.

If objects own their resourcs, 'delete' is rarely needed outside
their destructors.

> And then you decide to use a third-party C++ library.  Now you're
> almost certainly using your smart pointer inconsistently, or worse,
> have smart pointers with different semantics.

I never, ever, mentioned smart pointers. I am talking about using
very basic C++ features like destructors.

Take as an example from the first file I opened   'prompt_for_continue'.
There's an xfree in there, needed in one codepath, not needed in the
other. Not exception safe btw, but then, we do not have exceptions,
right?

{
  char *ignore;
  ...
  ignore = gdb_readline_wrapper (cont_prompt);
  ....
  if (ignore)
    {
      ...
      xfree (ignore);
    }
   ...
}

With a C-with-classes approach that could be made to look like

{
   ...
   string_t ignore = gdb_readline_wrapper (cont_prompt);
   ...
   if (ignore)
     {
      ...
     }
   ...
}


So instead of having the code spread over 39 lines (1680..1719 in utils.c)
the code is spread over _5_ lines, it saves more than a dozen keystrokes
to create, and you do not even have to think about whether the xfree 
call goes into the if, or outside, or whatever.

And see: No 'delete'. No smart pointers. No magic.

> Yes, C++ has some features that make memory management easier in
> theory.  But they're not the magic bullet that their proponents claim
> them to be.

I am not argueing that it is a silver bullet. I am saying it helps in a fairly
wide range of situations when used cautiously.

Andre'

Re: Move GDB to C++ ?

[Eli Zaretskii]

> Date: Wed, 30 Jul 2008 14:12:45 +0200 (CEST)
> From: Mark Kettenis <mark.kettenis@xs4all.nl>
> CC: gdb@sourceware.org
> 
> Yes, C++ has some features that make memory management easier in
> theory.  But they're not the magic bullet that their proponents claim
> them to be.

Very true.  In my experience, C++ makes it easier to extend existing
software, but does not make its maintenance (i.e. debugging) easier,
and actually makes it harder to find your way around in an unfamiliar
program (e.g., because overloading makes the source less
self-explanatory).

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= <apoenitz@trolltech.com>
> Date: Wed, 30 Jul 2008 13:56:56 +0200
> 
> PS: Incidentally, I came across the discussion because I was looking
> for a place to ask a few "gdb user questions".
> 
> The list descriptions at http://sourceware.org/gdb/mailing-lists/
> all seem to be a bit development-centric. Would this list here be ok
> nevertheless?

Yes, it would be okay.  This list is not only for development
discussions, but also for user questions.

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From:  Vladimir Prus <vladimir@codesourcery.com>
> Date:  Tue, 29 Jul 2008 21:28:05 +0400
> 
> 1. GDB is made compiled with C++ compiler, with resulting errors removed.
> 2. I refactor struct value, and folks get to comment if the resulting code
> is better, or worse, than what we have.
> 
> Comments?

My only comment is a question: what for?  I simply don't see the
intended purpose or the goal of this.

I happen to manage software projects for a living, and whenever we
need to upgrade or change some of our tools, it is always because we
need to do something that is impossible or very inconvenient with the
existing ones.  We never do it out of some abstract wish of "improving
the design" or "refactoring" for their own sake.

So will someone please tell, loud and clear: what do we want to do the
day after GDB is rewritten in C++?  Let's suppose that we magically
fast-forward to the day after everything was refactored and GDB is
110% pure, OO, C++ -- what will we do the next day that we cannot or
have difficulties doing today?

Unless we can answer this question, refactoring and rewriting is
simply waste of resources, nothing less, nothing more.

Re: Move GDB to C++ ?

[Stan Shebs]

Eli Zaretskii wrote:
> So will someone please tell, loud and clear: what do we want to do the
> day after GDB is rewritten in C++?  Let's suppose that we magically
> fast-forward to the day after everything was refactored and GDB is
> 110% pure, OO, C++ -- what will we do the next day that we cannot or
> have difficulties doing today?
>   
Speaking for myself, I hope to spend less of my time reading code, 
especially idiosyncratic implementations that seemed like clever ideas 
twenty years ago. For instance, at this very moment I'm looking at 
ALL_OBJFILES and friends, wondering if the introduction of multiple 
execs is going to impact overall performance.
> Unless we can answer this question, refactoring and rewriting is
> simply waste of resources, nothing less, nothing more.
>   
Indeed, refactoring alone is pointless. The theory is supposed to be 
that it enables other changes. For instance, when I broke up 
wait_for_inferior ages ago, my immediate goal was to preserve 
functionality exactly; nobody understood any more how all the gotos 
interacted, and I didn't want to throw GDB into any more of a muddle 
than it had already gotten into. But once that was done, it facilitated 
additiional changes for async event handling, nonstop debugging, etc.

Stan

Re: Move GDB to C++ ?

[Eli Zaretskii]

> Date: Tue, 29 Jul 2008 12:35:02 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
> CC: gdb@sources.redhat.com
> 
> For instance, at this very moment I'm looking at 
> ALL_OBJFILES and friends, wondering if the introduction of multiple 
> execs is going to impact overall performance.

And how would that change with C++?

Re: Move GDB to C++ ?

[Stan Shebs]

Eli Zaretskii wrote:
>> Date: Tue, 29 Jul 2008 12:35:02 -0700
>> From: Stan Shebs <stanshebs@earthlink.net>
>> CC: gdb@sources.redhat.com
>>
>> For instance, at this very moment I'm looking at 
>> ALL_OBJFILES and friends, wondering if the introduction of multiple 
>> execs is going to impact overall performance.
>>     
>
> And how would that change with C++?
>
>   
C++ collection classes would be very effective here. And sure, the same 
things could be constructed manually in C, but then you're using piles 
of macro trickery a la vec.h and you lose all your typechecking etc, or 
if you use function dispatching to iterate, you blow your optimization 
opportunities in code that is known to be time-critical. Good use of C++ 
machinery effectively moves functionality out of the GDB source tree and 
lets the compiler do the work instead.

Stan

Re: Move GDB to C++ ?

[Eli Zaretskii]

> Date: Wed, 30 Jul 2008 11:45:15 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
> CC: gdb@sources.redhat.com
> 
> Eli Zaretskii wrote:
> >> Date: Tue, 29 Jul 2008 12:35:02 -0700
> >> From: Stan Shebs <stanshebs@earthlink.net>
> >> CC: gdb@sources.redhat.com
> >>
> >> For instance, at this very moment I'm looking at 
> >> ALL_OBJFILES and friends, wondering if the introduction of multiple 
> >> execs is going to impact overall performance.
> >>     
> >
> > And how would that change with C++?
> >
> >   
> C++ collection classes would be very effective here.

Can we see some code, please?

> And sure, the same 
> things could be constructed manually in C, but then you're using piles 
> of macro trickery a la vec.h

Are we still talking about ALL_OBJFILES, or about something more
broad?  ALL_OBJFILES is just a loop:

    #define	ALL_OBJFILES(obj) \
      for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next)

Re: Move GDB to C++ ?

[Stan Shebs]

Eli Zaretskii wrote:
>> Date: Wed, 30 Jul 2008 11:45:15 -0700
>> From: Stan Shebs <stanshebs@earthlink.net>
>> CC: gdb@sources.redhat.com
>>
>> Eli Zaretskii wrote:
>>     
>>>> Date: Tue, 29 Jul 2008 12:35:02 -0700
>>>> From: Stan Shebs <stanshebs@earthlink.net>
>>>> CC: gdb@sources.redhat.com
>>>>
>>>> For instance, at this very moment I'm looking at 
>>>> ALL_OBJFILES and friends, wondering if the introduction of multiple 
>>>> execs is going to impact overall performance.
>>>>     
>>>>         
>>> And how would that change with C++?
>>>
>>>   
>>>       
>> C++ collection classes would be very effective here.
>>     
>
> Can we see some code, please?
>   
How can I do that meaningfully? It depends on how everything else is to 
be designed. I'm a little surprised that you don't see it yourself, 
actually.
>> And sure, the same 
>> things could be constructed manually in C, but then you're using piles 
>> of macro trickery a la vec.h
>>     
>
> Are we still talking about ALL_OBJFILES, or about something more
> broad?  ALL_OBJFILES is just a loop:
>
>     #define	ALL_OBJFILES(obj) \
>       for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next)
>   
It's the the "and friends" part that is problematic, there are a dozen 
variants at least, and the potential for doubling that number with 
multiple execs, because sometimes you still want to iterate through all 
indiscriminately, other times through only the objfiles for a particular 
program. There is even a note in objfiles.h about the hazards of the 
basic "pointer to next" approach, which was the very height of C fashion 
twenty years ago, but is actually a chronic source of bugs and memory leaks.

Stan

Re: Move GDB to C++ ?

[Andrew Cagney]

Stan Shebs wrote:
>
>>
>>   
> How can I do that meaningfully? It depends on how everything else is 
> to be designed. I'm a little surprised that you don't see it yourself, 
> actually.

I think Eli's point is reasonable, we need good reason to change the 
code; multi-arch, for instance, was motivated by the desire to support 
multiple architectures within a single GDB.  Below are two candidates 
for change; In each case they provide design suggestions that, I 
believe, are more easily expressed using an O-O paradime, and let us 
address specific limitations in the current GDB code

value has-a location has-a-multiple pieces
http://sourceware.org/ml/gdb/2008-07/msg00302.html
By breaking up value so that it's location consists of multiple pieces 
we're able to handle the modification of variables who's value is split 
between registers, or between registers and memory.  I think this 
provides an example of where we can ignore the language and focus on the 
proposed design change, deciding if it stands up on its merits.  A C++ 
implementation, while perhaps more straight forward, isn't a predicate 
to the work.

virtual stack vs physical stack
http://sourceware.org/ml/gdb/2008-07/msg00191.html
This offers both an alternative to Daniel's current inline back-trace 
code; and a way potential way forward for us to handle more complex 
unwinding such as can occure in an OpenMP program  where the user's 
stack appears to straddle multiple threads.  This design is more 
powerful in that it applies the decorator pattern; something that may be 
technically challenging in C.

For each case, especially the second, is this more straight forward in 
an O-O language, even C++.



>>> And sure, the same things could be constructed manually in C, but 
>>> then you're using piles of macro trickery a la vec.h
>>>     
>>
>> Are we still talking about ALL_OBJFILES, or about something more
>> broad?  ALL_OBJFILES is just a loop:
>>
>>     #define    ALL_OBJFILES(obj) \
>>       for ((obj) = object_files; (obj) != NULL; (obj) = (obj)->next)
>>   
> It's the the "and friends" part that is problematic, there are a dozen 
> variants at least, and the potential for doubling that number with 
> multiple execs, because sometimes you still want to iterate through 
> all indiscriminately, other times through only the objfiles for a 
> particular program. There is even a note in objfiles.h about the 
> hazards of the basic "pointer to next" approach, which was the very 
> height of C fashion twenty years ago, but is actually a chronic source 
> of bugs and memory leaks.
>
I'd read this more as an argument in favour of a managed runtime 
environment that included features such as garbage collection.

You're right that we need to re-think the way we allocate and manage 
memory for debug-info; determining a new global strategy for its 
management.  Once we've figured that out we can look forward to 
implementing it, and we may in deed find that the mechanisms provided by 
C++ aid in local aspects of the global strategy (we might also find that 
the complexity of C++'s features actually obscure the problem :-).  The 
thing to recognize is that C++ is a tool here, not a silver bullet.

Re: Move GDB to C++ ?

[Andrew Cagney]

Stan Shebs wrote:
>  if you use function dispatching to iterate, you blow your 
> optimization opportunities in code that is known to be time-critical.
>
Not having to kludge up indirect dispatch would be nice for a number of 
reasons, performance is not one of them.  It's like adding "inline" 
because we think that will fix a not spot.

Re: Move GDB to C++ ?

[Mark Kettenis]

> Date: Wed, 30 Jul 2008 11:45:15 -0700
> From: Stan Shebs <stanshebs@earthlink.net>
> 
> Eli Zaretskii wrote:
> >> Date: Tue, 29 Jul 2008 12:35:02 -0700
> >> From: Stan Shebs <stanshebs@earthlink.net>
> >> CC: gdb@sources.redhat.com
> >>
> >> For instance, at this very moment I'm looking at 
> >> ALL_OBJFILES and friends, wondering if the introduction of multiple 
> >> execs is going to impact overall performance.
> >>     
> >
> > And how would that change with C++?
> >
> >   
> C++ collection classes would be very effective here. And sure, the same 
> things could be constructed manually in C, but then you're using piles 
> of macro trickery a la vec.h and you lose all your typechecking etc, or 

You mean the C++ STL container classes?  Yes they make it easy to
write code.  But they don't really help when you need to debug your
code since they are implemented using templates.  The result is
incomprehensible compiler errors when you make a mistake in your code.
And every time I need to look at such a container in GDB I spend
minutes and minutes figuring out how to display its contents.

I'm not a fan of macro trickery a la vec.h either.  I think actually
"open coding" your containers is preferable in many cases.  Linked
lists and dynamically sizable arrays aren't too difficult to
implement of you only need them for two or three different types.

> if you use function dispatching to iterate, you blow your optimization 
> opportunities in code that is known to be time-critical.

Do you have any evidence to back this up?  As far as I understand the
main optimization strategy for C++ is heavy use of inlining.  This
increases the code footprint of your code which in turn blows away
your instruction cache.  That's a heavy price to pay for avoiding a
few branch instructions and some stack access.

My experience is the exact opposite.  Behind that simple assignment
might hide a very costly operation.

>                                                           Good use of C++ 
> machinery effectively moves functionality out of the GDB source tree and 
> lets the compiler do the work instead.

Pushing compile time through the roof and gobbling up several hundred
of megabytes of memory.  Will it still be possible to compile a native
GDB on an underpowered ARM CPU with 64MB of memory?

Re: Move GDB to C++ ?

[André Pönitz]

On Wednesday 30 July 2008 21:42:17 Mark Kettenis wrote:
> > C++ collection classes would be very effective here. And sure, the same 
> > things could be constructed manually in C, but then you're using piles 
> > of macro trickery a la vec.h and you lose all your typechecking etc, or 
> 
> You mean the C++ STL container classes?  Yes they make it easy to
> write code.

And they make it easy to choose the right container for the task, e.g. 
the one with the needed performance characteristics. In C, one 
basically starts of with a linked list, and only if it really, really hurts
to a degree that one can't ignore the problem

> But they don't really help when you need to debug your 
> code since they are implemented using templates. 

It's somewhat funny to hear that kind of argument from someone
who is writing debuggers. Isn't it your self-assigned task to make
debugging easy? If it isn't easy (and I do agree that debugging 
common C++ with plain gdb is a pain), it is - sorry to be blunt -
at least partially your fault.

Instantiated class templates are not different from ordinary structs, and
there is no real problem in presenting the "children" of a, say,
std::list<int>  as if they were ordinary struct members, at least for a
given (say, current gcc's) implementation.

> The result is incomprehensible compiler errors when you make
> a mistake in your code. 

Well, at the time I started coding (and probably yours, too ;-)),
compiler were considered "user friendly" when they did not just
abort on faulty input but were so nice and gave the number of
the problematic line, too. (a) one gets used to it, and (b) it's
far more convienient nowadays. Especially gcc is pretty good
at pointing out possible reasons _why_ compilation failed.

> And every time I need to look at such a container in GDB I spend
> minutes and minutes figuring out how to display its contents.

See above. That's the problem of the frontend you use. Of course,
one reason that most frontends do not display container contents
nicely is that gdb is not easy to interact with programmatically, and
behaviour details change by the release, so frontend writers are
likely to skip that part and just present you the C view of the world.

> I'm not a fan of macro trickery a la vec.h either.  I think actually
> "open coding" your containers is preferable in many cases.  Linked
> lists and dynamically sizable arrays aren't too difficult to
> implement of you only need them for two or three different types.

And a hash map might be the proper choice for a container
performance-wise, and you are lost with "openly coded plain C".

> > if you use function dispatching to iterate, you blow your optimization 
> > opportunities in code that is known to be time-critical.
> 
> Do you have any evidence to back this up?  As far as I understand the
> main optimization strategy for C++ is heavy use of inlining.  This
> increases the code footprint of your code which in turn blows away
> your instruction cache.  That's a heavy price to pay for avoiding a
> few branch instructions and some stack access.

Gdb performance is an issue. I have projects were starting 
up gdb easily takes 20 seconds or more. The same code
shows up in the debugger from the Dark Side in a snap. 

> My experience is the exact opposite.  Behind that simple assignment
> might hide a very costly operation.

First off all, not all such operations are on the critical paths in the
application, so there usually  lots of places where an expensive 'a = b;'
might waste a few hundred CPU cycles over the optimal, 20 line, highly
optimized  "manual copy"; but the latter wastes the developer's time, the 
reviewer's time and the code reader's time, and human time is usually
regarded more valuable than CPU time.

In the other cases, the profiler will tell you, and it's up to you to decide
whether it's worth that price in that situation and whether you need
hand-craft this particular piece of code. Or simply optimize the container
you use _without_ touching the "user code".  That's a liberty you do not
have with "openly coded" structures.

> > Good use of C++ machinery effectively moves functionality
> > out of the GDB source tree and  
> > lets the compiler do the work instead.
> 
> Pushing compile time through the roof and gobbling up several hundred
> of megabytes of memory.  Will it still be possible to compile a native
> GDB on an underpowered ARM CPU with 64MB of memory?

Yes. 

Andre'

Re: Move GDB to C++ ?

[Alpár Jüttner]

Hi,

 
> > Pushing compile time through the roof and gobbling up several hundred
> > of megabytes of memory.  Will it still be possible to compile a native
> > GDB on an underpowered ARM CPU with 64MB of memory?
> 
> Yes. 

Or no.

Gcc can be very memory hungry when compiling C++, a memory consumption
of 400MB is not unusual even for relatively short code snippets, thus it
can be a problem indeed. Probably this happens only when heavy template
programming is used, which may not be the case for gdb (except the use
of STL, which is a template library).

Anyway, some experiment should be made here.

Regards,
Alpar

Re: Move GDB to C++ ?

[Alpár Jüttner]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

Hi,

> Well, at the time I started coding (and probably yours, too ;-)),
> compiler were considered "user friendly" when they did not just
> abort on faulty input but were so nice and gave the number of
> the problematic line, too. (a) one gets used to it, and (b) it's
> far more convienient nowadays. Especially gcc is pretty good
> at pointing out possible reasons _why_ compilation failed.

Understanding the error message of g++ is sometimes a kind of horror,
indeed. See the attached error message for a "nice" example. Luckily,
this is again something that is only a problem when templates are
extensively used.

Best regards,
Alpar


[-- Attachment #2: g++-log.txt --]
[-- Type: text/plain, Size: 17019 bytes --]

-*- mode: compilation; default-directory: "~/projects/ETIK/hugo_loc/work/deba/" -*-
Compilation started at Mon Nov 28 07:14:16

g++ -I/home/alpar/projects/ETIK/hugo preflow-matching.cpp
preflow-matching.h: In function 'int lemon::_maxMatchingB_init(const Graph&, MT&, typename Graph::LowerNodeMap<int>&, typename Graph::LowerNodeMap<int>&, int&) [with Graph = lemon::SmartUndirBipartiteGraph, MT = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >::UpperNodeMap<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>]':
preflow-matching.h:165:   instantiated from 'int lemon::maxMatchingB(const Graph&, MT&) [with Graph = lemon::SmartUndirBipartiteGraph, MT = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >::UpperNodeMap<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>]'
preflow-matching.h:143:   instantiated from 'int lemon::maxMatchingB(const Graph&) [with Graph = Graph]'
preflow-matching.cpp:241:   instantiated from here
preflow-matching.h:99: error: no match for 'operator=' in '(+ matching)->lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >::UpperNodeMap<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>::<anonymous>.lemon::IterableMapExtender<lemon::DefaultMap<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge> >::<anonymous>.lemon::DefaultMap<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>::<anonymous>.lemon::ArrayMap<_Graph, _Item, _Value>::operator[] [with _Graph = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, _Item = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, _Value = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge](((const lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode&)(& lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode(((const lemon::SmartUndirBipartiteGraphBase::Node&)((const lemon::SmartUndirBipartiteGraphBase::Node*)(& n.lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > >::UpperNodeIt::<anonymous>))))))) = lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > >::IncEdgeIt(((const lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > >&)(&(+ g)->lemon::SmartUndirBipartiteGraph::<anonymous>.lemon::ClearableUndirBipartiteGraphExtender<lemon::ExtendableUndirBipartiteGraphExtender<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > > > >::<anonymous>.lemon::ExtendableUndirBipartiteGraphExtender<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > > >::<anonymous>.lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >::<anonymous>)), ((const lemon::SmartUndirBipartiteGraphBase::Node&)((const lemon::SmartUndirBipartiteGraphBase::Node*)(& n.lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > >::UpperNodeIt::<anonymous>))))'
/home/alpar/projects/ETIK/hugo/lemon/bits/graph_extender.h:428: note: candidates are: lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge& lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge::operator=(const lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge&)
preflow-matching.h: In function 'int lemon::_maxMatchingB(const Graph&, MT&, typename Graph::LowerNodeMap<int>&, typename Graph::LowerNodeMap<int>&, int) [with Graph = lemon::SmartUndirBipartiteGraph, MT = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >::UpperNodeMap<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>]':
preflow-matching.h:167:   instantiated from 'int lemon::maxMatchingB(const Graph&, MT&) [with Graph = lemon::SmartUndirBipartiteGraph, MT = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >::UpperNodeMap<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>]'
preflow-matching.h:143:   instantiated from 'int lemon::maxMatchingB(const Graph&) [with Graph = Graph]'
preflow-matching.cpp:241:   instantiated from here
preflow-matching.h:54: error: dependent-name 'lemon::IterableBoolNodeMap<Graph>::TrueIt' is parsed as a non-type, but instantiation yields a type
preflow-matching.h:54: note: say 'typename lemon::IterableBoolNodeMap<Graph>::TrueIt' if a type is meant
preflow-matching.h:74: error: no match for 'operator=' in '(+ matching)->lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >::UpperNodeMap<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>::<anonymous>.lemon::IterableMapExtender<lemon::DefaultMap<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge> >::<anonymous>.lemon::DefaultMap<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>::<anonymous>.lemon::ArrayMap<_Graph, _Item, _Value>::operator[] [with _Graph = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, _Item = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, _Value = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge](((const lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode&)(& lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode(((const lemon::SmartUndirBipartiteGraphBase::Node&)((const lemon::SmartUndirBipartiteGraphBase::Node*)(&(+ g)->lemon::SmartUndirBipartiteGraph::<anonymous>.lemon::ClearableUndirBipartiteGraphExtender<lemon::ExtendableUndirBipartiteGraphExtender<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > > > >::<anonymous>.lemon::ExtendableUndirBipartiteGraphExtender<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > > >::<anonymous>.lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >::<anonymous>.lemon::IterableUndirBipartiteGraphExtender<_Base>::runningNode [with _Base = lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> >](((const lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > >::IncEdgeIt&)((const lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > >::IncEdgeIt*)(& bedge))))))))))) = bedge'
/home/alpar/projects/ETIK/hugo/lemon/bits/graph_extender.h:428: note: candidates are: lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge& lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge::operator=(const lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge&)
preflow-matching.h:82: error: no match for 'operator[]' in 'cov[(+ matching)->lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >::UpperNodeMap<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>::<anonymous>.lemon::IterableMapExtender<lemon::DefaultMap<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge> >::<anonymous>.lemon::DefaultMap<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>::<anonymous>.lemon::ArrayMap<_Graph, _Item, _Value>::operator[] [with _Graph = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, _Item = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, _Value = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge](((const lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode&)(& lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode(((const lemon::SmartUndirBipartiteGraphBase::Node&)((const lemon::SmartUndirBipartiteGraphBase::Node*)(& n.lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > >::UpperNodeIt::<anonymous>)))))))]'
/home/alpar/projects/ETIK/hugo/lemon/bits/vector_map.h:154: note: candidates are: typename std::vector<_Value, std::allocator<_Tp> >::reference lemon::VectorMap<_Graph, _Item, _Value>::operator[](const _Item&) [with _Graph = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, _Item = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::LowerNode, _Value = int]
/home/alpar/projects/ETIK/hugo/lemon/bits/vector_map.h:162: note:                 typename std::vector<_Value, std::allocator<_Tp> >::const_reference lemon::VectorMap<_Graph, _Item, _Value>::operator[](const _Item&) const [with _Graph = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, _Item = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::LowerNode, _Value = int]
preflow-matching.h:83: error: no match for 'operator[]' in 'cov[(+ matching)->lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >::UpperNodeMap<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>::<anonymous>.lemon::IterableMapExtender<lemon::DefaultMap<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge> >::<anonymous>.lemon::DefaultMap<lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge>::<anonymous>.lemon::ArrayMap<_Graph, _Item, _Value>::operator[] [with _Graph = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, _Item = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode, _Value = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::Edge](((const lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode&)(& lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::UpperNode(((const lemon::SmartUndirBipartiteGraphBase::Node&)((const lemon::SmartUndirBipartiteGraphBase::Node*)(& n.lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > >::UpperNodeIt::<anonymous>)))))))]'
/home/alpar/projects/ETIK/hugo/lemon/bits/vector_map.h:154: note: candidates are: typename std::vector<_Value, std::allocator<_Tp> >::reference lemon::VectorMap<_Graph, _Item, _Value>::operator[](const _Item&) [with _Graph = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, _Item = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::LowerNode, _Value = int]
/home/alpar/projects/ETIK/hugo/lemon/bits/vector_map.h:162: note:                 typename std::vector<_Value, std::allocator<_Tp> >::const_reference lemon::VectorMap<_Graph, _Item, _Value>::operator[](const _Item&) const [with _Graph = lemon::MappableUndirBipartiteGraphExtender<lemon::IterableUndirBipartiteGraphExtender<lemon::AlterableUndirBipartiteGraphExtender<lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase> > > >, _Item = lemon::UndirBipartiteGraphExtender<lemon::SmartUndirBipartiteGraphBase>::LowerNode, _Value = int]

Compilation exited abnormally with code 1 at Mon Nov 28 07:14:18

Re: Move GDB to C++ ?

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> So will someone please tell, loud and clear: what do we want to do the
Eli> day after GDB is rewritten in C++?  Let's suppose that we magically
Eli> fast-forward to the day after everything was refactored and GDB is
Eli> 110% pure, OO, C++ -- what will we do the next day that we cannot or
Eli> have difficulties doing today?

Nobody is proposing that we stop all work and rewrite GDB in C++, then
look to see what we could do with it.  That would not make sense.

Aside from the one-time effort to make gdb compile with a C++
compiler, it can be introduced gradually.


C++ is not a silver bullet, it is an improvement.

I think much of Ian's PDF on moving GCC to C++ applies just as well to
gdb:

    http://www.airs.com/ian/cxx-slides.pdf

Actually, the case is even stronger for gdb.  For example, GCC does
not use RAII or exceptions -- both idioms where C++ is strong -- but
gdb does.

Naturally, every construct in C++ can be written using C.  This is
obvious, because gdb already does it.  However, in C++ it is generally
less work, and the result is often better -- more regular, simpler to
reason about, more type-safe, less buggy, or in some cases faster.

Tom

Re: Move GDB to C++ ?

[Eli Zaretskii]

> Cc: gdb@sources.redhat.com
> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 29 Jul 2008 21:59:08 -0600
> 
> >>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli> So will someone please tell, loud and clear: what do we want to do the
> Eli> day after GDB is rewritten in C++?  Let's suppose that we magically
> Eli> fast-forward to the day after everything was refactored and GDB is
> Eli> 110% pure, OO, C++ -- what will we do the next day that we cannot or
> Eli> have difficulties doing today?
> 
> Nobody is proposing that we stop all work and rewrite GDB in C++, then
> look to see what we could do with it.

Did I say that someone did propose this?  If you think I did, I
probably failed to express myself clearly.

> Aside from the one-time effort to make gdb compile with a C++
> compiler, it can be introduced gradually.
> 
> 
> C++ is not a silver bullet, it is an improvement.

Yes, but still no answer to the question I proposed.

> I think much of Ian's PDF on moving GCC to C++ applies just as well to
> gdb:
> 
>     http://www.airs.com/ian/cxx-slides.pdf

Those slides have only one _real_ GCC-specific argument in favor of
C++: on slide 11.  All the rest is general comparison between C and
C++ based on toy examples.

What I would like to see, as a minimum, is a dozen such arguments, for
some of the more important parts of GDB code, that show how switching
to C++ will make those parts easier to understand, extend, and
maintain.  For now, I've heard only one such argument: about struct
value, and it wasn't anywhere as detailed as a convincing argument
should be.  If someone would come to me with such arguments on my
daytime job, she would be out of my office in less than 2 minutes.

> Naturally, every construct in C++ can be written using C.  This is
> obvious, because gdb already does it.  However, in C++ it is generally
> less work, and the result is often better -- more regular, simpler to
> reason about, more type-safe, less buggy, or in some cases faster.

As I said, such general arguments don't convince me where I get my
paycheck, and that's a place where I can actually force people to code
according to some standards.

Re: Move GDB to C++ ?

[David Carlton]

I'm not an active GDB contributer any more, so feel free to ignore
anything that I'm saying, but:

I think this discussion is now largely beating around the bush.


Some people strongly prefer to work (on large scale projects) in C,
and really don't want to work in C++.  Some people strongly prefer to
work in C++, and really don't want to work in C.  (And some people
would rather work in Java, or Ruby, or Haskell, but none of those are
realistic options for a GDB transition, so I'm ignoring them.)

Given that, we can talk about technical advantages or disadvantages
until we're blue in the face, but I don't think that will get us any
farther.  We've already seen examples of how GDB is reimplementing
almost every C++ concept that you can think of in C; for the C++ fans,
that's convincing evidence that GDB development would proceed more
smoothly in C++ (those constructs could be done with less work), while
for the C fans, that's convincing evidence that GDB development
doesn't need C (proof by existence).

And I don't see that more examples are going to help much.  I think
Vladimir's proposal of doing one example of a conversion in detail is
sensible enough, but I don't think it will change anybody's feelings
on this matter.  I bet the results will look better to people who like
C++, and unconvincing to people who like C; indeed, Eli's already said
as much for the latter side.

And even if that example did point to significant benefits that C fans
agreed with (or, to take the other side, even if the results didn't
show code that looked significantly different in C than in C++), I'm
not sure that would matter: even if people were intellectually
convinced that their non-preferred language was "better" for GDB,
they'd still be unhappy programming in a language that felt wrong to
them.


I liked it how, at the start of this thread, Mark was very clear: he
doesn't like C++, he has no desire to program in C++, if GDB switches
to C++, he will find something else to work on.  That's what the
choice here looks like to me: you're not choosing implementation
languages, you're choosing contributors, you're trying to figure out
which implementation language will lead to a healthier contributor mix
going forward.

Which language will lead to more people enjoying contributing to GDB?
Which language will lead to more people feeling like they can work at
full productivity while contributing to GDB?  How will the choice of
language affect GDB's institutional memory?  How will the choice of
language affect whether or not newcomers are likely to join in,
whether or not they're likely to stay involved?

I have no idea how to answer these questions. :-(  (Other than running
an experiment by forking GDB.)  But they're what's important here.

David Carlton
david.carlton@sun.com

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From: David Carlton <david.carlton@sun.com>
> Date: Wed, 30 Jul 2008 12:56:14 -0700
> 
> Some people strongly prefer to work (on large scale projects) in C,
> and really don't want to work in C++.  Some people strongly prefer to
> work in C++, and really don't want to work in C.  (And some people
> would rather work in Java, or Ruby, or Haskell, but none of those are
> realistic options for a GDB transition, so I'm ignoring them.)

FWIW, at least for me, this is not a language choice issue, this is an
issue of making a decision whether to invest a non-trivial amount of
time and effort into refactoring.  I would say the same things I did
in this thread if someone would suggest to refactor GDB in C.

> Given that, we can talk about technical advantages or disadvantages
> until we're blue in the face, but I don't think that will get us any
> farther.  We've already seen examples of how GDB is reimplementing
> almost every C++ concept that you can think of in C; for the C++ fans,
> that's convincing evidence that GDB development would proceed more
> smoothly in C++ (those constructs could be done with less work), while
> for the C fans, that's convincing evidence that GDB development
> doesn't need C (proof by existence).
> 
> And I don't see that more examples are going to help much.  I think
> Vladimir's proposal of doing one example of a conversion in detail is
> sensible enough, but I don't think it will change anybody's feelings
> on this matter.  I bet the results will look better to people who like
> C++, and unconvincing to people who like C; indeed, Eli's already said
> as much for the latter side.

For the record, on my daytime job we develop and maintain a very large
body of extremely object-oriented C++ code.  So much for me being on
``the latter side''.

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From: David Carlton <david.carlton@sun.com>
> Date: Wed, 30 Jul 2008 12:56:14 -0700
> 
> Some people strongly prefer to work (on large scale projects) in C,
> and really don't want to work in C++.  Some people strongly prefer to
> work in C++, and really don't want to work in C.  (And some people
> would rather work in Java, or Ruby, or Haskell, but none of those are
> realistic options for a GDB transition, so I'm ignoring them.)

FWIW, at least for me, this is not a language choice issue, this is an
issue of making a decision whether to invest a non-trivial amount of
time and effort into refactoring.  I would say the same things I did
in this thread if someone would suggest to refactor GDB in C.

> Given that, we can talk about technical advantages or disadvantages
> until we're blue in the face, but I don't think that will get us any
> farther.  We've already seen examples of how GDB is reimplementing
> almost every C++ concept that you can think of in C; for the C++ fans,
> that's convincing evidence that GDB development would proceed more
> smoothly in C++ (those constructs could be done with less work), while
> for the C fans, that's convincing evidence that GDB development
> doesn't need C (proof by existence).
> 
> And I don't see that more examples are going to help much.  I think
> Vladimir's proposal of doing one example of a conversion in detail is
> sensible enough, but I don't think it will change anybody's feelings
> on this matter.  I bet the results will look better to people who like
> C++, and unconvincing to people who like C; indeed, Eli's already said
> as much for the latter side.

For the record, on my daytime job we develop and maintain a very large
body of extremely object-oriented C++ code.  So much for me being on
``the latter side''.

Re: Move GDB to C++ ?

[Michael Veksler]

David Carlton wrote:
> Which language will lead to more people enjoying contributing to GDB?
> Which language will lead to more people feeling like they can work at
> full productivity while contributing to GDB? How will the choice of
> language affect GDB's institutional memory? How will the choice of
> language affect whether or not newcomers are likely to join in,
> whether or not they're likely to stay involved?
>
I have never contributed one line of code to GDB, however this could
be different.

The story:
Several years ago I have encountered a crippling bug for AIX+g++
debugging which would make gdb crash on the first breakpoint.
It is possible that there is a PR for this, I don't remember.

The cause for the crash was that some of the stabs debug info got 
reordered by
AIX's /bin/ld and /bin/as (which seems to be within the spec, by the way).
This reordering sometimes confused gdb and an assertion was fired up.
After seeing the mess of gdb code in that area I gave up fixing this bug in
gdb.

What I ended up doing is to hack gcc-3.2 to emit redundant debug 
information,
such that reordering will not make any difference for gdb. Unfortunately,
gcc would not accept my 10 lines patch (because the bug was not in gcc)
and I had to maintain a private gcc (which I ended up sending to several
people who found me through google).

My conclusion:
If GDB had used c++ std containers it would be much easier for
me to *read* the code and then reorganize it. I don't claim that debugging
C++ is any easier, but I do claim that understanding code *intent* is 
easier
(as long as the coders follow the prime guideline - do not surprise the 
reader)

I would have written a 1000 lines patch if I could only figure out what
gdb was doing in a reasonable amount of time. I *believe* that if that 
piece
of code had used std containers then gdb would see more random
contributions than it does today (in that piece of code).
This is only my personal belief. I am biased since I have been writing c++
code for the past 11 years (wrote C for 5 years before that).

Against c++ I would say that writing good c++ code (without shooting 
yourself
through all your limbs) requires self control and experience. Sometimes it
requires deep knowledge of weird corners in the language (which took me 
years
to mostly master). Simply minimize your friction with such corners by 
e.g. defining
templates only in very rare cases when the benefits are huge and several 
experts
are willing to provide nearly 24h/7 support for them (or avoid them 
altogether).

I will never remember the rules for writing a template function which is 
a friend
of a template class - inside the class definition (every compiler has 
different corner
cases and bugs for this kind of stuff), I simply avoid it - not worth 
the trouble.

Michael

Re: Move GDB to C++ ?

[Ian Lance Taylor]

Eli Zaretskii <eliz@gnu.org> writes:

>> I think much of Ian's PDF on moving GCC to C++ applies just as well to
>> gdb:
>> 
>>     http://www.airs.com/ian/cxx-slides.pdf
>
> Those slides have only one _real_ GCC-specific argument in favor of
> C++: on slide 11.  All the rest is general comparison between C and
> C++ based on toy examples.

I think that is an unfair criticism.  Every C example on those slides
came directly from the gcc source code, simplified to fit on the
slide.  In fact, I think the simplification actually makes the C code
look better than it really is, but I needed slides to show examples
while I spoke, so my space was limited.


I tend to think that gdb would be improved by moving to C++: I think
it would make it easier to maintain the code.  Many of the objections
seem to take two general forms:

1) "It could get worse."  That's right: it could get worse.  But gdb
could get worse without changing languages.  The way you keep it from
getting worse is by writing good code and by selecting good
maintainers.  Choice of language is a relatively minor factor in
reducing code quality.

2) "It's too much work."  Yes, it's a lot of work.  If you aren't
interested, don't do the work.  If other people are willing to do the
work, think carefully about whether you want to reject their efforts,
and why.  If other people are not willing to do the work, then for
sure it won't happen.


I'm on the gdb steering committee, but my personal opinion is that
choice of language is a technical decision best made by the active
maintainers, not a steering committee decision.  I am not, of course,
an active maintainer.

Ian

Re: Move GDB to C++ ?

[Vladimir Prus]

Eli Zaretskii wrote:

>> From:  Vladimir Prus <vladimir@codesourcery.com>
>> Date:  Tue, 29 Jul 2008 21:28:05 +0400
>> 
>> 1. GDB is made compiled with C++ compiler, with resulting errors removed.
>> 2. I refactor struct value, and folks get to comment if the resulting code
>> is better, or worse, than what we have.
>> 
>> Comments?
> 
> My only comment is a question: what for?  I simply don't see the
> intended purpose or the goal of this.
> 
> I happen to manage software projects for a living, and whenever we
> need to upgrade or change some of our tools, it is always because we
> need to do something that is impossible or very inconvenient with the
> existing ones.  We never do it out of some abstract wish of "improving
> the design" or "refactoring" for their own sake.
> 
> So will someone please tell, loud and clear: what do we want to do the
> day after GDB is rewritten in C++?  Let's suppose that we magically
> fast-forward to the day after everything was refactored and GDB is
> 110% pure, OO, C++ -- what will we do the next day that we cannot or
> have difficulties doing today?

As you surely know, most languages are Turing-complete, so you can
do everything in any language, including assembler. The goal, 
purely, is to spend less time fighting with the language, and more 
time doing useful things.

> Unless we can answer this question, refactoring and rewriting is
> simply waste of resources, nothing less, nothing more.

And here, you also surely know what is generally goal of refactoring --
to make code simpler and more amendable for future change. This naturally
means that you need either some immediate change to make, or general
idea what will block many future changes. I do think that struct value
needs refactoring -- because I know that adding new kind of value was
a pain in current codebase. I do think that target stack needs cleanup,
because we ran in some inconveniences during non-stop work, and because
multi-process work will have to change it seriously. 

Those areas do need to be refactored to be hackable-on, and such refactoring
better make use of a language suited for OOP -- which those areas try to
approximate using C, now.

- Volodya

Re: Move GDB to C++ ?

[Salvatore Lionetti]

Hi to all,

i'm looking in symbol management and dwarf module.

- i think now is the time to refactor, expecially of interfaces between subsystem
- Language should be a secondary  issue, also if for example try cacth is better if offered by host language;)
- I'm available to work to same piece of code, expecially on symbol management.

Have a good day

--- Mer 30/7/08, Vladimir Prus <vladimir@codesourcery.com> ha scritto:

> Da: Vladimir Prus <vladimir@codesourcery.com>
> Oggetto: Re: Move GDB to C++ ?
> A: gdb@sources.redhat.com
> Data: Mercoledì 30 luglio 2008, 09:18
> Eli Zaretskii wrote:
> 
> >> From:  Vladimir Prus
> <vladimir@codesourcery.com>
> >> Date:  Tue, 29 Jul 2008 21:28:05 +0400
> >> 
> >> 1. GDB is made compiled with C++ compiler, with
> resulting errors removed.
> >> 2. I refactor struct value, and folks get to
> comment if the resulting code
> >> is better, or worse, than what we have.
> >> 
> >> Comments?
> > 
> > My only comment is a question: what for?  I simply
> don't see the
> > intended purpose or the goal of this.
> > 
> > I happen to manage software projects for a living, and
> whenever we
> > need to upgrade or change some of our tools, it is
> always because we
> > need to do something that is impossible or very
> inconvenient with the
> > existing ones.  We never do it out of some abstract
> wish of "improving
> > the design" or "refactoring" for their
> own sake.
> > 
> > So will someone please tell, loud and clear: what do
> we want to do the
> > day after GDB is rewritten in C++?  Let's suppose
> that we magically
> > fast-forward to the day after everything was
> refactored and GDB is
> > 110% pure, OO, C++ -- what will we do the next day
> that we cannot or
> > have difficulties doing today?
> 
> As you surely know, most languages are Turing-complete, so
> you can
> do everything in any language, including assembler. The
> goal, 
> purely, is to spend less time fighting with the language,
> and more 
> time doing useful things.
> 
> > Unless we can answer this question, refactoring and
> rewriting is
> > simply waste of resources, nothing less, nothing more.
> 
> And here, you also surely know what is generally goal of
> refactoring --
> to make code simpler and more amendable for future change.
> This naturally
> means that you need either some immediate change to make,
> or general
> idea what will block many future changes. I do think that
> struct value
> needs refactoring -- because I know that adding new kind of
> value was
> a pain in current codebase. I do think that target stack
> needs cleanup,
> because we ran in some inconveniences during non-stop work,
> and because
> multi-process work will have to change it seriously. 
> 
> Those areas do need to be refactored to be hackable-on, and
> such refactoring
> better make use of a language suited for OOP -- which those
> areas try to
> approximate using C, now.
> 
> - Volodya


      Posta, news, sport, oroscopo: tutto in una sola pagina. 
Crea l&#39;home page che piace a te!
www.yahoo.it/latuapagina

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From:  Vladimir Prus <vladimir@codesourcery.com>
> Date:  Wed, 30 Jul 2008 11:18:09 +0400
> 
> > Unless we can answer this question, refactoring and rewriting is
> > simply waste of resources, nothing less, nothing more.
> 
> And here, you also surely know what is generally goal of refactoring --
> to make code simpler and more amendable for future change.

No, refactoring always has some specific goal.  Only given a specific
goal, can one weigh the alternatives -- one to keep existing design
and code and change it, the other to refactor it and then extend the
result.  You need to have a clear goal so that you could balance
advantages against disadvantages.  Without a goal, all you have is
disadvantages (the overhead and effort of refactoring), because
advantages cannot be estimated without a specific goal in sight.  How
do you estimate an advantage of ``making code simpler and more
amenable to change''?  You can't.

> I do think that struct value needs refactoring -- because I know
> that adding new kind of value was a pain in current codebase.

But if we won't add another kind in 10 years, maybe that's not a
problem?

And anyway, can you present a convincing case for refactoring struct
value, one that shows the details of adding a new kind each way?

> I do think that target stack needs cleanup, because we ran in some
> inconveniences during non-stop work, and because multi-process work
> will have to change it seriously.

Again, please be specific: show me how doing this in C++ would be much
better than in C.

> Those areas do need to be refactored to be hackable-on, and such refactoring
> better make use of a language suited for OOP -- which those areas try to
> approximate using C, now.

Sorry, this is circular reasoning.  I'm hacking GDB since 1999
(although not as much as I would like to), and I never had any special
need for OOP.  Not even when I introduced cross-platform code such as
x86 watchpoint support.  It will take more than just general
hand-waving to convince me.

Re: Move GDB to C++ ?

[Stan Shebs]

Eli Zaretskii wrote:
>> From:  Vladimir Prus <vladimir@codesourcery.com>
>> Date:  Wed, 30 Jul 2008 11:18:09 +0400
>>
>>     
>>> Unless we can answer this question, refactoring and rewriting is
>>> simply waste of resources, nothing less, nothing more.
>>>       
>> And here, you also surely know what is generally goal of refactoring --
>> to make code simpler and more amendable for future change.
>>     
>
> No, refactoring always has some specific goal.  Only given a specific
> goal, can one weigh the alternatives -- one to keep existing design
> and code and change it, the other to refactor it and then extend the
> result.  You need to have a clear goal so that you could balance
> advantages against disadvantages.  Without a goal, all you have is
> disadvantages (the overhead and effort of refactoring), because
> advantages cannot be estimated without a specific goal in sight.  How
> do you estimate an advantage of ``making code simpler and more
> amenable to change''?  You can't.
>   
But to be fair, the coding standards we already impose don't usually 
have quantifiable benefits. In fact your argument could be used against 
any kind of abstraction in the code (how do you prove that the target 
stack is advantageous over some other design?), or against the adding of 
comments (can you demonstrate that any particular comment block is 
helping any other developers?).

I actually think this is one of the unheralded strengths of free 
software over proprietary - we're always able to transform the code into 
something we all *want* to work on. By contrast, proprietary code so 
often degenerates into undocumented spaghetti, because it only gets 
touched when there is an obvious short-term benefit, and only touched 
enough to realize the short-term result.

If everybody simply said "yes, I would prefer working on a GDB written 
in C++", I would consider that sufficient justification all by itself, 
even if there were no technical reasons.

Stan

Re: Move GDB to C++ ?

[Mark Kettenis]

> Date: Tue, 29 Jul 2008 12:51:51 -0400
> From: Andrew Cagney <cagney@gnu.org>
> 
> Mark Kettenis wrote:
> >> Date: Thu, 10 Jul 2008 11:46:15 -0700
> >> From: Stan Shebs <stanshebs@earthlink.net>
> >>
> >> As many know, there is a project afoot to investigate the recoding of 
> >> GCC from C into C++. I believe the C++ idea was briefly touched on for 
> >> GDB at the summit, although I don't remember much discussion. Anyway, 
> >> this would be a good time to start thinking about it, and if people are 
> >> generally in favor of the idea, we can start small by tweaking the 
> >> sources to be C++-friendly, avoiding keywords and so forth; GCC has a 
> >> new warning flag -Wcxx-compat that can help.
> >>     
> >
> > I think this is an absolutely retarded idea.  C++ is a horrible
> > programming language.
> >   
> Mark,
> 
> I appreciate your pain here - as some would put it "C++ is the answer, 
> now what was the question? :-)" - and having considered this further, 
> wonder if both this thread and a proposed implementation as part of the 
> archer project are being too quick to put the C++ cart before the 
> architectural horse :-)
> 
> Instead of changing GDB to C++ and hoping the change will magically 
> transform GDB's code base into a clean ideal design; should we instead 
> be focused on trying to address what I suspect is the underlying 
> motivation here - a desire to clean up and re-structure GDB's code base 
> so that it more clearly corresponds to a more modern Object Oriented design?
> 
> If we consider this as an important goal, and find a way to more 
> smoothly facilitate this development (multi-arch, at 9 years, in my not 
> so humble opinion, was too slow)  we'll be able to improve GDB's 
> internal architecture without using C++.  Then, in time, with a clearer 
> O-O design, we can re-consider choices such as language.
> 
> Thoughts?

Andrew, I agree with much of what you're saying here.  There are many
areas in GDB that could use the attention of someone who can take
astep back from it and see whether a subsystem can be transformed in
something that's constructed in a simpler and more straightforward
way.  I don't believe for a moment that switching to C++ will help
with that (let alone that switching to C++ will make this happen
automagically).  Virtually every C++ software project that I've seen
in my life suffers from overdesign (useless abstraction layers,
misapplied "design patterns", escalated generic programming).  I
stronly believe it is better to invest our time in cleaning up and
extending the existing codebase instead of converting it to a new
programming language.

I really feel all these discussions about our toold (switching from
cvs to svn or git, replacing C with C++, migrating our bugs from gnats
to bugzilla) are a waste of time.

Re: Move GDB to C++ ?

[Jan Kratochvil]

On Thu, 10 Jul 2008 20:46:15 +0200, Stan Shebs wrote:
> For my part, I think we should do it. GDB has quite a bit of object-like  
> structure internally,

+1  (as GObject is unfortunately not going to win it)


Regards,
Jan

Re: Move GDB to C++ ?

[Tom Tromey]

>>>>> "Stan" == Stan Shebs <stanshebs@earthlink.net> writes:

Stan> As many know, there is a project afoot to investigate the
Stan> recoding of GCC from C into C++.

I'll send a separate note about this soon, probably tomorrow.

Thanks for raising this topic -- very brave!

Stan> For my part, I think we should do it. GDB has quite a bit of
Stan> object-like structure internally

I think GDB is nearly written in a dialect of C++ already:

* It uses exceptions all over the place.
  Instead of throw, gdb uses error().
  Instead of try{} catch{}, gdb uses TRY_CATCH.

* RAII is omnipresent, in the form of cleanups.

* Classes exist.  For instance, struct cmd_list_element is a class
  with a constructor, various fields, accessor methods, and some
  virtual methods.

* Subclasses are in use too.  The 'struct expression' and 'struct
  type' classes essentially have subclasses, they are just written as
  discriminated unions or whatnot.

* Templates are used in at least one place -- vec.h.

* I think function overloading is in use too, and default arguments.
  One example is parse_exp_1 and parse_exp_in_context.

In all these cases, the C++ code is, in my opinion, simpler to read
and write than the corresponding gdb code.  It is also more regular;
whereas in gdb some "virtual methods" take a 'this' pointer, some do
not; some classes have destructors, some do not (these are both things
I ran into on the Python branch).  Finally, C++ provides better
support for abstraction, specifically via access control.

So, I am in favor of this change.

Tom

Re: Move GDB to C++ ?

[Andrew STUBBS]

Tom Tromey wrote:
> I think GDB is nearly written in a dialect of C++ already:

...

> In all these cases, the C++ code is, in my opinion, simpler to read
> and write than the corresponding gdb code.  It is also more regular;
> whereas in gdb some "virtual methods" take a 'this' pointer, some do
> not; some classes have destructors, some do not (these are both things
> I ran into on the Python branch).  Finally, C++ provides better
> support for abstraction, specifically via access control.

I tend to agree with this statement. In particular I would say that 
destructors would be much easier to follow than cleanups.

I'm not going to make any judgement about whether there's a business 
case for doing the work, but here's a question:

A while ago there was some idea of a libgdb that would abstract the 
debugger back end from the interface (or I may have totally 
misunderstood what the whole thing was about). I haven't heard much 
about it recently, and the libgdb that exists seems to be something of a 
build artefact, rather than a useful abstraction. If such an idea still 
exists, what affect would switching to C++ have on that plan? Would it 
make it easier? Or would it just make it incompatible with non-C++ projects?

Andrew

Re: Move GDB to C++ ?

[Daniel Jacobowitz]

On Fri, Jul 11, 2008 at 10:51:30AM +0100, Andrew STUBBS wrote:
> A while ago there was some idea of a libgdb that would abstract the  
> debugger back end from the interface (or I may have totally misunderstood 
> what the whole thing was about). I haven't heard much about it recently, 
> and the libgdb that exists seems to be something of a build artefact, 
> rather than a useful abstraction. If such an idea still exists, what 
> affect would switching to C++ have on that plan? Would it make it easier? 
> Or would it just make it incompatible with non-C++ projects?

I don't think such an idea still exists.  We've sunk our effort into
MI instead.

Oddly, even though the idea doesn't exist, it has one user that I know
of (in the Free Pascal IDE).  The way it works is quite terrifying;
there's a Pascal interface definition that includes several versions
of each of GDB's core types for selected GDB versions.

-- 
Daniel Jacobowitz
CodeSourcery

RE: Move GDB to C++ ?

[Pierre Muller]

> -----Message d'origine-----
> De : gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] De la
> part de Daniel Jacobowitz
> Envoyé : Friday, July 11, 2008 1:44 PM
> À : gdb@sourceware.org
> Objet : Re: Move GDB to C++ ?
> 
> On Fri, Jul 11, 2008 at 10:51:30AM +0100, Andrew STUBBS wrote:
> > A while ago there was some idea of a libgdb that would abstract the
> > debugger back end from the interface (or I may have totally
> misunderstood
> > what the whole thing was about). I haven't heard much about it
> recently,
> > and the libgdb that exists seems to be something of a build artefact,
> > rather than a useful abstraction. If such an idea still exists, what
> > affect would switching to C++ have on that plan? Would it make it
> easier?
> > Or would it just make it incompatible with non-C++ projects?
> 
> I don't think such an idea still exists.  We've sunk our effort into
> MI instead.
> 
> Oddly, even though the idea doesn't exist, it has one user that I know
> of (in the Free Pascal IDE).  The way it works is quite terrifying;
> there's a Pascal interface definition that includes several versions
> of each of GDB's core types for selected GDB versions.

  You can blame ME, I wrote part of that stuff, and it is horrible to 
maintain too...
  Just look at the source:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/gdbint/src/gdbin
t.pp?view=log

  And the current version does not have all the tweaks
about older GDB releases for which some fields in some of the
structs where missing.
  Another big trouble was the offsets, and I am still not sure
it works correctly for 64 bit architechtures...

  But it is still very useful...

  To come back to the main topic about moving
GDB sources to C++, Ii must confess that I am a
pascal programmer by hart. 
  I only came to C for the beauty of GDB itself!
To be able to add pascal support for GDB (which is still
far from good, but at least usable).
  When I see all the troubles about debugging pascal object/classes,
I suspect that C++ will still also have some subtleties.

  I would really hate to not be able to debug GDB with itself! 
Even nowadays, I still get complaints about incomplete types
when I debug GDB with itself, so I imagine that this would become
much more common.
 
  But I am an old dinosaur, and I also resisted at that time
the move of Free Pascal compiler sources from
pascal objects to classes, because of similar doubts.

  I must confess that some things are now much clearer 
in the implementation of the Free Pascal compiler thanks to that
switch.

  And the argument that we are already using hidden class programming
is quite relevant...
  Using classes is probably a good thing, but I would be scared
that people start to use sophisticated C++ features that I 
do not understand :(


Pierre Muller
Pascal language support maintainer for GDB

Re: Move GDB to C++ ?

[Andrew Cagney]

Andrew STUBBS wrote:
> Tom Tromey wrote:
>> I think GDB is nearly written in a dialect of C++ already:
>
> ...
>
>> In all these cases, the C++ code is, in my opinion, simpler to read
>> and write than the corresponding gdb code.  It is also more regular;
>> whereas in gdb some "virtual methods" take a 'this' pointer, some do
>> not; some classes have destructors, some do not (these are both things
>> I ran into on the Python branch).  Finally, C++ provides better
>> support for abstraction, specifically via access control.
>
> I tend to agree with this statement. In particular I would say that 
> destructors would be much easier to follow than cleanups.
>
> I'm not going to make any judgement about whether there's a business 
> case for doing the work, but here's a question:
>
> A while ago there was some idea of a libgdb that would abstract the 
> debugger back end from the interface (or I may have totally 
> misunderstood what the whole thing was about). I haven't heard much 
> about it recently, and the libgdb that exists seems to be something of 
> a build artefact, rather than a useful abstraction.

I think of it as a good high level concept, but yes, as Daniel points 
out, the libgdb implementation and approach are long dead.  For 
instance, if gdb were more clearly broken into a number of components, 
we'd be able to implement tools such as gstack and gcore directly (as 
they were intended) and not as wrappers or hacks around the gdb cli.  An 
initial step might be to clarify these internal interfaces, any thoughts 
on that?

> If such an idea still exists, what affect would switching to C++ have 
> on that plan? Would it make it easier? Or would it just make it 
> incompatible with non-C++ projects?
>
I think it would help.  For instance, Eclipse has started pushing a more 
abstract debugger interface - DSF - it expects the target to implement a 
very abstract O-O model of the target system.  Being able to implement 
such an O-O models directly in an O-O language would greatly simplify 
things.

Such an abstraction may even prove useful to the Python bindings, I'd 
imagine the combination of that and PyGtk to be a very empowering.

-

Re: Move GDB to C++ ?

[Tom Tromey]

>>>>> "Tom" == Tom Tromey <tromey@redhat.com> writes:

Tom> * Templates are used in at least one place -- vec.h.

I found another gdb-specific example of this: observers.  A given
observer is essentially an instance of a template class.

Tom

Re: Move GDB to C++ ?

[Nick Roberts]

 > Tom> * Templates are used in at least one place -- vec.h.
 > 
 > I found another gdb-specific example of this: observers.  A given
 > observer is essentially an instance of a template class.

From my point of view, another benefit of using C++, is presumably that
variable objects could be represented as linked lists, rather than use the
current vector API which, for reasons I've already given, I think is
unsuitable.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Move GDB to C++ ?

[Vladimir Prus]

Nick Roberts wrote:

>  > Tom> * Templates are used in at least one place -- vec.h.
>  > 
>  > I found another gdb-specific example of this: observers.  A given
>  > observer is essentially an instance of a template class.
> 
> From my point of view, another benefit of using C++, is presumably that
> variable objects could be represented as linked lists, rather than use the
> current vector API which, for reasons I've already given, I think is
> unsuitable.

Without getting into that discussion again, it's clear that either std::vector,
or std::list, or std::deque, are much better than anything implementable in C.

- Volodya

Re: Move GDB to C++ ?

[Robert Dewar]

Vladimir Prus wrote:
> Nick Roberts wrote:
> 
>>  > Tom> * Templates are used in at least one place -- vec.h.
>>  > 
>>  > I found another gdb-specific example of this: observers.  A given
>>  > observer is essentially an instance of a template class.
>>
>> From my point of view, another benefit of using C++, is presumably that
>> variable objects could be represented as linked lists, rather than use the
>> current vector API which, for reasons I've already given, I think is
>> unsuitable.
> 
> Without getting into that discussion again, it's clear that either std::vector,
> or std::list, or std::deque, are much better than anything implementable in C.

Sure, but that's a narrow view from the language point only. You have to 
take into full account many factors including:

a) some maintainers dislike for C++ that may reduce their contributions

b) some maintainers who simply don't care to mess with another language

c) the danger of unnecessary complex stuff creeping in if there is
insufficient control and code review.

d) the transition costs are non-negligible

e) the increased commplexity of the environment necessary to build
GDB. Speaking a moment from AdaCore's point of view as an example,
this would mean we had to build and maintain C++ compilers on dozens
of configurations. We can probably do this, but it is not zero work,
and I have no idea how other organizations would be affected.

f) the danger that points a) through e) together might lead to a
divergence in the development path.

My inclination is that the minuses outweigh the pluses.

To make this point clearer, suppose I suggested we recode the
whole of GDB in Ada. From purely a language point of view, the
technical arguments in favor of such a recoding would be very
strong, and indeed I would be happy to argue and demonstrate
that from purely a language point of view, this would be a
better choice than C++.

However, everyone (including me) would agree that in this case
a) through f) would outweigh any technical langauge advantage,
so much so that the proposal would not be considered seriously
at all.

Obviously the transition from C to C++ would be easier, but I
see too much of the argument focused on the language advantages,
and not enough on the balance of the negative and positive points.

However

Re: Move GDB to C++ ?

[Vladimir Prus]

On Monday 14 July 2008 17:21:28 Robert Dewar wrote:
> Vladimir Prus wrote:
> > Nick Roberts wrote:
> > 
> >>  > Tom> * Templates are used in at least one place -- vec.h.
> >>  > 
> >>  > I found another gdb-specific example of this: observers.  A given
> >>  > observer is essentially an instance of a template class.
> >>
> >> From my point of view, another benefit of using C++, is presumably that
> >> variable objects could be represented as linked lists, rather than use the
> >> current vector API which, for reasons I've already given, I think is
> >> unsuitable.
> > 
> > Without getting into that discussion again, it's clear that either std::vector,
> > or std::list, or std::deque, are much better than anything implementable in C.
> 
> Sure, but that's a narrow view from the language point only. 

You might want to note that I was replying to Nick comments about data structures only;
whereas I have a more broad opinion about C++, I was not trying to express it here.

> You have to  
> take into full account many factors including:
> 
> a) some maintainers dislike for C++ that may reduce their contributions

Are you sure no maintainer dislike C? 

> c) the danger of unnecessary complex stuff creeping in if there is
> insufficient control and code review.

We already have unnecessary complex stuff, which is poorly documented in sources,
and not documented in any lecture courses or books. Like, exceptions and cleanups.

> b) some maintainers who simply don't care to mess with another language
> 
> d) the transition costs are non-negligible

You might want to note that the ongoing cost of using improper tools are not
zero, either.

> 
> e) the increased commplexity of the environment necessary to build
> GDB. Speaking a moment from AdaCore's point of view as an example,
> this would mean we had to build and maintain C++ compilers on dozens
> of configurations. We can probably do this, but it is not zero work,
> and I have no idea how other organizations would be affected.
> 
> f) the danger that points a) through e) together might lead to a
> divergence in the development path.

This is strong statement. Do you have the evidence that such a divergence
will happen among those folks who *actively* contribute things?

> My inclination is that the minuses outweigh the pluses.
> 
> To make this point clearer, suppose I suggested we recode the
> whole of GDB in Ada. From purely a language point of view, the
> technical arguments in favor of such a recoding would be very
> strong, and indeed I would be happy to argue and demonstrate
> that from purely a language point of view, this would be a
> better choice than C++.
> 
> However, everyone (including me) would agree that in this case
> a) through f) would outweigh any technical langauge advantage,
> so much so that the proposal would not be considered seriously
> at all.

Well, there are obvious *practical* differences between C++ and Ada,
which makes C++ more viable for any codebase presently in C.

> 
> Obviously the transition from C to C++ would be easier, but I
> see too much of the argument focused on the language advantages,
> and not enough on the balance of the negative and positive points.

I think that it's pretty much impossible to get accurate estimate of
benefit/cost ratio, especially when benefit includes such abstract
things as developer's productivity, and elimination of the current wards,
especially wards for potential new contributors. 

I think that in this case, the most important argument is that GDB already
uses most of the features C++ has to offer -- except in non-standard and
undocumented way. Switch to C++ will make that better. The only price to
pay is requiring C++ compiler -- and given that the GNU project makes GCC,
I just don't see the issue.

- Volodya

Re: Move GDB to C++ ?

[Robert Dewar]

Vladimir Prus wrote:

> I think that in this case, the most important argument is that GDB already
> uses most of the features C++ has to offer -- except in non-standard and
> undocumented way. Switch to C++ will make that better. The only price to
> pay is requiring C++ compiler -- and given that the GNU project makes GCC,
> I just don't see the issue.

OK, thats worrisome (that you dont see the issue). Because for
sure this is a consideration. The effort of building, properly
installing, and maintaining an appropriate version of g++ that
will make it possible to build and debug gdb is definitely not
zero. Sure there are no conceptual difficulties, but that does
not mean it is zero work from a system administration point of
view.

Re: Move GDB to C++ ?

[Robert Dewar]

Vladimir Prus wrote:

>> a) some maintainers dislike for C++ that may reduce their contributions
> 
> Are you sure no maintainer dislike C? 

I never indicated an opinion on this, let alone that I was sure,
indeed this is discussable.
> 
>> c) the danger of unnecessary complex stuff creeping in if there is
>> insufficient control and code review.
> 
> We already have unnecessary complex stuff, which is poorly documented in sources,
> and not documented in any lecture courses or books. Like, exceptions and cleanups.

Right, but I still think it's a danger that should be discussed
> 
>> b) some maintainers who simply don't care to mess with another language
>>
>> d) the transition costs are non-negligible
> 
> You might want to note that the ongoing cost of using improper tools are not
> zero, either.

Well of course not everyone agrees with the "improper" here, but
for sure discussion of ongoing and long term advantages is
appropriate

>> f) the danger that points a) through e) together might lead to a
>> divergence in the development path.
> 
> This is strong statement. Do you have the evidence that such a divergence
> will happen among those folks who *actively* contribute things?

It's obviously a danger, if you think the danger is minimal, fine,
but it is important to make sure that there is a sufficient
consensus among all those involved to avoid this.

> I think that it's pretty much impossible to get accurate estimate of
> benefit/cost ratio, especially when benefit includes such abstract
> things as developer's productivity, and elimination of the current wards,
> especially wards for potential new contributors. 

Not sure what "wards" means here (warts?) but anyway, in the absence
of some kind of reasonable estimate of bvenefit/cost ratio, there is
a strong argument for the status quo I would think, so I think it is
necessary to try to make this estimate, accurate is too strong, but
reasonable is reasonable :-)
> 
> I think that in this case, the most important argument is that GDB already
> uses most of the features C++ has to offer -- except in non-standard and
> undocumented way. Switch to C++ will make that better. The only price to
> pay is requiring C++ compiler -- and given that the GNU project makes GCC,
> I just don't see the issue.

Proper documentation is always a good thing, so to the extent that the
current issues are to do with undocumented stuff, I would fix them by
providinng the documentation before deciding that switching to another
language will magically fix the failure to document things well.

Re: Move GDB to C++ ?

[Vladimir Prus]

On Monday 14 July 2008 20:03:05 Robert Dewar wrote:
> Vladimir Prus wrote:
> 
> >> a) some maintainers dislike for C++ that may reduce their contributions
> > 
> > Are you sure no maintainer dislike C? 
> 
> I never indicated an opinion on this, let alone that I was sure,
> indeed this is discussable.
> > 
> >> c) the danger of unnecessary complex stuff creeping in if there is
> >> insufficient control and code review.
> > 
> > We already have unnecessary complex stuff, which is poorly documented in sources,
> > and not documented in any lecture courses or books. Like, exceptions and cleanups.
> 
> Right, but I still think it's a danger that should be discussed
>
> >> b) some maintainers who simply don't care to mess with another language
> >>
> >> d) the transition costs are non-negligible
> > 
> > You might want to note that the ongoing cost of using improper tools are not
> > zero, either.
> 
> Well of course not everyone agrees with the "improper" here, but
> for sure discussion of ongoing and long term advantages is
> appropriate
> 
> >> f) the danger that points a) through e) together might lead to a
> >> divergence in the development path.
> > 
> > This is strong statement. Do you have the evidence that such a divergence
> > will happen among those folks who *actively* contribute things?
> 
> It's obviously a danger, if you think the danger is minimal, fine,
> but it is important to make sure that there is a sufficient
> consensus among all those involved to avoid this.
> 
> > I think that it's pretty much impossible to get accurate estimate of
> > benefit/cost ratio, especially when benefit includes such abstract
> > things as developer's productivity, and elimination of the current wards,
> > especially wards for potential new contributors. 
> 
> Not sure what "wards" means here (warts?) but anyway, in the absence
> of some kind of reasonable estimate of bvenefit/cost ratio, there is
> a strong argument for the status quo I would think, so I think it is
> necessary to try to make this estimate, accurate is too strong, but
> reasonable is reasonable :-)

I think you're falling into a trap common for planning large transitions.
It seems reasonable to prepare of list of points, and compare alternatives
on each point. However, I never saw this work, because even if you and I
agree on one specific point, there's slim chance that 10 different people
will all agree on that single point. And if there are 10 different points
to discuss (with varying importance) and 20 different people (with varying 
degree of involvement, and varying backgrounds, and varying opinions about
the importance of the points), how do you come with a clear "yes"/"no" result?

Most transitions I saw involved:
1. A few folks pushing for specific solution that improves on the current
status quo.
2. Other folks expressing opinions like "we absolutely need XXX"

So, here, what are your most important concerns? Do you see those concerns can
be mitigated, or not?

> > 
> > I think that in this case, the most important argument is that GDB already
> > uses most of the features C++ has to offer -- except in non-standard and
> > undocumented way. Switch to C++ will make that better. The only price to
> > pay is requiring C++ compiler -- and given that the GNU project makes GCC,
> > I just don't see the issue.
> 
> Proper documentation is always a good thing, so to the extent that the
> current issues are to do with undocumented stuff, I would fix them by
> providinng the documentation before deciding that switching to another
> language will magically fix the failure to document things well.

The problem is the book named "The C++ Programming Language" went through at 
least 3 revisions, presumably with extra help of professional editors. Do we want
to beat that? And why newcomers who already read this book should read the
documentation for our non-standard mechanisms.

- Volodya

Re: Move GDB to C++ ?

[Robert Dewar]

Vladimir Prus wrote:

> I think you're falling into a trap common for planning large transitions.
> It seems reasonable to prepare of list of points, and compare alternatives
> on each point. However, I never saw this work, 

I have seen it work many times, and managed several transitions of
this type ...

> Most transitions I saw involved:
> 1. A few folks pushing for specific solution that improves on the current
> status quo.
> 2. Other folks expressing opinions like "we absolutely need XXX"

Sounds like they were badly mismanaged
> 
> So, here, what are your most important concerns? Do you see those concerns can
> be mitigated, or not?

> The problem is the book named "The C++ Programming Language" went through at 
> least 3 revisions, presumably with extra help of professional editors. Do we want
> to beat that? And why newcomers who already read this book should read the
> documentation for our non-standard mechanisms.

Well I don't know the code well enough, but what exactly do you mean
by non-standard here---not conforming to the C standard??? The GDB code
I *have* looked at all seems like fairly standard C to me!
> 
> - Volodya

Re: Move GDB to C++ ?

[Vladimir Prus]

On Monday 14 July 2008 20:39:21 Robert Dewar wrote:
> Vladimir Prus wrote:
> 
> > I think you're falling into a trap common for planning large transitions.
> > It seems reasonable to prepare of list of points, and compare alternatives
> > on each point. However, I never saw this work, 
> 
> I have seen it work many times, and managed several transitions of
> this type ...

Probably, you've managed that in a commercial company? Because in open-source,
you rarely have a single manager who can be used to resolve issues on which 
no concensus can be reached in reasonable time. 

> > Most transitions I saw involved:
> > 1. A few folks pushing for specific solution that improves on the current
> > status quo.
> > 2. Other folks expressing opinions like "we absolutely need XXX"
> 
> Sounds like they were badly mismanaged

You are free to feel this way. But to give a concrete example, switch to SVN, for many
projects such as GCC or C++ Boost, definitely improved things and therefore were much
better thing than endlessly discussion which version control is best.

> > So, here, what are your most important concerns? Do you see those concerns can
> > be mitigated, or not?
> 
> > The problem is the book named "The C++ Programming Language" went through at 
> > least 3 revisions, presumably with extra help of professional editors. Do we want
> > to beat that? And why newcomers who already read this book should read the
> > documentation for our non-standard mechanisms.
> 
> Well I don't know the code well enough, but what exactly do you mean
> by non-standard here---not conforming to the C standard??? 

I mean a high-level design patterns and constructs that closely correspond
to existing constructs of C++, but yet implemented in a home-grown way,
and unknown to either C++ programmers or C programmers outside GDB.

> The GDB code 
> I *have* looked at all seems like fairly standard C to me!

Tom has posted a list of such things in GDB, did you look at that list?

- Volodya

Re: Move GDB to C++ ?

[Thiago Jung Bauermann]

On Mon, 2008-07-14 at 21:52 +0400, Vladimir Prus wrote:
> On Monday 14 July 2008 20:39:21 Robert Dewar wrote:
> > > The problem is the book named "The C++ Programming Language" went through at 
> > > least 3 revisions, presumably with extra help of professional editors. Do we want
> > > to beat that? And why newcomers who already read this book should read the
> > > documentation for our non-standard mechanisms.
> > 
> > Well I don't know the code well enough, but what exactly do you mean
> > by non-standard here---not conforming to the C standard??? 
> 
> I mean a high-level design patterns and constructs that closely correspond
> to existing constructs of C++, but yet implemented in a home-grown way,
> and unknown to either C++ programmers or C programmers outside GDB.

I wholeheartedly agree with Vladimir's points. The cost of keeping GDB
source as it is should be weighted in as well.

FWIW, I've been hacking in GDB for the past year and a half, and just a
couple weeks ago I started to understand the cleanup mechanism and use
it in my code.

I also still don't understand how the exceptions mechanism work (I
always trust the TRY_CATCH and EXCEPT macros will do the necessary magic
for me), and somebody even told me that it doesn't work well, in
reality.

> > The GDB code 
> > I *have* looked at all seems like fairly standard C to me!
> 
> Tom has posted a list of such things in GDB, did you look at that list?

Indeed, that's a very good list.
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center

Re: Move GDB to C++ ?

[Mark Kettenis]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Mon, 14 Jul 2008 20:23:04 +0400
>
> > Proper documentation is always a good thing, so to the extent that the
> > current issues are to do with undocumented stuff, I would fix them by
> > providinng the documentation before deciding that switching to another
> > language will magically fix the failure to document things well.
> 
> The problem is the book named "The C++ Programming Language" went
> through at least 3 revisions, presumably with extra help of
> professional editors. Do we want to beat that? And why newcomers who
> already read this book should read the documentation for our
> non-standard mechanisms.

Oh, I think I have a copy of that book somewhere.  It's heavy enough
to kill a decent-sized bird with.  It has at least an order of
magnitude more pages than the book I learnt C from.  And I doubt it
can replace a significant fraction of the GDB internals documentation.

Re: Move GDB to C++ ?

[Daniel Jacobowitz]

On Mon, Jul 14, 2008 at 07:53:30PM +0400, Vladimir Prus wrote:
> I think that in this case, the most important argument is that GDB already
> uses most of the features C++ has to offer -- except in non-standard and
> undocumented way. Switch to C++ will make that better. The only price to
> pay is requiring C++ compiler -- and given that the GNU project makes GCC,
> I just don't see the issue.

Consider requiring the C++ runtime, then... this would be a problem
for CodeSourcery in the same way that it would be for AdaCore.
Solvable in both cases, and I have no qualms about solving it, but it
will be some work.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Move GDB to C++ ?

[Robert Dewar]

Daniel Jacobowitz wrote:
> On Mon, Jul 14, 2008 at 07:53:30PM +0400, Vladimir Prus wrote:
>> I think that in this case, the most important argument is that GDB already
>> uses most of the features C++ has to offer -- except in non-standard and
>> undocumented way. Switch to C++ will make that better. The only price to
>> pay is requiring C++ compiler -- and given that the GNU project makes GCC,
>> I just don't see the issue.
> 
> Consider requiring the C++ runtime, then... this would be a problem
> for CodeSourcery in the same way that it would be for AdaCore.
> Solvable in both cases, and I have no qualms about solving it, but it
> will be some work.

Right, indeed, I am not saying this cannot be done, just that the
infrastructure work needed, especially on multiple targets, is not
trivial.

> 

Re: Move GDB to C++ ?

[Robert Dewar]

Daniel Jacobowitz wrote:

> Consider requiring the C++ runtime, then... this would be a problem
> for CodeSourcery in the same way that it would be for AdaCore.
> Solvable in both cases, and I have no qualms about solving it, but it
> will be some work.

And of course CodeSourcery does have some experience with g++ :-)
so it is instructive that even there it would be some work to make
the transition, of course as Daniel says, this can certainly be done,
but I think it is important to understand all the costs in such a
transition.

Re: Move GDB to C++ ?

[Bob Rossi]

On Mon, Jul 14, 2008 at 12:17:42PM -0400, Robert Dewar wrote:
> Daniel Jacobowitz wrote:
>
>> Consider requiring the C++ runtime, then... this would be a problem
>> for CodeSourcery in the same way that it would be for AdaCore.
>> Solvable in both cases, and I have no qualms about solving it, but it
>> will be some work.
>
> And of course CodeSourcery does have some experience with g++ :-)
> so it is instructive that even there it would be some work to make
> the transition, of course as Daniel says, this can certainly be done,
> but I think it is important to understand all the costs in such a
> transition.

Just think about mingw. I wasn't able to get dwarf2 working, I had
to rever back to stabs to debug a C++ program.

Cygwin is still using a version of 3.4.5.

There are platforms that will require a significant amount of work, to
port gdb nicely too. Just some thoughts.

Bob Rossi

Re: Move GDB to C++ ?

[Vladimir Prus]

On Monday 14 July 2008 20:12:28 Daniel Jacobowitz wrote:
> On Mon, Jul 14, 2008 at 07:53:30PM +0400, Vladimir Prus wrote:
> > I think that in this case, the most important argument is that GDB already
> > uses most of the features C++ has to offer -- except in non-standard and
> > undocumented way. Switch to C++ will make that better. The only price to
> > pay is requiring C++ compiler -- and given that the GNU project makes GCC,
> > I just don't see the issue.
> 
> Consider requiring the C++ runtime, then... this would be a problem
> for CodeSourcery in the same way that it would be for AdaCore.
> Solvable in both cases, and I have no qualms about solving it, but it
> will be some work.

I recall we have this problem solved ;-) We did not actually push that
to the field, since we prototyped it with a library, which a customer 
might link into a application with different libstdc++, but GDB, been
a binary, would not have that issue.

- Volodya

 

Re: Move GDB to C++ ?

[Tom Tromey]

Stan> As many know, there is a project afoot to investigate the
Stan> recoding of GCC from C into C++.

Tom> I'll send a separate note about this soon, probably tomorrow.

Well, I totally misread your first sentence, prompting me to send out
something nonsensical.  Oh well, not the first time :)

I misread that "GCC" and thought you were referring to the discussions
taking place on the frysk list.  I was going to try to cross the
streams and post something here about that, but I think it may make
better sense to just have interested parties read and respond there.

thanks,
Tom

Re: Move GDB to C++ ?

[Michael Snyder]

On Thu, 2008-07-10 at 11:46 -0700, Stan Shebs wrote:
> As many know, there is a project afoot to investigate the recoding of 
> GCC from C into C++. I believe the C++ idea was briefly touched on for 
> GDB at the summit, although I don't remember much discussion. Anyway, 
> this would be a good time to start thinking about it, and if people are 
> generally in favor of the idea, we can start small by tweaking the 
> sources to be C++-friendly, avoiding keywords and so forth; GCC has a 
> new warning flag -Wcxx-compat that can help.
> 
> For my part, I think we should do it. GDB has quite a bit of object-like 
> structure internally, and while in the past it was taking a bit of a 
> chance to rely on the availability and reliability of C++ compilers, 
> those concerns are now generally outdated; I'm not sure any of the 
> potential problem hosts are even supported any longer.

While I do not love C++, I can see no harm in this suggestion.
Even if the full transition never happens, gdb will be no worse.

On Thu, 2008-07-10 at 16:39 -0400, Andrew Cagney wrote:
> The one question I would pose though, is bashing up the current GDB
code 
> base until it compiles with C++ a reasonable approach?  Each time C++ 
> has been suggested previously, that has been the proposed path forward, 
> and each time it has not moved (I've even tried it my self).  Perhaps, 
> instead, we should approach this more on a component basis - stack, 
> expr, type, proc, debug-info, ..., and convert each chunk in turn.

I think this is perfectly reasonable too -- and the two suggestions
are perfectly compatible.  I also like Stan's suggestion about
branches.

On Thu, 2008-07-10 at 23:26 -0700, Joel Brobecker wrote:
> That would be my concern #1. I really think that it's a huge plus
> to be able to build GDB with a C compiler. C++ compiler are just
> not as common as C compilers, particularly on more exotic platforms.

We recently made the jump from K&R to requiring an ANSI compiler.
Are we really all that far from requiring GCC?

Joel:
> My other major concern is debugability - I want to make sure that
> if we agree on the transition, GDB will be as easy to debug as before.
> I am way out of my league on this, but isn't it the case that:
>   - there's still some progress to be made to help debugging C++
>     in general (I might be VERY wrong on that one)

You're not entirely wrong -- but that argument cuts both ways.
If gdb is written in C++, that will force us to "eat our own
dog food", as it were... and maybe debug support for C++ will
improve.

>   - that stabs is not good enough to provide full C++ debugging support
> ?

In that you are correct.  But it's not all-or-nothing.
We should enumerate what parts of C++ are un-supportable
in stabs.

Andrew Cagney:
> ...  I suspect that, when we're 
> talking about that sort of time scale for an incremental approach, it 
> too runs the risk of limited commitment levels, and GDB finding itself 
> in a C vs C++ no-where land.

Yep, but the first step that Stan proposes is innocuous.
GDB will be no worse for being able to be compiled with 
  -Wcxx-compat .

Re: Move GDB to C++ ?

[Andrew Cagney]

Michael Snyder wrote:
> On Thu, 2008-07-10 at 11:46 -0700, Stan Shebs wrote:
>   
>> As many know, there is a project afoot to investigate the recoding of 
>> GCC from C into C++. I believe the C++ idea was briefly touched on for 
>> GDB at the summit, although I don't remember much discussion. Anyway, 
>> this would be a good time to start thinking about it, and if people are 
>> generally in favor of the idea, we can start small by tweaking the 
>> sources to be C++-friendly, avoiding keywords and so forth; GCC has a 
>> new warning flag -Wcxx-compat that can help.
>>
>> For my part, I think we should do it. GDB has quite a bit of object-like 
>> structure internally, and while in the past it was taking a bit of a 
>> chance to rely on the availability and reliability of C++ compilers, 
>> those concerns are now generally outdated; I'm not sure any of the 
>> potential problem hosts are even supported any longer.
>>     
>
> While I do not love C++, I can see no harm in this suggestion.
> Even if the full transition never happens, gdb will be no worse.
>   

This is complicated.  As Robert's pointed out, some of the costs are 
up-front.  If the full transition never happens then we'll have still 
paid that price.

This is why I think, initially, should consider running an experiment in 
parallel, it will let us see what happens without those up-front 
penelties.  Then, with concrete code, we'll be able to better access 
things and determining if there is a true advantage.  It will also let 
those interested in this figure out all the issues such as coding et.al. 
without creating unnecessary entropy here in mainline GDB.

Re: Move GDB to C++ ?

[Michael Eager]

Stan Shebs wrote:
> As many know, there is a project afoot to investigate the recoding of 
> GCC from C into C++. I believe the C++ idea was briefly touched on for 
> GDB at the summit, although I don't remember much discussion. Anyway, 
> this would be a good time to start thinking about it, and if people are 
> generally in favor of the idea, we can start small by tweaking the 
> sources to be C++-friendly, avoiding keywords and so forth; GCC has a 
> new warning flag -Wcxx-compat that can help.
> 
> For my part, I think we should do it. GDB has quite a bit of object-like 
> structure internally, and while in the past it was taking a bit of a 
> chance to rely on the availability and reliability of C++ compilers, 
> those concerns are now generally outdated; I'm not sure any of the 
> potential problem hosts are even supported any longer.

I'll offer my two cents worth.

Last year, I suggested porting portions of GDB to C++.  This had
been previously discussed, but was basically shouted down for a variety
of reasons.  I'm glad to see it being discussed again.

Some long time ago, I converted Sun Microsystem's DBX initially to
the C-compatible subset of C++, then extended it with classes and a few
other C++ features in areas where the feature matched the logic, such as
handling symbol tables or object file structures.  No templates, no
STL, retained previous exception handling; essentially, the conversion
was to "C with Classes".  This led to a significant improvement in
maintainability and reduced bug count.

Many parts of GDB (I think of gdbarch) appear to be coded to implement
objects, classes, and members, exactly if it had been generated from
C++ objects.  It seems to me that these would convert to "C with Classes"
easily, with improvement in both performance and clarity.

Despite having served on the C++ Standards Committee some time ago,
and having taught many C++ classes, I am not very fond of C++ for many
of the reasons that others have mentioned.  Templates and the template
libraries can generate error messages which range the entire spectrum
from obscure to incomprehensible.  Debugging support for several features
is spotty.  The remedy for the latter is to improve GDB support for these
features.  For the former, avoid features which are problematic.

The problems that I see in converting GDB to C++ are that it is huge
(600K+ lines) and not really modular.  The source tree is very
shallow, with architecture-dependent and -independent code mixed in
with core gdb functionality, user interface, host support and other
stuff (some of which may not be functional, like gdblib).  This makes
any wholesale conversion of GDB somewhat daunting.

Here is the approach I would take to converting GDB to C++:
   1)  Build existing GDB with C++ and correct any C/C++ incompatibilities.
   2)  Identify functional modules (e.g., cli, target support, gdbarch)
   3)  For each functional module:
      3a)  Create subdirectory for functional module
      3b)  Build library for functional module and link with GDB
      3c)  Convert from C-style to C++-style interface (if necessary)
      3d)  Document module functionality

It seems to me that this could be done incrementally with limited
impact on existing development.  I also think that this could have
many other beneficial effects on GDB, including making it easier
to understand and modify, making it less brittle, and perhaps even
working toward a fully functional gdblib.  I think that making GDB
more modular is the key -- this allows conversion to C++ to be done
in smaller bites, rather than wholesale.




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

Re: Move GDB to C++ ?

[Vladimir Prus]

Stan Shebs wrote:

> As many know, there is a project afoot to investigate the recoding of
> GCC from C into C++. I believe the C++ idea was briefly touched on for
> GDB at the summit, although I don't remember much discussion. Anyway,
> this would be a good time to start thinking about it, and if people are
> generally in favor of the idea, we can start small by tweaking the
> sources to be C++-friendly, avoiding keywords and so forth; GCC has a
> new warning flag -Wcxx-compat that can help.
> 
> For my part, I think we should do it. GDB has quite a bit of object-like
> structure internally, and while in the past it was taking a bit of a
> chance to rely on the availability and reliability of C++ compilers,
> those concerns are now generally outdated; I'm not sure any of the
> potential problem hosts are even supported any longer.


I think this discussion went a bit wrong way -- trying to convince folks that
*investing effort* in converting to C++ is justified. However, I don't think
the proposal is about making folks not interested in C++ doing any work -- the
proposal is about allowing folks who do some specific work, and want to make
use of additional features C++ provides, to use those features, while not imposing
significant problems on the rest of contributors.

Let me give an example. I believe that using C++ in varobj.c would allow to reduce
the amount of code; so should I need to add new "method" to varobj, I'd like to convert
from current emulation of classes to C++ classes. The only folks who actively touch
that file are Nick and myself. Assume Nick does not mind. Then, why not allow me to
use C++ for that module? Some possible reasons:

1. It would require having C++ compiler when building GDB. This, of course, maybe
be issue for companies who provide GDB on exotic platforms. The issue can be discussed,
or it can be discarded on the ground that this is list for FSF GDB, and FSF makes gcc
as well.
2. Not everybody knows C++, so if I'm hit by a bus, not everybody will be able to
adopt this module. (This is obviously more important for core parts than for MI).
I'm not sure if this aspect is critical -- I get the impression that even those
who object to C++ actually knows the language.
3. Misusing C++ features can make the code totally unmaintainable. However, misusing C
can have the same effect. As all patches are posted, anybody can object when such
misuse of C++ features happens. The same mechanism can be used to object to C++ features
not universally known to GDB developers.

So, it seems to me that there is a group of people that will benefit from switch to C++,
and the inconvenience for people not willing to invest any time into this project will
be minimal. Sounds like an overall gain, no?

- Volodya

Re: Move GDB to C++ ?

[Alpár Jüttner]

> 2. Not everybody knows C++, so if I'm hit by a bus, not everybody will be able to
> adopt this module. (This is obviously more important for core parts than for MI).
> I'm not sure if this aspect is critical -- I get the impression that even those
> who object to C++ actually knows the language.

Sometimes I feel the opposite. Most of the concerns appearing in this
list are a kind of phobia against C++. Some of them was true in the past
but not now, others are just a result of ignorance.

A good example for that was the debate on xfree vs. delete. One of the
goals of STL standard containers is that using them the programmer will
almost never has to use 'delete'.

There _are_ serious problems with C++, but if C++ is used properly, they
will not be a problem in case of gdb. Also, C++ could have been designed
much much better, but even this bad design provides major benefits over
C for skilled developers.

Best regards,
Alpar

GDB to C++ issue: deletion

[Paul Hilfinger]

Alpar wrote:

> A good example for that was the debate on xfree vs. delete. One of the
> goals of STL standard containers is that using them the programmer will
> almost never has to use 'delete'.

This reminded me of an issue that I'd be curious to see discussed.
The STL container classes are certainly convenient for decreasing
memory leaks with little fuss, but they do so internally with
individual frees of allocated items.  GDB currently does much of its
allocation using a region-based style (in the form of obstacks).  This
reduces leakage at some expense in safety (although I have not seen
many dangling-pointer problems triggered premature obstack releases in
GDB).  Allegedly, GDB's use of obstacks significantly speeds up
allocation and (of course) deletion.  I have certainly seen programs
in which the need to free data structures individually adds
significant cost*.  The STL container classes provide for allocators,
but I have no experience in how well they could be made to work in
duplicating GDB's current performance in this area.

I'd be interested in hearing the thoughts of the C++ lobby.

Paul Hilfinger


* In the really old days (before some contributors to this list were
  born, I suspect), I used Brian Reid's Scribe program as a text
  formatter.  It would print out a progress report in the form of a 
  sequence of page numbers, as LaTeX does now.  I noticed that after
  it reported printing the last page, there would be a VERY long pause
  before the program finally exited (the longer the document, the
  longer the pause) .  Sure enough, this was Brian's carefully 
  hand-crafted automatic storage reclamation mechanism painstakingly 
  releasing all the data structures (pointlessly, of course, since
  then as now, the OS deallocated program storage en masse on exit).

Re: GDB to C++ issue: deletion

[Daniel Jacobowitz]

On Thu, Jul 31, 2008 at 03:04:19PM -0700, Paul Hilfinger wrote:
> This reminded me of an issue that I'd be curious to see discussed.
> The STL container classes are certainly convenient for decreasing
> memory leaks with little fuss, but they do so internally with
> individual frees of allocated items.

Please let's not confuse this already sprawling discussion further
with this level of detail!

The STL is not an obvious natural successor to custom allocators.
Some things GDB uses obstacks for out of inertia, or because they were
simpler than the alternatives; others are performance critical.  The
performance critical ones might benefit from some sort of pool
allocator instead, or continue with obstacks.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB to C++ issue: deletion

[Paul Hilfinger]

> On Thu, Jul 31, 2008 at 03:04:19PM -0700, Paul Hilfinger wrote:
> > This reminded me of an issue that I'd be curious to see discussed.
> > The STL container classes are certainly convenient for decreasing
> > memory leaks with little fuss, but they do so internally with
> > individual frees of allocated items.
> 
> Please let's not confuse this already sprawling discussion further
> with this level of detail!

1. Ahem, which is precisely why I used a new subject, so as not to 
   incorporate an incidental side discussion into the same thread!

2. On the other hand, if someone is going to claim the advantages of 
   not having to do delete as an advantage, it is not entirely 
   unreasonable to make sure it really works out that way in practice.

Paul

Re: GDB to C++ issue: deletion

[Daniel Jacobowitz]

On Thu, Jul 31, 2008 at 03:40:02PM -0700, Paul Hilfinger wrote:
> > Please let's not confuse this already sprawling discussion further
> > with this level of detail!
> 
> 1. Ahem, which is precisely why I used a new subject, so as not to 
>    incorporate an incidental side discussion into the same thread!

Sorry.  You replied to the same thread; most current Unix mailers
will thread such replies together regardless of subject.  I didn't
even notice.

> 2. On the other hand, if someone is going to claim the advantages of 
>    not having to do delete as an advantage, it is not entirely 
>    unreasonable to make sure it really works out that way in practice.

IMO that applies to short lived variables, not the sort of things that
get obstacked at all.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB to C++ issue: deletion

[Ian Lance Taylor]

Paul Hilfinger <hilfingr@EECS.Berkeley.EDU> writes:

> This reminded me of an issue that I'd be curious to see discussed.
> The STL container classes are certainly convenient for decreasing
> memory leaks with little fuss, but they do so internally with
> individual frees of allocated items.  GDB currently does much of its
> allocation using a region-based style (in the form of obstacks).  This
> reduces leakage at some expense in safety (although I have not seen
> many dangling-pointer problems triggered premature obstack releases in
> GDB).  Allegedly, GDB's use of obstacks significantly speeds up
> allocation and (of course) deletion.  I have certainly seen programs
> in which the need to free data structures individually adds
> significant cost*.  The STL container classes provide for allocators,
> but I have no experience in how well they could be made to work in
> duplicating GDB's current performance in this area.

It's fairly easy to use a custom allocator for an STL object which
allocates from a memory pool.  libstdc++ has one.  The free function
simply adds the pointer to a free list.  You wouldn't want to use that
specific allocator, since it loses performance by being multi-thread
safe.  But it would be easy to simplify it.

Lots of code which uses obstacks doesn't actually free anything at
all.  It wouldn't really work to duplicate the semantics of
obstack_free in an allocator (free the specified object and all
objects allocated after it).  But it would be easy to simply ignore
calls to free--just make the allocator's deallocate function do
nothing.  In that case the memory would not go away until the
allocator itself is destroyed--or, if you prefer, the allocator could
be written to simply never release the memory at all.

Ian

Re: GDB to C++ issue: deletion

[André Pönitz]

On Friday 01 August 2008 00:04:19 Paul Hilfinger wrote:
> Alpar wrote:
> 
> > A good example for that was the debate on xfree vs. delete. One of the
> > goals of STL standard containers is that using them the programmer will
> > almost never has to use 'delete'.
> 
> This reminded me of an issue that I'd be curious to see discussed.
> The STL container classes are certainly convenient for decreasing
> memory leaks with little fuss, but they do so internally with
> individual frees of allocated items.  GDB currently does much of its
> allocation using a region-based style (in the form of obstacks).  This
> reduces leakage at some expense in safety (although I have not seen
> many dangling-pointer problems triggered premature obstack releases in
> GDB).  Allegedly, GDB's use of obstacks significantly speeds up
> allocation and (of course) deletion.  I have certainly seen programs
> in which the need to free data structures individually adds
> significant cost*.  The STL container classes provide for allocators,
> but I have no experience in how well they could be made to work in
> duplicating GDB's current performance in this area.
> 
> I'd be interested in hearing the thoughts of the C++ lobby.

0. It's the wrong question ;-) It should not be "How to I translate the 
code in lines 30 through 42 from C to C++?" but "The C code in lines
30 through 42 solves problem X. How would I solve X in C++?"
(yes, custom allocators might be a solution to certain generic
allocation performance problems, but the solution more often is
something different.)

1. The problem of finding alternatives does not exist ;-)  If someone feels
- or, better, has proof - that good old C-style code provides the best 
performance in some part of the code, and that part of the code
is on the critical path, well, than just leave that piece of code as it is.
Almost all C code is valid C++.

2. Even on this level, C++ might help to improve code readability and
maintanance by using e.g. helper classes with destructors etc. that
would translate to exactly the same machine code yet be more compact
on the source side.

3. Thirdly: Micro-optimizations. They are nice to improve the performance
of a piece of code _after_ one came to the conclusion that a certain
approach is conceptually the best and uses already the theoretically best
(or at least reasonable) data structures for the job. It's not uncommon to
gain a factor of 2 to 10 just by doing micro-optimizations, gaining half of a
percent at a time. So they are a valuable tool in the tool chest. However,
using them is a waste of resources if it's based on the wrong algorithm or
data  structures.

Now, C code typically starts with linked lists as containers and improves
a bit on that and then applies micro optimizations in the "user code"
and than gets stuck at this level as refactoring of micro-optimized
code is difficult especially when the optimizations are inlined in the user
code and the algorithms/containers are tweaked away from "standard"
implementations.

With C++ one typically starts at least with the algorithm or container 
that promises good scalability. That's easy, because "they are there".
Switching later is also comparatively easy, sometimes it's even sufficient
just to replace a single line to switch, say, from a std::list to a std::vector
or such. So C++ code is much more lilkely to use the right container
for the task, and using the wrong container typically costs a factor of "N"
not 2 or 10.

Incidentally, I think that the currently existing gdb (and other GNU core
tools) nicely demonstrate the problem from a user's perspective: It does
not scale well, and it has much worse performance than some competitors.
Of course, multi-platform abstraction has an price, but using e.g. quadratic
algorithms for an O(n) or O(n log n) task imply practical limits... see e.g. 
http://sourceware.org/ml/binutils/2004-01/msg00476.html  for an example]

André 

[1] Of course, every now and then a Guru level coder shows up, replaces
one central trouble maker with something very cool, more efficient,
even more hand-crafted, that happens to work well without being
understood by aynone else. Then the Guru leaves, and the code becomes
a "no go" area for mere mortals...

Re: GDB to C++ issue: deletion

[Eli Zaretskii]

> From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= <apoenitz@trolltech.com>
> Date: Fri, 1 Aug 2008 10:54:20 +0200
> 
> [1] Of course, every now and then a Guru level coder shows up, replaces
> one central trouble maker with something very cool, more efficient,
> even more hand-crafted, that happens to work well without being
> understood by aynone else. Then the Guru leaves, and the code becomes
> a "no go" area for mere mortals...

Which is why we should request that every such guru documents her
code, both in the sources and in gdbint.texinfo, to the level where
mere mortals can hack on it later.  Unfortunately, not all of them
comply.

Still, I think that it is a misrepresentation to say that GDB code
cannot be understood by "mere mortals".  Most problems, as far as I
remember from questions posted here, are about the high-level
architectural aspects, asked by those who want to add support for some
novel or unusual platform.  People who need to fix a bug in existing
code normally don't have much trouble understanding it.

Re: GDB to C++ issue: deletion

[Daniel Jacobowitz]

Sorry, I replied to the wrong list.

On Fri, Aug 01, 2008 at 12:53:24PM +0300, Eli Zaretskii wrote:
> Still, I think that it is a misrepresentation to say that GDB code
> cannot be understood by "mere mortals".  Most problems, as far as I
> remember from questions posted here, are about the high-level
> architectural aspects, asked by those who want to add support for some
> novel or unusual platform.  People who need to fix a bug in existing
> code normally don't have much trouble understanding it.

For what it's worth, that's not my experience at all.  Contributors
have a lot of trouble with the GDB code.  One of the biggest problems
is cleanups, which is one reason I'm listening with interest to this
conversation.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB to C++ issue: deletion

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> Sorry, I replied to the wrong list.  On Fri, Aug 01, 2008 at
 Daniel> 12:53:24PM +0300, Eli Zaretskii wrote:
 >> Still, I think that it is a misrepresentation to say that GDB code
 >> cannot be understood by "mere mortals".  Most problems, as far as
 >> I remember from questions posted here, are about the high-level
 >> architectural aspects, asked by those who want to add support for
 >> some novel or unusual platform.  People who need to fix a bug in
 >> existing code normally don't have much trouble understanding it.

 Daniel> For what it's worth, that's not my experience at all.
 Daniel> Contributors have a lot of trouble with the GDB code.  One of
 Daniel> the biggest problems is cleanups, which is one reason I'm
 Daniel> listening with interest to this conversation.

I'll second that.  I've done some small scale tweaking and bugfixing,
and I found GDB internals hard to navigate.  The internals manual is
very little help, unfortunately.

     paul

Re: GDB to C++ issue: deletion

[Eli Zaretskii]

> Date: Fri, 1 Aug 2008 10:57:16 -0400
> From: Paul Koning <Paul_Koning@dell.com>
> Cc: eliz@gnu.org,     apoenitz@trolltech.com,     gdb@sources.redhat.com
> 
> >>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:
> 
>  Daniel> Sorry, I replied to the wrong list.  On Fri, Aug 01, 2008 at
>  Daniel> 12:53:24PM +0300, Eli Zaretskii wrote:
>  >> Still, I think that it is a misrepresentation to say that GDB code
>  >> cannot be understood by "mere mortals".  Most problems, as far as
>  >> I remember from questions posted here, are about the high-level
>  >> architectural aspects, asked by those who want to add support for
>  >> some novel or unusual platform.  People who need to fix a bug in
>  >> existing code normally don't have much trouble understanding it.
> 
>  Daniel> For what it's worth, that's not my experience at all.
>  Daniel> Contributors have a lot of trouble with the GDB code.  One of
>  Daniel> the biggest problems is cleanups, which is one reason I'm
>  Daniel> listening with interest to this conversation.
> 
> I'll second that.  I've done some small scale tweaking and bugfixing,
> and I found GDB internals hard to navigate.  The internals manual is
> very little help, unfortunately.

For the record: I was talking from my impression as a reader of this
list.  It's just an impression, so it could be wrong, of course.  My
personal experience with GDB is no longer relevant to hardships of
casual contributors, so I cannot use that, because I know too much
about the internals.

Re: GDB to C++ issue: deletion

[André Pönitz]

On Friday 01 August 2008 11:53:24 Eli Zaretskii wrote:
> > From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= <apoenitz@trolltech.com>
> > Date: Fri, 1 Aug 2008 10:54:20 +0200
> > 
> > [1] Of course, every now and then a Guru level coder shows up, replaces
> > one central trouble maker with something very cool, more efficient,
> > even more hand-crafted, that happens to work well without being
> > understood by aynone else. Then the Guru leaves, and the code becomes
> > a "no go" area for mere mortals...
> 
> Which is why we should request that every such guru documents her
> code, both in the sources and in gdbint.texinfo, to the level where
> mere mortals can hack on it later.  Unfortunately, not all of them
> comply.

Part of the need to document code vanishes if the code is
straight to the point and not blurred by "maintanance operations".

Let me give an example. There is e.g (random pick):

    /* .... The new continuation will be added at
       the front.  */
    void
    add_intermediate_continuation (void (*continuation_hook)
                                   (struct continuation_arg *),
                                   struct continuation_arg *arg_list)
    {
      struct continuation *continuation_ptr;

      continuation_ptr =
        (struct continuation *) xmalloc (sizeof (struct continuation));
      continuation_ptr->continuation_hook = continuation_hook;
      continuation_ptr->arg_list = arg_list;
      continuation_ptr->next = intermediate_continuation;
      intermediate_continuation = continuation_ptr;
    }

That could in "C-with-classes" look like

    /* ... */ 
    void
    prepend_intermediate_continuation (void (*continuation_hook)
                                   (continuation_arg *),
                                   continuation_arg *arg_list)
    {
      intermediate_continuation.prepend (
         new continuation (continuation_hook, arg_list));
    }

It's clear from a glimpse here that new continuation is _prepended_
to the list. Spotting this information in the code is as easy as spotting
it in the comment of the original version,  and there's no chance that
code and comment diverge. I also saves me a few seconds to check that
the code in the original version does indeed what the comment
promises. [Of course I could trust the reviewer that they'd never
accept out-of-sync comment, but there's still a slight and _needless_
risk there...]

Also, there are around 460 non-whitespace characters to be typed,
to be review, to be read  in the original code. The replacement has 200.
Similar results for line count... And it's not using complex C++ features, 
and the produced object code will be pretty much the same.

André 

PS:

> Still, I think that it is a misrepresentation to say that GDB code
> cannot be understood by "mere mortals".  Most problems, as far as I
> remember from questions posted here, are about the high-level
> architectural aspects, asked by those who want to add support for some
> novel or unusual platform.  People who need to fix a bug in existing
> code normally don't have much trouble understanding it.

So I do not even qualify as "mere mortal" anymore  :-}

I typically fail to find the root of my gdb problems let alone to fix it.
E.g. at the beginning of the week I was trying to find out why in some
situations gdb claims to get "too few argument to function"
(infrun.c, around line 540), always with nargs == 1 and 
TYPE_NFIELDS (ftype) == 2

If this happens once then it does so consistently for anything that
has double quote characters on the commandline, say  

   p  "xxxx"

or

   call foo(0,1,2,"xxxx")

Incidentally,

   call foo(0,1,2,0) 

would _not_ complain about the wrong number. I spend quite a
while on that but I am still clueless. Unfortunately the situation
is quite complex (some gdb frontend trying to debug itself) so 
I did not try to ask for help yet. But according to your statement
I should not have much trouble to understand it ;-)

Re: GDB to C++ issue: deletion

[Daniel Jacobowitz]

On Fri, Aug 01, 2008 at 04:34:33PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 1 Aug 2008 08:51:24 -0400
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb-patches@sourceware.org
> > 
> > For what it's worth, that's not my experience at all.  Contributors
> > have a lot of trouble with the GDB code.  One of the biggest problems
> > is cleanups
> 
> What are the problems with cleanups?  Do you mean the code that uses
> them or their implementation?

I mean the code that uses them; people working in other areas of GDB
rarely have to worry about their implementation.  Some areas I've
seen problems with:

It's not clear locally (i.e. looking at any bit of code that uses
cleanups) when or how the cleanups are executed.  They're usually
triggered by an exception from some called function, and the code that
invokes the cleanups is far away.  In C, people do not expect
exceptions and so they're confused by the introduction of exception
handling.

Similarly, it's rarely clear when a cleanup is necessary and when it
isn't.  We don't have any strong conventions on what functions can
throw.  So I often have to explain to people how to write cleanups
and why they need to.

Sometimes we run cleanups and sometimes we discard them.  This is
confusing.  It's not something that would be necessarily affected by a
change in language but use of an OO language might make it easier to
represent.  I believe discard_cleanups is usually used to implement
move semantics - a change in ownership from local to global without
copying.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB to C++ issue: deletion

[Eli Zaretskii]

> Date: Fri, 1 Aug 2008 09:59:20 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org
> 
> It's not clear locally (i.e. looking at any bit of code that uses
> cleanups) when or how the cleanups are executed.  They're usually
> triggered by an exception from some called function, and the code that
> invokes the cleanups is far away.  In C, people do not expect
> exceptions and so they're confused by the introduction of exception
> handling.

Thanks.  I understand what you are saying, but no longer can imagine
why people would find this confusing.  Perhaps I'm too used to Lisp,
C++, and the C code in the Emacs Lisp engine to find exception
handling confusing.

> Sometimes we run cleanups and sometimes we discard them.  This is
> confusing.  It's not something that would be necessarily affected by a
> change in language but use of an OO language might make it easier to
> represent.

Exceptions have nothing to do with OOP.  It's just a feature that is
not part of C, so it needs to be emulated.

Re: GDB to C++ issue: deletion

[Daniel Jacobowitz]

On Fri, Aug 01, 2008 at 06:16:14PM +0300, Eli Zaretskii wrote:
> Thanks.  I understand what you are saying, but no longer can imagine
> why people would find this confusing.  Perhaps I'm too used to Lisp,
> C++, and the C code in the Emacs Lisp engine to find exception
> handling confusing.

And also used to GDB, perhaps?

From the years I've spent reviewing GDB patches, I can definitely say
that new contributors have trouble with our cleanup mechanism.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB to C++ issue: deletion

[Eli Zaretskii]

> Date: Fri, 1 Aug 2008 11:28:50 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org
> 
> On Fri, Aug 01, 2008 at 06:16:14PM +0300, Eli Zaretskii wrote:
> > Thanks.  I understand what you are saying, but no longer can imagine
> > why people would find this confusing.  Perhaps I'm too used to Lisp,
> > C++, and the C code in the Emacs Lisp engine to find exception
> > handling confusing.
> 
> And also used to GDB, perhaps?

Yes, that too.

Since RMS originally wrote both Emacs and GDB, their top-level event
loops look almost identical in structure and the way they implement
exceptions thrown by inferior code.

Problem with can_use_hw_breakpoint

[Jeremy Bennett]

I am trying to implement the target operation can_use_hw_breakpoint()
for an architecture with limited resources for hardware
breakpoint/watchpoint.

The call to can_use_hw_breakpoint() will identify the type of HW
breakpoint/watchpoint, a count of how many of that type are required,
and for watchpoints a flag (othertype) to indicate if HW watchpoints of
other types have been requested.

This function is called in response to watch, rwatch, awatch or hbreak
commands. My architecture can support up to 4 hardware watchpoints.
Consider the sequence

awatch a (watchpoint 1)
awatch b (watchpoint 2)
rwatch c (watchpoint 3)
rwatch d (watchpoint 4)
rwatch e

rwatch e should fail (5th request), but all I know from the call to
can_use_hw_breakpoint() is that 3 of this type are requested and that
some other type of watchpoint (but not how many) has previously been
requested.

It does not help to keep a private count of the calls, since I have no
notification of deletions, so I could not distinguish the sequence

awatch a (watchpoint 1)
awatch b (watchpoint 2)
rwatch c (watchpoint 3)
rwatch d (watchpoint 4)
delete 1
rwatch e (watchpoint 5)

which should succeed.

Ideally I would like can_use_hw_breakpoint to supply me with an array
with the counts of all types of HW breakpoint/watchpoint requested, so I
could determine the total resource currently required.

In the absence of this, can anyone suggest a reasonably simple solution.
The only approach I could think would be to place observers on the
watch, rwatch, awatch, hbreak and delete commands. This seems an
excessively heavyweight solution to impose.

Any suggestions welcome.

Thanks,


Jeremy

-- 
Tel:      +44 (1202) 416955
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com

Re: Problem with can_use_hw_breakpoint

[Eli Zaretskii]

> From: Jeremy Bennett <jeremy.bennett@embecosm.com>
> Date: Sat, 09 Aug 2008 13:03:06 +0100
> 
> This function is called in response to watch, rwatch, awatch or hbreak
> commands. My architecture can support up to 4 hardware watchpoints.
> Consider the sequence
> 
> awatch a (watchpoint 1)
> awatch b (watchpoint 2)
> rwatch c (watchpoint 3)
> rwatch d (watchpoint 4)
> rwatch e
> 
> rwatch e should fail (5th request), but all I know from the call to
> can_use_hw_breakpoint() is that 3 of this type are requested and that
> some other type of watchpoint (but not how many) has previously been
> requested.

You say above that your architecture supports up to 4 hardware
watchpoints.  Given that, isn't it enough to simply add 3+1 and
compare that to 4?

> Ideally I would like can_use_hw_breakpoint to supply me with an array
> with the counts of all types of HW breakpoint/watchpoint requested, so I
> could determine the total resource currently required.

What are the exact limitations of your architecture?  Do they depend
on the types of the watchpoints, and if so, how?

> In the absence of this, can anyone suggest a reasonably simple solution.

Take a look at i386-nat.c: it maintains a mirror of the hardware
watchpoints related resources, and consults them for both allowing
multiple watchpoints that watch the same addresses, and for deciding
when another watchpoint cannot be defined.

Re: Problem with can_use_hw_breakpoint

[Jeremy Bennett]

On Sat, 2008-08-09 at 15:19 +0300, Eli Zaretskii wrote:
> > From: Jeremy Bennett <jeremy.bennett@embecosm.com>
> > Date: Sat, 09 Aug 2008 13:03:06 +0100
> > 
> > This function is called in response to watch, rwatch, awatch or hbreak
> > commands. My architecture can support up to 4 hardware watchpoints.
> > Consider the sequence
> > 
> > awatch a (watchpoint 1)
> > awatch b (watchpoint 2)
> > rwatch c (watchpoint 3)
> > rwatch d (watchpoint 4)
> > rwatch e
> > 
> > rwatch e should fail (5th request), but all I know from the call to
> > can_use_hw_breakpoint() is that 3 of this type are requested and that
> > some other type of watchpoint (but not how many) has previously been
> > requested.
> 
> You say above that your architecture supports up to 4 hardware
> watchpoints.  Given that, isn't it enough to simply add 3+1 and
> compare that to 4?

Hi Eli,

Thanks for the quick response.

The problem is that I should be adding 3 (the rwatch) + 2 (the awatch)
and thus rejecting the watchpoint, but I have no way of knowing that the
count of awatch points is 2 - just that is is greater than zero.

> > Ideally I would like can_use_hw_breakpoint to supply me with an array
> > with the counts of all types of HW breakpoint/watchpoint requested, so I
> > could determine the total resource currently required.
> 
> What are the exact limitations of your architecture?  Do they depend
> on the types of the watchpoints, and if so, how?

It's the OpenRISC 1000 architecture. It implements 8 hardware
"matchpoints" which can be used for GDB HW breakpoints (needs one
matchpoint) or GDB HW watchpoints of any type (each needs a pair of
matchpoints). So I could handle 2 HW breakpoints with 1 rwatch and 2
awatch watchpoints for example.

> Take a look at i386-nat.c: it maintains a mirror of the hardware
> watchpoints related resources, and consults them for both allowing
> multiple watchpoints that watch the same addresses, and for deciding
> when another watchpoint cannot be defined.

Many thanks - this gave me some more hints.

I've realized that TARGET_CAN_USE_HARDWARE_WATCHPOINT is not guaranteed
to give a correct answer - it is just a "best guess". Section 5.1.2 of
the User Guide explains (if in doubt always read the manual :-))

        "If you set too many hardware watchpoints, GDB might be unable
        to insert all of them when you resume the execution of your
        program. Since the precise number of active watchpoints is
        unknown until such time as the program is about to be resumed,
        GDB might not be able to warn you about this when you set the
        watchpoints, and the warning will be printed only when the
        program is resumed:
        
               Hardware watchpoint num : Could not insert watchpoint
        
        If this happens, delete or disable some of the watchpoints."

This is good enough for me. I can get it right most of the time from the
data supplied and stop worrying about the corner cases (my example
above). I notice that the i386 has the simplest approximation of all -
it always returns 1 for TARGET_CAN_USE_HARDWARE_WATCHPOINT.

Best wishes,


Jeremy

-- 
Tel:      +44 (1202) 416955
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From:  Vladimir Prus <vladimir@codesourcery.com>
> Date:  Thu, 31 Jul 2008 10:10:37 +0400
> 
> I think this discussion went a bit wrong way -- trying to convince folks that
> *investing effort* in converting to C++ is justified. However, I don't think
> the proposal is about making folks not interested in C++ doing any work -- the
> proposal is about allowing folks who do some specific work, and want to make
> use of additional features C++ provides, to use those features, while not imposing
> significant problems on the rest of contributors.

Your being busy refactoring does impose a significant problem on me.
We are members of the same team, so how you use your time while on the
team is important to me.

Re: Move GDB to C++ ?

[Daniel Jacobowitz]

On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote:
> > From:  Vladimir Prus <vladimir@codesourcery.com>
> > Date:  Thu, 31 Jul 2008 10:10:37 +0400
> > 
> > I think this discussion went a bit wrong way -- trying to convince folks that
> > *investing effort* in converting to C++ is justified. However, I don't think
> > the proposal is about making folks not interested in C++ doing any work -- the
> > proposal is about allowing folks who do some specific work, and want to make
> > use of additional features C++ provides, to use those features, while not imposing
> > significant problems on the rest of contributors.
> 
> Your being busy refactoring does impose a significant problem on me.
> We are members of the same team, so how you use your time while on the
> team is important to me.

Could you please expand on this idea?

Certainly the event of refactoring will have a big impact on all
contributors.  That's at the moment of commit, and not before.  So if
you think it's actively harmful, that's a different issue from the
one Vladimir is talking about here.

GDB is a GNU project, driven by volunteers and sponsored contributors.
And the sponsored contributors are volunteers from the perspective of
anyone outside the sponsoring organization.  I don't understand the
objection to other people choosing to invest effort on something, even
if you think it's unimportant.  Volunteer projects go where their
volunteers want to take them!

And I think one of the bit structural issues in GDB is that it's hard
for even active volunteers to take it to new places.  I want to make
that easier.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Move GDB to C++ ?

[Eli Zaretskii]

> Date: Fri, 1 Aug 2008 09:13:12 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <vladimir@codesourcery.com>, gdb@sources.redhat.com
> 
> On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote:
> > > From:  Vladimir Prus <vladimir@codesourcery.com>
> > > Date:  Thu, 31 Jul 2008 10:10:37 +0400
> > > 
> > > I think this discussion went a bit wrong way -- trying to convince folks that
> > > *investing effort* in converting to C++ is justified. However, I don't think
> > > the proposal is about making folks not interested in C++ doing any work -- the
> > > proposal is about allowing folks who do some specific work, and want to make
> > > use of additional features C++ provides, to use those features, while not imposing
> > > significant problems on the rest of contributors.
> > 
> > Your being busy refactoring does impose a significant problem on me.
> > We are members of the same team, so how you use your time while on the
> > team is important to me.
> 
> Could you please expand on this idea?

The idea is that a maintainer cannot behave with the code as he
pleases, claiming that it's his time and therefore his, and only his,
business.

The idea is also that GDB is a collective effort, so arguments saying
"I will do this because I like it, and you shouldn't care" are not
something I'm willing to accept.

> GDB is a GNU project, driven by volunteers and sponsored contributors.
> And the sponsored contributors are volunteers from the perspective of
> anyone outside the sponsoring organization.  I don't understand the
> objection to other people choosing to invest effort on something, even
> if you think it's unimportant.  Volunteer projects go where their
> volunteers want to take them!

We are not talking about just any change here.  We are talking about a
change that will affect everyone.  Taking a volunteer project in such
directions without consensus isn't right, IMO.  Vladimir's message in
effect tried to side-step the lack of consensus, which is not how I
thought GDB development should advance.

> And I think one of the bit structural issues in GDB is that it's hard
> for even active volunteers to take it to new places.  I want to make
> that easier.

So do I, but what new places are we talking about?  Until now, I fail
to see even a single direction in which someone would like to go,
while the fact that GDB is written in C makes that hard.

Re: Move GDB to C++ ?

[André Pönitz]

On Friday 01 August 2008 15:46:25 Eli Zaretskii wrote:
> So do I, but what new places are we talking about?  Until now, I fail
> to see even a single direction in which someone would like to go,
> while the fact that GDB is written in C makes that hard.

I can think of a few directions that might be interesting:

  (1) a working, full featured MI interface,
  (2) integrated scripting,
  (3) performance improvements.
  (4) gdb-as-a-library.

The question whether they are hard "because it's C" is open:
You will say no, I say yes, simply because high level restructuring
is more painful in C than in reasonably C++.

André

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= <apoenitz@trolltech.com>
> Date: Fri, 1 Aug 2008 16:06:14 +0200
> 
> I can think of a few directions that might be interesting:
> 
>   (1) a working, full featured MI interface,
>   (2) integrated scripting,
>   (3) performance improvements.
>   (4) gdb-as-a-library.
> 
> The question whether they are hard "because it's C" is open:
> You will say no, I say yes, simply because high level restructuring
> is more painful in C than in reasonably C++.

Don't worry about what I'm going to say.  Just give specific arguments
why C++ will enable these directions significantly better than C.  If
you do that, you might be surprised by what I will have to say.

Re: Move GDB to C++ ?

[André Pönitz]

On Friday 01 August 2008 17:18:26 Eli Zaretskii wrote:
> > From: =?utf-8?q?Andr=C3=A9_P=C3=B6nitz?= <apoenitz@trolltech.com>
> > Date: Fri, 1 Aug 2008 16:06:14 +0200
> > 
> > I can think of a few directions that might be interesting:
> > 
> >   (1) a working, full featured MI interface,
> >   (2) integrated scripting,
> >   (3) performance improvements.
> >   (4) gdb-as-a-library.
> > 
> > The question whether they are hard "because it's C" is open:
> > You will say no, I say yes, simply because high level restructuring
> > is more painful in C than in reasonably C++.
> 
> Don't worry about what I'm going to say.  Just give specific arguments
> why C++ will enable these directions significantly better than C.  If
> you do that, you might be surprised by what I will have to say.

The reasons are the basically the same as the one I gave in other
parts of this thread. Assuming a rational approach to the type
and way C++ features are used we have:

1. Using C++ reduces source code size typically by a factor of 2 or
more _while improving readability_ as the the code that vanishes from
the sources is boiler plate code for, say, manipulating containers, or 
cleaning up within a function. The remaining "essence" is easier
to browse, faster to scan by humans and easier to refactor.

2. C++ helps to pick the right containers and algorithms at the
beginning, and makes it easier to switch later in case of errors
as different types of containers and algorithms often offer similar
interfaces - despite of different implementations and performance
characteristics. This is in stark contrast with C where container
access and manipulation is typically "manually" inlined on the
user side (up to the degree where "containers" as such do not
even exist but rather are conventions like  "start at a pointer, and
end at the next embedded end-marker", or "this item, and whatever
is linked from its 'next' pointer"). Refactoring such code, say, 
replacing the container with some other with different performance
characteristics, typically involves a complete rewrite of the user
code, and is far more error prone as "sticking to the conventions"
more often than not cannot be checked by the compiler itself.

The ability to refactor easily will certainly help with gdb performance.
Also, it helps when creating "higher level functionality", when it is
not clear on the outset how a good solution would look like. E.g.
MI currently is a mess (sorry for being blut again...). Incomplete, 
inconsistent, and misleadingly documented. Incidentally, C++ can
help to create more uniform internal interfaces as _using_ such
is much more common than the "inline-everything-manually-and-
micro-optimize-as-you-type-and-only-use-functions-when-really-
needed"-style approach of C.


n. On top of that: C++ does not hurt. C code can stay (sometimes
with minor adjustments) if needed and none of the advantages
cited above are wanted. Also, C++ _is_ widely available, and also
g++ 2.95.3 would fit the bill for what I think gdb needs.

I just notice I wrote something like that already, so maybe I'd better
stop. As far as I can tell, all arguments have been on the table for
a few times now. The strongest argument against that I saw was
Mark's fear that using C++ for future gdb releases might hamper
his ability to use a seven year old compiler for non-GNU-base 
operating systems, and that fear is very likely to be unfounded.
Of course I can't tell for sure since he did not point to any specific 
problem. I doubt there is any for our (my?) envisioned usage pattern.
The fear of "inevitable smart pointer invasion" is certainly not 
realisitic...

Regards,
André

PS: I am also somewhat tired of this discussion now. I suppose I'll 
try again in a few years...

Re: Move GDB to C++ ?

[Daniel Jacobowitz]

On Fri, Aug 01, 2008 at 04:46:25PM +0300, Eli Zaretskii wrote:
> The idea is that a maintainer cannot behave with the code as he
> pleases, claiming that it's his time and therefore his, and only his,
> business.

So this is an objection to the refactoring, not to how Vladimir spends
his time working on GDB.  That's fine; I was just reacting to my
interpretation of your statement.  Thanks!

Please note that this is also what Vladimir was trying to say.
Objecting to the results of refactoring is different from objecting to
him working on the refactoring.

I've seen several kind of objections:

- The effort of conversion would not be worthwhile.  I believe that
these objections are, in this circumstance, not significant; the
people who believe the effort of refactoring is not worthwhile are
certainly not obliged to help.

- The conversion is a bad idea because of inherent problems of C++.
I haven't seen much to convince me of this.

- The conversion is a bad idea because of the dependency on C++.  This
is an interesting issue and I plan to discuss it, but not in this
message.

One objection I have not seen:

- The result of the refactoring would be harder to solve problems in.
This, especially with concrete examples, would be a compelling
objection.

> The idea is also that GDB is a collective effort, so arguments saying
> "I will do this because I like it, and you shouldn't care" are not
> something I'm willing to accept.

To see one reason why tempers are flaring in this conversation, please
compare that paragraph to this one:

GDB is a collective effort, so arguments saying "you will not do this
because I don't like it" are not something I'm willing to accept.

> > And I think one of the bit structural issues in GDB is that it's hard
> > for even active volunteers to take it to new places.  I want to make
> > that easier.
> 
> So do I, but what new places are we talking about?  Until now, I fail
> to see even a single direction in which someone would like to go,
> while the fact that GDB is written in C makes that hard.

A number of examples have been presented in this thread.  I find them
convincing; you don't.  I'm not sure what I can add to that.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Move GDB to C++ ?

[Eli Zaretskii]

> Date: Fri, 1 Aug 2008 10:20:48 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: vladimir@codesourcery.com, gdb@sources.redhat.com
> 
> On Fri, Aug 01, 2008 at 04:46:25PM +0300, Eli Zaretskii wrote:
> > The idea is that a maintainer cannot behave with the code as he
> > pleases, claiming that it's his time and therefore his, and only his,
> > business.
> 
> So this is an objection to the refactoring, not to how Vladimir spends
> his time working on GDB.

There were no references to refactoring in the paragraph you cited.
FWIW, it was a general concern, not something I concocted to justify
my more specific objections.

Re: Move GDB to C++ ?

[Vladimir Prus]

Eli Zaretskii wrote:

>> Date: Fri, 1 Aug 2008 09:13:12 -0400
>> From: Daniel Jacobowitz <drow@false.org>
>> Cc: Vladimir Prus <vladimir@codesourcery.com>, gdb@sources.redhat.com
>> 
>> On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote:
>> > > From:  Vladimir Prus <vladimir@codesourcery.com>
>> > > Date:  Thu, 31 Jul 2008 10:10:37 +0400
>> > > 
>> > > I think this discussion went a bit wrong way -- trying to convince folks that
>> > > *investing effort* in converting to C++ is justified. However, I don't think
>> > > the proposal is about making folks not interested in C++ doing any work -- the
>> > > proposal is about allowing folks who do some specific work, and want to make
>> > > use of additional features C++ provides, to use those features, while not imposing
>> > > significant problems on the rest of contributors.
>> > 
>> > Your being busy refactoring does impose a significant problem on me.
>> > We are members of the same team, so how you use your time while on the
>> > team is important to me.
>> 
>> Could you please expand on this idea?
> 
> The idea is that a maintainer cannot behave with the code as he
> pleases, claiming that it's his time and therefore his, and only his,
> business.
> 
> The idea is also that GDB is a collective effort, so arguments saying
> "I will do this because I like it, and you shouldn't care" are not
> something I'm willing to accept.

I don't think anybody ever said the phrase you've quoted. You, as a global
maintainer can care about any patch posted to gdb-patches as you see fit.
But I think that objections to any decision in any patch should focus on
specific technical issues, or lack thereof, in the end result. 

For example, every time I do any nontrivial work, I look at existing code,
and try to see if it can be made more hackable. As result, I might
post a patch that takes a 400-line function and extracts a couple of 
fragments into separate functions. You might respond asking why I think
those are the right fragments to extract, whether the names of new functions
makes sense, and so on. But on the other hand saying "don't waste your
time on refactoring, just hack you change in" would seem wrong -- if it's
me doing the work, then I know the most efficient way for me, so as long
as each individual patch makes thing better and the end goal is achieved,
things are OK.

Why should not all technical decisions viewed this way? If I post a patch
that makes use of a C++ feature, then it's reasonable to object if this
feature makes the code more obscure or less maintainable, or increases
GDB footprint. But if none of those issues are present, why prevent me from
using the feature? Or why demand that I prove that use of this feature makes
*me* more productive and whether just hacking the immediate change in would
be faster?

The *only* global decision here, is whether to use C++ compiler when building
GDB and I think that decision should be used on purely practical concerns.
Say, if 100 people believe use of C++ features will make them more productive,
100 people who would not use C++ features anyway, and it turns out that there's
exactly one platform that will not be able to compile GDB if it switches to C++,
and that platform is EOLed in 1980, then I think the decision is clear. And
it that case, the first 100 people need to convince the other 100 people that
they should use C++ features -- they are happy not to.

 >> GDB is a GNU project, driven by volunteers and sponsored contributors.
>> And the sponsored contributors are volunteers from the perspective of
>> anyone outside the sponsoring organization.  I don't understand the
>> objection to other people choosing to invest effort on something, even
>> if you think it's unimportant.  Volunteer projects go where their
>> volunteers want to take them!
> 
> We are not talking about just any change here.  We are talking about a
> change that will affect everyone.  Taking a volunteer project in such
> directions without consensus isn't right, IMO.  Vladimir's message in
> effect tried to side-step the lack of consensus, which is not how I
> thought GDB development should advance.

It's not exactly true; I there are various consensuses that are possible.
It seems to me like we were trying to reach concensus on the following
statement:

    "Everybody should stop doing anything, quit their jobs, go to desert,
    and hack on converting GDB to C++ without rest"

Naturally, this is not a defensible statement, and I think the statement to
discuss is:

    "There's quite a number of people who say they will be more productive
     using C++ and C++ will bring little inconvenience to the rest, so
     allowing using C++ is a net gain"

The folks who say they are more productive with C++ are not teenagers, or even
students, so I think it reasonable to trust their opinion about their own
productivity. Do you agree? Then, the above statement can be false only
if the inconvenience is as bit as to make the result a net loss. So far,
only Mark has provided concrete concerns -- namely that requiring C++ might
make some targets unviable.

Do you know of specific inconveniences that will affect you, personally?

- Volodya

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From:  Vladimir Prus <vladimir@codesourcery.com>
> Date:  Fri, 01 Aug 2008 20:13:36 +0400
> 
> Eli Zaretskii wrote:
> 
> > The idea is that a maintainer cannot behave with the code as he
> > pleases, claiming that it's his time and therefore his, and only his,
> > business.
> > 
> > The idea is also that GDB is a collective effort, so arguments saying
> > "I will do this because I like it, and you shouldn't care" are not
> > something I'm willing to accept.
> 
> I don't think anybody ever said the phrase you've quoted.

Well, that's how I interpreted what you wrote in the message to which
I responded.  If I misunderstood, I apologize; in that case, please do
tell what _did_ you want to say in this passage:

> I think this discussion went a bit wrong way -- trying to convince folks that
> *investing effort* in converting to C++ is justified. However, I don't think
> the proposal is about making folks not interested in C++ doing any work -- the
> proposal is about allowing folks who do some specific work, and want to make
> use of additional features C++ provides, to use those features, while not imposing
> significant problems on the rest of contributors.
> 
> Let me give an example. I believe that using C++ in varobj.c would allow to reduce
> the amount of code; so should I need to add new "method" to varobj, I'd like to convert
> from current emulation of classes to C++ classes. The only folks who actively touch
> that file are Nick and myself. Assume Nick does not mind. Then, why not allow me to
> use C++ for that module?

??

> But I think that objections to any decision in any patch should focus on
> specific technical issues, or lack thereof, in the end result. 

I agree.  But then the above text doesn't present any technical
arguments, either.  It just says (or so I understand it): if one
maintainer does something he considers right in the parts of GDB
unvisited by others, why not let him do so?  This is not a technical
issue.

> For example, every time I do any nontrivial work, I look at existing code,
> and try to see if it can be made more hackable. As result, I might
> post a patch that takes a 400-line function and extracts a couple of 
> fragments into separate functions. You might respond asking why I think
> those are the right fragments to extract, whether the names of new functions
> makes sense, and so on. But on the other hand saying "don't waste your
> time on refactoring, just hack you change in" would seem wrong -- if it's
> me doing the work, then I know the most efficient way for me, so as long
> as each individual patch makes thing better and the end goal is achieved,
> things are OK.

In GDB, we do trust each other, but we also have a peer review
procedures.  During this review, it is quite possible that I (or
someone else) would come up and say that what seems like a cool idea
to you looks not so cool to me.  This isn't mistrust, this is how GDB
development works for quite some time.  And since you know all that
very well, I don't understand why you protest against these very
practices on the premise that "if it's me doing the work, then I know
the most efficient way for me".

> Why should not all technical decisions viewed this way? If I post a patch
> that makes use of a C++ feature, then it's reasonable to object if this
> feature makes the code more obscure or less maintainable, or increases
> GDB footprint. But if none of those issues are present, why prevent me from
> using the feature? Or why demand that I prove that use of this feature makes
> *me* more productive and whether just hacking the immediate change in would
> be faster?

Because a decision to switch to another language is much heavier than
a decision about a feature of a language that we already use.

> The *only* global decision here, is whether to use C++ compiler when building
> GDB and I think that decision should be used on purely practical concerns.
> Say, if 100 people believe use of C++ features will make them more productive,
> 100 people who would not use C++ features anyway, and it turns out that there's
> exactly one platform that will not be able to compile GDB if it switches to C++,
> and that platform is EOLed in 1980, then I think the decision is clear.

Decisions based on beliefs are not at all clear, in my experience.
Beliefs are certainly not _practical_ concerns in my book.  I did ask
for practical arguments (not beliefs), and will be happy to weigh them
if they will be ever brought up.

> The folks who say they are more productive with C++ are not teenagers, or even
> students, so I think it reasonable to trust their opinion about their own
> productivity. Do you agree?

Yes, I agree.  But that is not the issue.  We cannot convert GDB to
C++ in parts, or at least that's not what is being suggested.  The
suggestion on the table is to convert everything to C++.  So whether
this or that maintainer is personally more productive in C++ is only a
small part of the arguments for or against the change, because the
decision will force _all_ maintainers to work in C++, even those who
believe they are less productive in it than in C.

> Then, the above statement can be false only if the inconvenience is
> as bit as to make the result a net loss. So far, only Mark has
> provided concrete concerns -- namely that requiring C++ might make
> some targets unviable.

Mark was the only one who said why from his POV the switch is
unacceptable.  I'm saying something else: a decision like that, if it
needs to be a good decision, should find good arguments _for_ the
change, not only lack of arguments _against_ it.  In other words, to
me, "why not?" is not a good argument for significant changes such as
this one.

> Do you know of specific inconveniences that will affect you, personally?

I don't see how my personal inconvenience is relevant here.  If
personal inconvenience is supposed to be the main reason for rejecting
changes, I could never object to any change in the GDB manual, for
example, because having a less-than-good manual does not personally
inconvenience me in any way.

But I have proposition for you (and everybody else who thinks it is
clear GDB should move to C++): since you evidently have more than
enough free time both to maintain your parts of GDB and work on
refactoring, how about if you start a branch in the CVS, refactor GDB
to C++ there, and show the result?  Then we will have two versions of
GDB to compare and I believe most of the dispute will die of natural
causes because the advantages of one of the versions over the other
will be clear to all.  Of course, this proposition only stands if the
GDB maintenance and routine development don't suffer any significant
setbacks due to the additional work on the C++ branch.

Re: Move GDB to C++ ?

[Vladimir Prus]

On Friday 01 August 2008 23:19:51 Eli Zaretskii wrote:
> > From:  Vladimir Prus <vladimir@codesourcery.com>
> > Date:  Fri, 01 Aug 2008 20:13:36 +0400
> > 
> > Eli Zaretskii wrote:
> > 
> > > The idea is that a maintainer cannot behave with the code as he
> > > pleases, claiming that it's his time and therefore his, and only his,
> > > business.
> > > 
> > > The idea is also that GDB is a collective effort, so arguments saying
> > > "I will do this because I like it, and you shouldn't care" are not
> > > something I'm willing to accept.
> > 
> > I don't think anybody ever said the phrase you've quoted.
> 
> Well, that's how I interpreted what you wrote in the message to which
> I responded.  If I misunderstood, I apologize; in that case, please do
> tell what _did_ you want to say in this passage:
> 
> > I think this discussion went a bit wrong way -- trying to convince folks that
> > *investing effort* in converting to C++ is justified. However, I don't think
> > the proposal is about making folks not interested in C++ doing any work -- the
> > proposal is about allowing folks who do some specific work, and want to make
> > use of additional features C++ provides, to use those features, while not imposing
> > significant problems on the rest of contributors.
> > 
> > Let me give an example. I believe that using C++ in varobj.c would allow to reduce
> > the amount of code; so should I need to add new "method" to varobj, I'd like to convert
> > from current emulation of classes to C++ classes. The only folks who actively touch
> > that file are Nick and myself. Assume Nick does not mind. Then, why not allow me to
> > use C++ for that module?

The statement you've quoted is not complete, and is followed by quite some text, ending 
with the the following:

   So, it seems to me that there is a group of people that will benefit from switch to C++,
   and the inconvenience for people not willing to invest any time into this project will
   be minimal. Sounds like an overall gain, no?

> > For example, every time I do any nontrivial work, I look at existing code,
> > and try to see if it can be made more hackable. As result, I might
> > post a patch that takes a 400-line function and extracts a couple of 
> > fragments into separate functions. You might respond asking why I think
> > those are the right fragments to extract, whether the names of new functions
> > makes sense, and so on. But on the other hand saying "don't waste your
> > time on refactoring, just hack you change in" would seem wrong -- if it's
> > me doing the work, then I know the most efficient way for me, so as long
> > as each individual patch makes thing better and the end goal is achieved,
> > things are OK.
> 
> In GDB, we do trust each other, but we also have a peer review
> procedures.  During this review, it is quite possible that I (or
> someone else) would come up and say that what seems like a cool idea
> to you looks not so cool to me.  This isn't mistrust, this is how GDB
> development works for quite some time.  And since you know all that
> very well, I don't understand why you protest against these very
> practices on the premise that "if it's me doing the work, then I know
> the most efficient way for me".

Those practices never resulting in anybody questioning me if I use my
time most efficiently. I was never asked to prove that refactoring code,
in general, results in easier forthcoming changes in that code area. Then,
I'm surprised that you want me to prove that converting some specific
bits to C++ is the most efficient use of my time, or whether that, in general,
enables to do forthcoming changes faster. If any patch making use
of C++ has specific issues, review should focus on those specific issues.
 
> > Why should not all technical decisions viewed this way? If I post a patch
> > that makes use of a C++ feature, then it's reasonable to object if this
> > feature makes the code more obscure or less maintainable, or increases
> > GDB footprint. But if none of those issues are present, why prevent me from
> > using the feature? Or why demand that I prove that use of this feature makes
> > *me* more productive and whether just hacking the immediate change in would
> > be faster?
> 
> Because a decision to switch to another language is much heavier than
> a decision about a feature of a language that we already use.

Why? Presumably, because of specific practical issues? Further, those issues
do not exist in vacuum -- those are issues for GDB developers and contributors.
Then, to make any decision, we need to know the issues that specific persons have.
Do you agree that if no GDB developer or use can name any issue with C++ 
that will cause him problem, or make him less productive, then it's OK to switch?

> > The *only* global decision here, is whether to use C++ compiler when building
> > GDB and I think that decision should be used on purely practical concerns.
> > Say, if 100 people believe use of C++ features will make them more productive,
> > 100 people who would not use C++ features anyway, and it turns out that there's
> > exactly one platform that will not be able to compile GDB if it switches to C++,
> > and that platform is EOLed in 1980, then I think the decision is clear.
> 
> Decisions based on beliefs are not at all clear, in my experience.
> Beliefs are certainly not _practical_ concerns in my book.  I did ask
> for practical arguments (not beliefs), and will be happy to weigh them
> if they will be ever brought up.
> 
> > The folks who say they are more productive with C++ are not teenagers, or even
> > students, so I think it reasonable to trust their opinion about their own
> > productivity. Do you agree?
> 
> Yes, I agree.  

Ok, good. Then, we've established that at least some folks will be more productive if
we switch to C++. This is what we have on one side of the scale.

> But that is not the issue.  We cannot convert GDB to 
> C++ in parts, or at least that's not what is being suggested.  The
> suggestion on the table is to convert everything to C++.  

No, I don't think wholesale conversion to C++ is proposed.

> So whether 
> this or that maintainer is personally more productive in C++ is only a
> small part of the arguments for or against the change, because the
> decision will force _all_ maintainers to work in C++, even those who
> believe they are less productive in it than in C.

Yes, this is one of concerns I've mentioned in my original email, and it's
on the other side of the scale. Naturally, it's not possible to prove that 
every current and future maintainer will be as productive in C++ as in C. 
But fortunately, the set of current maintainers and contributors is finite,
and each can speak for himself. Do you agree that if no maintainer will say
he's less productive in C++ than in C, then we can trust them, and no 
productivity loss will result? 
 
> > Then, the above statement can be false only if the inconvenience is
> > as bit as to make the result a net loss. So far, only Mark has
> > provided concrete concerns -- namely that requiring C++ might make
> > some targets unviable.
> 
> Mark was the only one who said why from his POV the switch is
> unacceptable.  I'm saying something else: a decision like that, if it
> needs to be a good decision, should find good arguments _for_ the
> change, not only lack of arguments _against_ it.  In other words, to
> me, "why not?" is not a good argument for significant changes such as
> this one.

As we've already established, quite a number of people will be more productive
in C++, which I think is sufficient "pro" to start more detailed process of
collecting pros and cons. You, on the other side, want some stronger "pro"
before even trying to list cons. Why?

> > Do you know of specific inconveniences that will affect you, personally?
> 
> I don't see how my personal inconvenience is relevant here.  If
> personal inconvenience is supposed to be the main reason for rejecting
> changes, I could never object to any change in the GDB manual, for
> example, because having a less-than-good manual does not personally
> inconvenience me in any way.

"Inconvenience" was a wrong word. What are negative consequences of the switch
that will affect you as a GDB maintainer in your day-to-day coding?
 
> But I have proposition for you (and everybody else who thinks it is
> clear GDB should move to C++): since you evidently have more than
> enough free time both to maintain your parts of GDB and work on
> refactoring, 

Was this passage meant to sound sarcastic? This thread arises from the
premise that we don't have enough free time to fight with language limitations.

> how about if you start a branch in the CVS, refactor GDB 
> to C++ there, and show the result?  Then we will have two versions of
> GDB to compare and I believe most of the dispute will die of natural
> causes because the advantages of one of the versions over the other
> will be clear to all.  Of course, this proposition only stands if the
> GDB maintenance and routine development don't suffer any significant
> setbacks due to the additional work on the C++ branch.

You are right that having the concrete code would help. But, did not I already
suggested to prepare a patch showing use of C++ for some specific area? Or
you suggest to convert every single file to C++ idioms before any kind of further
discussion? Naturally, there's certain number of changed lines after which merges
between two codebases will become too hard, so we'll have a fork as result. I don't
think anybody in this thread wants that to happen, so maybe a local patch for
some part of GDB, or several patches, is a better way to evaluate effects of C++?

- Volodya

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Sat, 2 Aug 2008 09:54:57 +0400
> Cc: gdb@sources.redhat.com
> 
> The statement you've quoted is not complete, and is followed by quite some text, ending 
> with the the following:
> 
>    So, it seems to me that there is a group of people that will benefit from switch to C++,
>    and the inconvenience for people not willing to invest any time into this project will
>    be minimal. Sounds like an overall gain, no?

This just reiterates what you said in the part I cited.  I still don't
see how I should have interpreted your text differently.  You are
saying that a benefit to a single maintainer in the area where others
either don't mind or don't work is a reason good enough to change the
development paradigm in that area.  I disagree.

> Those practices never resulting in anybody questioning me if I use my
> time most efficiently. I was never asked to prove that refactoring code,
> in general, results in easier forthcoming changes in that code area. Then,
> I'm surprised that you want me to prove that converting some specific
> bits to C++ is the most efficient use of my time

"our time", not "my time".

> > Because a decision to switch to another language is much heavier than
> > a decision about a feature of a language that we already use.
> 
> Why? Presumably, because of specific practical issues?

I already explained those practical issues, in so many words, in this
thread.  I have nothing to add to what I said.

> Do you agree that if no GDB developer or use can name any issue with C++ 
> that will cause him problem, or make him less productive, then it's OK to switch?

No, I don't agree.  A good decision has nothing to do with problems
caused to the developers individually.

> No, I don't think wholesale conversion to C++ is proposed.

How can a program such as GDB be converted to C++ in parts?  Can you
show a practical plan of doing that?  Apart of making C code
compatible with a C++ compiler, the rest should be done at once, or
else we will have a terrible mess of C++ and C that is actually worse
of what we have today.  And what about new contributions--won't they
also be requested to be written in C++?

> Do you agree that if no maintainer will say he's less productive in
> C++ than in C, then we can trust them, and no productivity loss will
> result?

No.

> > Mark was the only one who said why from his POV the switch is
> > unacceptable.  I'm saying something else: a decision like that, if it
> > needs to be a good decision, should find good arguments _for_ the
> > change, not only lack of arguments _against_ it.  In other words, to
> > me, "why not?" is not a good argument for significant changes such as
> > this one.
> 
> As we've already established, quite a number of people will be more productive
> in C++, which I think is sufficient "pro" to start more detailed process of
> collecting pros and cons. You, on the other side, want some stronger "pro"
> before even trying to list cons. Why?

Again, I already explained why elsewhere: Each change of development
environment has a non-trivial overhead.  To justify that overhead, a
set of specific development goals should be stated, and then an
analysis should be made whether the way to reach those specific goals
will be easier by first changing the environment, and by how much
easier.

Just improved productivity is not a reason that is good enough,
because productivity is not a goal in itself, it's a means.  For
example, if no important developments are expected for years to come,
just maintenance, then productivity is not important.

> What are negative consequences of the switch that will affect you as
> a GDB maintainer in your day-to-day coding?

None whatsoever.  But my _personal_ problems with this switch have
nothing to do with a sane method of making decisions like this one.

> > But I have proposition for you (and everybody else who thinks it is
> > clear GDB should move to C++): since you evidently have more than
> > enough free time both to maintain your parts of GDB and work on
> > refactoring, 
> 
> Was this passage meant to sound sarcastic?

No, not at all.

> This thread arises from the
> premise that we don't have enough free time to fight with language limitations.

Then how can we afford to spend effort in converting code to C++?

> You are right that having the concrete code would help. But, did not I already
> suggested to prepare a patch showing use of C++ for some specific area? Or
> you suggest to convert every single file to C++ idioms before any kind of further
> discussion? Naturally, there's certain number of changed lines after which merges
> between two codebases will become too hard, so we'll have a fork as result. I don't
> think anybody in this thread wants that to happen, so maybe a local patch for
> some part of GDB, or several patches, is a better way to evaluate effects of C++?

I've been suggesting this since the beginning: let's have specific
examples of non-trivial parts of GDB that will show how C++ is better
than C, both for maintenance of existing code and for future
development.

Re: Move GDB to C++ ?

[Vladimir Prus]

Eli Zaretskii wrote:

>> Do you agree that if no GDB developer or use can name any issue with C++
>> that will cause him problem, or make him less productive, then it's OK to switch?
> 
> No, I don't agree.  A good decision has nothing to do with problems
> caused to the developers individually.

Why? I assume that if C++ switch comes with *no problems* at all, it would
not be an issue worth discussing at all. And if it causes some potential
problems, then those problems are for either developers or users. I fail to
see how a problem that does not affect nobody is a "problem".

>> No, I don't think wholesale conversion to C++ is proposed.
> 
> How can a program such as GDB be converted to C++ in parts?  Can you
> show a practical plan of doing that?  Apart of making C code
> compatible with a C++ compiler, the rest should be done at once, or
> else we will have a terrible mess of C++ and C that is actually worse
> of what we have today.  

No, we already have a terrible mess of using either macros, or function
pointers, or wrapper functions to emulate classes. At no point during
gradual transition of those mechanisms the code will be worse than it is now.

> And what about new contributions--won't they 
> also be requested to be written in C++?

Presumably, for the cases where code in question is converted to C++, and adding
new code requires using C++ features -- yes. For example, if struct value becomes
a class with virtual methods, then naturally one would have to use C++ features
when adding a new method. For other cases, I don't even see how we can request
folks to use C++ -- "you shalt use at least one C++ feature in each patch"? That's
neither possible nor desirable.

>> Do you agree that if no maintainer will say he's less productive in
>> C++ than in C, then we can trust them, and no productivity loss will
>> result?
> 
> No.

Do you think that either:
- some developers are not capable of estimating if they personally will
be less productive in C++
- there's some other productivity metric other then sum of individual
productivity for each developer?

>> > Mark was the only one who said why from his POV the switch is
>> > unacceptable.  I'm saying something else: a decision like that, if it
>> > needs to be a good decision, should find good arguments _for_ the
>> > change, not only lack of arguments _against_ it.  In other words, to
>> > me, "why not?" is not a good argument for significant changes such as
>> > this one.
>> 
>> As we've already established, quite a number of people will be more productive
>> in C++, which I think is sufficient "pro" to start more detailed process of
>> collecting pros and cons. You, on the other side, want some stronger "pro"
>> before even trying to list cons. Why?
> 
> Again, I already explained why elsewhere: Each change of development
> environment has a non-trivial overhead.  To justify that overhead, a
> set of specific development goals should be stated, and then an
> analysis should be made whether the way to reach those specific goals
> will be easier by first changing the environment, and by how much
> easier.
> 
> Just improved productivity is not a reason that is good enough,
> because productivity is not a goal in itself, it's a means.  For
> example, if no important developments are expected for years to come,
> just maintenance, then productivity is not important.

The approach for reaching a decision that you outline above sounds good,
but it has a problem. There's a big spectrum of approaches. On one side,
one can say that C++ is better that C for all purposes, and claim this
is valid. On the other hand, one can port GDB to C++, and then have
10 equally skilled programmers implement, individually, multi-process
support. 5 would do that in C version, 5 would do that in C++ version,
and then you'd compare code size, number of bugs, and time spent. Neither
of those extreme approaches seems reasonable to *me* -- but any person
has different opinion of what is reasonable enough. I might find that
the need to implement multi-process support is concrete goal, and that
necessary refactorings of target stack is enough motivation for C++,
and somebody else would argue that a complete implementation in C is
first needed. There's no universal agreement, so we'll be back to square
one -- with everybody having his personal opinion on whether the presented
arguments are good enough.

In in commercial setting, if you are the boss, you get to decide which
level of up-front design or prototyping is sufficient. In GDB, there's
no single boss, so we get back to opinions of individuals. If we can't get
an agreement on whether C++ is desired, do you think we can get an agreement
on what decision making process to use?

So my conclusion we're back to individual opinions to the matter. Each person
can be either for the change now, or against the change, or ask for additional
information, which brings me to...

>> You are right that having the concrete code would help. But, did not I already
>> suggested to prepare a patch showing use of C++ for some specific area? Or
>> you suggest to convert every single file to C++ idioms before any kind of further
>> discussion? Naturally, there's certain number of changed lines after which merges
>> between two codebases will become too hard, so we'll have a fork as result. I don't
>> think anybody in this thread wants that to happen, so maybe a local patch for
>> some part of GDB, or several patches, is a better way to evaluate effects of C++?
> 
> I've been suggesting this since the beginning: let's have specific
> examples of non-trivial parts of GDB that will show how C++ is better
> than C, both for maintenance of existing code and for future
> development.

...your personal opinion. Am I right that now you are undecided? 
What part of GDB do you want to be converted, as example, and what are your criteria for deciding if
C++ version is better than the C one?

- Volodya

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From:  Vladimir Prus <vladimir@codesourcery.com>
> Date:  Sat, 02 Aug 2008 13:22:07 +0400

I'm sorry, I cannot continue this discussion any further.  I was asked
for my opinion, and I gave it.  I then was dragged into a prolonged
discussion to justify my opinion on how such decisions should be made.
I feel I said already everything I had to say on this matter, and
anyone who wants to understand what I say has just to read my
messages.

Please also note that at no point I said I was against the switch.  My
point was that I don't see the goal, and without a goal I cannot judge
whether the switch is justified.

Vladimir says, in essence, that the goal is to give some maintainers a
development environment in which they think they will be more
productive.  In my experience, developers usually have very skewed
estimates of their productivity (this includes myself, when I develop
code), so basing long-range decisions on such estimates is a recipe
for bad decisions.

Re: Move GDB to C++ ?

[Vladimir Prus]

Eli Zaretskii wrote:

>> From:  Vladimir Prus <vladimir@codesourcery.com>
>> Date:  Sat, 02 Aug 2008 13:22:07 +0400
> 
> I'm sorry, I cannot continue this discussion any further.  I was asked
> for my opinion, and I gave it.  I then was dragged into a prolonged
> discussion to justify my opinion on how such decisions should be made.
> I feel I said already everything I had to say on this matter, and
> anyone who wants to understand what I say has just to read my
> messages.
> 
> Please also note that at no point I said I was against the switch.  My
> point was that I don't see the goal, and without a goal I cannot judge
> whether the switch is justified.

The only question here is how to count your opinion? -0, +0, -1 or +1 or
pure abstain?

- Volodya

Re: Move GDB to C++ ?

[Eli Zaretskii]

> From:  Vladimir Prus <vladimir@codesourcery.com>
> Date:  Sat, 02 Aug 2008 14:00:13 +0400
> 
> The only question here is how to count your opinion? -0, +0, -1 or +1 or
> pure abstain?

Why is there a need to count? are we voting yet?

Re: Move GDB to C++ ?

[Mark Kettenis]

> X-Spam-Check-By: sourceware.org
> Date: Fri, 1 Aug 2008 09:13:12 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote:
> > > From:  Vladimir Prus <vladimir@codesourcery.com>
> > > Date:  Thu, 31 Jul 2008 10:10:37 +0400
> > > 
> > > I think this discussion went a bit wrong way -- trying to convince folks that
> > > *investing effort* in converting to C++ is justified. However, I don't think
> > > the proposal is about making folks not interested in C++ doing any work -- the
> > > proposal is about allowing folks who do some specific work, and want to make
> > > use of additional features C++ provides, to use those features, while not imposing
> > > significant problems on the rest of contributors.
> > 
> > Your being busy refactoring does impose a significant problem on me.
> > We are members of the same team, so how you use your time while on the
> > team is important to me.
> 
> Could you please expand on this idea?
> 
> Certainly the event of refactoring will have a big impact on all
> contributors.  That's at the moment of commit, and not before.  So if
> you think it's actively harmful, that's a different issue from the
> one Vladimir is talking about here.
> 
> GDB is a GNU project, driven by volunteers and sponsored contributors.
> And the sponsored contributors are volunteers from the perspective of
> anyone outside the sponsoring organization.  I don't understand the
> objection to other people choosing to invest effort on something, even
> if you think it's unimportant.  Volunteer projects go where their
> volunteers want to take them!
> 
> And I think one of the bit structural issues in GDB is that it's hard
> for even active volunteers to take it to new places.  I want to make
> that easier.

[ This is not directed at Daniel in particular, his message was just
  happened to be a convenient one to reply to. ]

Guys, can we please stop this!  These discussions are now taking up
almost all the time I have to hack on GDB.  I feel obliged to take
part in them because I see them as a threat for the platforms I care
about, and the way GDB is shipped on those platform.  But I really
hate it.

More concretely.  On OpenBSD we build GDB as a native debugger on all
our platforms.  Some of these platforms still use GCC 2.95.3, because
later versions are slower, have a bigger memory footprint and have
more bugs, at least as far as the C compiler is concerned.  Others use
GCC 3.3.5 for much the same reason.  This is unlikely to change soon,
especially if GCC is going to be rewritten in C++.  Rewriting GDB in
C++ is bad news for those platforms because GCC 2.95.3 is not a very
good C++ compiler and ships with an outdated STL library.  I don't
think exception handling works reliably on all these platforms.
Things will get even slower and will probably require more memory than
some of my machines have.

I don't think it is acceptable to effectively drop support for a
platform for which there is a fairly active developer.

I'm not going to waste more of my time on this discussion.  But please
don't interpret my silence as an agreement.
 
Mark

Re: Move GDB to C++ ?

[André Pönitz]

On Friday 01 August 2008 15:52:01 Mark Kettenis wrote:
> More concretely.  On OpenBSD we build GDB as a native debugger on all
> our platforms.  Some of these platforms still use GCC 2.95.3, because
> later versions are slower, have a bigger memory footprint and have
> more bugs, at least as far as the C compiler is concerned.  Others use
> GCC 3.3.5 for much the same reason.  This is unlikely to change soon,
> especially if GCC is going to be rewritten in C++.  Rewriting GDB in
> C++ is bad news for those platforms because GCC 2.95.3 is not a very
> good C++ compiler and ships with an outdated STL library.

gcc 2.95.3 is a pretty good compiler for a reasonably usable subset
of C++. The accompanying Standard Library fits the same bill. 

I've used both until about a year ago for some old project that was 
not easily portable for other reasons.

There is absolutely no need to believe that moving a few but important
baby steps towards C++ would kill gdb on OpenBSD.

André

Re: Move GDB to C++ ?

[Stan Shebs]

Mark Kettenis wrote:
> Guys, can we please stop this!  These discussions are now taking up
> almost all the time I have to hack on GDB.  I feel obliged to take
> part in them because I see them as a threat for the platforms I care
> about, and the way GDB is shipped on those platform.  But I really
> hate it.
>   
I agree, seems pretty much beat to death at this point. I originally 
brought it up because I wanted to get a sense of where everybody was at 
these days. People's attitudes toward programming languages do change, 
but not because of mailing list discussion.
> More concretely.  On OpenBSD we build GDB as a native debugger on all
> our platforms.  Some of these platforms still use GCC 2.95.3, because
> later versions are slower, have a bigger memory footprint and have
> more bugs, at least as far as the C compiler is concerned.  Others use
> GCC 3.3.5 for much the same reason.  This is unlikely to change soon,
> especially if GCC is going to be rewritten in C++.  Rewriting GDB in
> C++ is bad news for those platforms because GCC 2.95.3 is not a very
> good C++ compiler and ships with an outdated STL library.  I don't
> think exception handling works reliably on all these platforms.
> Things will get even slower and will probably require more memory than
> some of my machines have.
>   
This sounds like a good litmus test actually. Either ensure that GDB 
continues to run, and reasonably well, on OpenBSD, or drop OpenBSD as a 
supported native.
> I don't think it is acceptable to effectively drop support for a
> platform for which there is a fairly active developer.
>   
Perhaps you'll get some company, if C++ fans set up OpenBSD systems so 
as to see what language features they can expect to work. :-)

Stan

Re: Move GDB to C++ ?

[Vladimir Prus]

Mark Kettenis wrote:

>> X-Spam-Check-By: sourceware.org
>> Date: Fri, 1 Aug 2008 09:13:12 -0400
>> From: Daniel Jacobowitz <drow@false.org>
>> 
>> On Thu, Jul 31, 2008 at 09:42:28PM +0300, Eli Zaretskii wrote:
>> > > From:  Vladimir Prus <vladimir@codesourcery.com>
>> > > Date:  Thu, 31 Jul 2008 10:10:37 +0400
>> > > 
>> > > I think this discussion went a bit wrong way -- trying to convince folks that
>> > > *investing effort* in converting to C++ is justified. However, I don't think
>> > > the proposal is about making folks not interested in C++ doing any work -- the
>> > > proposal is about allowing folks who do some specific work, and want to make
>> > > use of additional features C++ provides, to use those features, while not imposing
>> > > significant problems on the rest of contributors.
>> > 
>> > Your being busy refactoring does impose a significant problem on me.
>> > We are members of the same team, so how you use your time while on the
>> > team is important to me.
>> 
>> Could you please expand on this idea?
>> 
>> Certainly the event of refactoring will have a big impact on all
>> contributors.  That's at the moment of commit, and not before.  So if
>> you think it's actively harmful, that's a different issue from the
>> one Vladimir is talking about here.
>> 
>> GDB is a GNU project, driven by volunteers and sponsored contributors.
>> And the sponsored contributors are volunteers from the perspective of
>> anyone outside the sponsoring organization.  I don't understand the
>> objection to other people choosing to invest effort on something, even
>> if you think it's unimportant.  Volunteer projects go where their
>> volunteers want to take them!
>> 
>> And I think one of the bit structural issues in GDB is that it's hard
>> for even active volunteers to take it to new places.  I want to make
>> that easier.
> 
> [ This is not directed at Daniel in particular, his message was just
>   happened to be a convenient one to reply to. ]
> 
> Guys, can we please stop this!  These discussions are now taking up
> almost all the time I have to hack on GDB.  I feel obliged to take
> part in them because I see them as a threat for the platforms I care
> about, and the way GDB is shipped on those platform.  But I really
> hate it.
> 
> More concretely.  On OpenBSD we build GDB as a native debugger on all
> our platforms.  Some of these platforms still use GCC 2.95.3, because
> later versions are slower, have a bigger memory footprint and have
> more bugs, at least as far as the C compiler is concerned.  Others use
> GCC 3.3.5 for much the same reason.  This is unlikely to change soon,
> especially if GCC is going to be rewritten in C++.  Rewriting GDB in
> C++ is bad news for those platforms because GCC 2.95.3 is not a very
> good C++ compiler and ships with an outdated STL library.  I don't
> think exception handling works reliably on all these platforms.

I believe that for GDB purposes, 2.95.3 is just fine. In fact, 2.95 is
exactly the release where gcc's C++ support became OK.

> Things will get even slower and will probably require more memory than
> some of my machines have.

Do you have exact value, or estimate, or how much the performance and memory
consumption will suffer?

- Volodya

Re: Move GDB to C++ ?

[Daniel Jacobowitz]

On Fri, Aug 01, 2008 at 07:05:14PM +0400, Vladimir Prus wrote:
> > More concretely.  On OpenBSD we build GDB as a native debugger on all
> > our platforms.  Some of these platforms still use GCC 2.95.3, because
> > later versions are slower, have a bigger memory footprint and have
> > more bugs, at least as far as the C compiler is concerned.  Others use
> > GCC 3.3.5 for much the same reason.  This is unlikely to change soon,
> > especially if GCC is going to be rewritten in C++.  Rewriting GDB in
> > C++ is bad news for those platforms because GCC 2.95.3 is not a very
> > good C++ compiler and ships with an outdated STL library.  I don't
> > think exception handling works reliably on all these platforms.
> 
> I believe that for GDB purposes, 2.95.3 is just fine. In fact, 2.95 is
> exactly the release where gcc's C++ support became OK.

The part of this that concerns me is "I don't think exception handling
works reliably on all these platforms."

I'm not sure what we can say about that.  We didn't dig this hole, but
it exists none the less.  It really bothers me to be stuck writing GNU
software in 2008 that can't rely on GNU compilers released in the last
six years.

We can set up auto-testing on OpenBSD x86 without much difficulty.
But that's not where the problems are going to occur.  It'll be the
less-mainstream platforms like vax and hppa.

-- 
Daniel Jacobowitz
CodeSourcery

Re: GDB to C++ issue: deletion

[Paul Hilfinger]

> > 1. Ahem, which is precisely why I used a new subject, so as not to 
> >    incorporate an incidental side discussion into the same thread!
> 
> Sorry.  You replied to the same thread; most current Unix mailers
> will thread such replies together regardless of subject.  I didn't
> even notice.

How "helpful" of them.  Sorry; I didn't edit my header stringently
enough.  My bad.

> > 2. On the other hand, if someone is going to claim the advantages of 
> >    not having to do delete as an advantage, it is not entirely 
> >    unreasonable to make sure it really works out that way in practice.
> 
> IMO that applies to short lived variables, not the sort of things that
> get obstacked at all.

Actually, I had already concluded that short-lived variables would NOT
be a great problem.  To a first approximation, the effect of using STL's
storage management is to increase allocation costs by some constant
factor, because deallocation cost for an object tends to be limited by
some constant times its allocation cost.  As long as GDB's allocation
costs are not huge (and the constant factors are not huge), we
shouldn't have much pain.  

But that's just an overall argument about total execution time.
Common sources of short-lived variables (say during parsing and
(sub)expression evaluation) don't produce that many variables between
prompts (usually).  What I was more interested in was the possibility
of noticeably large changes in pause times for expensive operations
(such as re-reading a symbol table) on large executables.  I can think
of approaches, certainly, but have no actual experience with how well
they integrate with STL classes in practice.

Paul