Will therefore GDB utilize C++ or not?

Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

Hi,

there is now new patch:
	Re: [PATCH] Allow 64-bit enum values
	http://sourceware.org/ml/gdb-patches/2012-03/msg00932.html
which is a pre-requisite for GDB inferior type fields safety similar to what
I already checked in as:
	[commit] [patch 2/2] typedef-checking for CU relative vs. absolute offsets
	http://sourceware.org/ml/gdb-patches/2012-03/msg00721.html

But compared to the [commit] patch of only 282 '+' lines limited to dwarf*
files only above the type fields safety patch will be huge and thorough the
whole GDB codebase (TYPE_LENGTH: 1103 lines, FIELD_BITPOS: 22 lines, sure the
patch will be larger)..


->
This whole effort is wrong if GDB was in C++ which allows to use:
	http://en.wikipedia.org/wiki/Object_type_%28object-oriented_programming%29#Boxing

so that one can directly use type->length as long as it is safe, an example of
C++ solution is given below.

It no longer needs to patch every use of TYPE_LENGTH into some TYPE_LENGTH_VAL
or to append '.cu_off' to every use of the "integer" like I did in the
[commit] patch above.


There are sure many other cases I still wait to solve using C++.  There was
some plan to have GDB exceptions and cleanups converted to C++ exceptions and
RAII
	http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization
automatic allocation/deallocation which would automatically solve many other
bugs being fixed by hand here and there.  I have filed also
	crashes from stale frame_info *
	http://sourceware.org/bugzilla/show_bug.cgi?id=13866
which would be easily sanity-protected by mandatory referencing frame_info *
by C++ smart-pointer and during reinit_frame_cache just assert there are no
live instances of frame_info references out there etc. etc.


For switching GDB compilation to C++ there is needed to resolve some name
clashes first
	http://sourceware.org/gdb/wiki/ArcherBranchManagement
	Enabling gdb to compile with the -Wc++-compat flag to gcc.
	archer-ratmice-compile-Wc++-compat
but there is enough workforce to do this mechanical type of work as long as
there is an agreement to switch to C++.

To C++ or not to C++?  Unfortunately the discussion was here already before
and I am aware several contributors are not welcome with it, I think it does
not need to affect readability of C code much, there is not enough workforce
to rewrite all the GDB code into C++ style anyway.  Still C++ would help
a lot, some kinds of bugs are not solvable without it.

I am open to suggestions of static analysis tools to use instead but at least
according to the experience of Tom Tromey it is not so easy / safe / foolproof
to use, IIUC his words.


Thanks,
Jan


#include <stdint.h>
class Length
{
  int64_t _x;
public:
  Length(int64_t x) { _x = x; }
  operator int64_t() { return _x; }
private:
  operator int() { return _x; }
};
void ok (int64_t l) {}
void bad (int l) {}
void bad2 (long long l) {}
int
main()
{
  Length l(10);
// great, no errors
  ok (l);
// error: ‘Length::operator int()’ is private
// error: within this context
// note: candidates are:
// note: Length::operator int()
// note: Length::operator int64_t()
// error:   initializing argument 1 of ‘void bad2(long long int)’
  bad (l);
// error: conversion from ‘Length’ to ‘long long int’ is ambiguous
  bad2 (l);
}

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> To C++ or not to C++?  Unfortunately the discussion was here
Jan> already before and I am aware several contributors are not welcome
Jan> with it, I think it does not need to affect readability of C code
Jan> much, there is not enough workforce to rewrite all the GDB code
Jan> into C++ style anyway.  Still C++ would help a lot, some kinds of
Jan> bugs are not solvable without it.

I'm strongly in favor of C++ for reasons I'll lay out below.

I agree with all your points.

But first:

Jan> I am open to suggestions of static analysis tools to use instead
Jan> but at least according to the experience of Tom Tromey it is not so
Jan> easy / safe / foolproof to use, IIUC his words.

Yes, when David Malcolm wrote his Python plugin for GCC, I decided to
see whether we could get the equivalent maintainability benefits of C++
by writing in C and then using static analysis to fill the gaps.

To this end I wrote a few small plugins to do analysis on gdb.

My conclusion is that it is just too much work to iron out all the false
reports from the plugins.  Partly this is due to gdb's unusual
structure, in particular the use of cleanups, which mean that any
analysis requires a lot of hair to ensure its correctness.


Last June (so long ago already?) I sent a draft of a proposal to migrate
gdb to C++ to the Archer list (the thread is
http://sourceware.org/ml/archer/2011-q2/threads.html#00028; the
followups are worth reading, but I've incorporated most of it into the
below).  After some discussion and edits, I chickened out of sending it.
Here it is now:


At the GCC Summit, I once again brought up the perennial idea of
moving GDB to be implemented in C++.  There, we agreed that as a
follow-on to that discussion that I would raise the topic among the
GDB maintainers, and in particular present my migration plan.

My goal for moving to C++ is to make GDB more robust.

My view is that GDB is already written in a poor cousin of C++.
Nearly every feature that people hate about C++ is already in use in
GDB.  This list is not exhaustive, just informational:

* Subclasses.  See general_symbol_info.  struct value and struct type
  would be improved by them.

* Virtual functions.  gdbarch, languages, and values all use these.

* Overloaded functions.  Anywhere you see a _1 suffix.

* Templates.  Both observers and VEC are templates.

* Exceptions.  Used ubiquitously.

* RAII.  Cleanups, but they are dynamic and more error-prone.

* Even global constructors -- init.c.

In most cases, GDB's implementation of these features is inferior to
that of the C++ compiler.  Its exceptions are slower.  Its data
structures have less type-safety.  Both cleanups and TRY_CATCH are
error-prone in practice.  GDB is needlessly verbose due to using
callback-based container iteration and callback-based exception
handling.  We have run into various situations where errors could have
been prevented through the use of better type-safety -- e.g., wrapper
classes for the CU- versus section-offset case.

I think a gradual move to C++ would enable us to fix these problems.
I believe it would also provide us a way to fix the ongoing reference
counting bugs in the Python layer.


I don't believe we should convert all of GDB to C++.  In particular I
think gdbserver should remain as pure C, and likewise any code shared
between gdbserver and gdb should be kept as such.


I also think we should be reasonably conservative in our choices of
C++ constructs to use.  I think this should be a separate thread; I
will be happy to write a draft proposal for this as well.  We can also
see what the GCC community comes up with here -- our needs are a
little different, but probably not drastically so.


My concrete transition proposal is:

1. Modify GDB so it can be compiled with -Wc++-compat.
   This would be the first patch series.  There is already an archer
   branch for this.

2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is
   not complete).  This would be the second patch series.

3. Require C++.

4. Change selected modules to use C++ rather than C.
   I don't think a wholesale change makes sense, but some areas would
   benefit.

   My first target would be to change the exception handling system to
   use C++ exceptions.  This would enable us to begin using RAII in
   some areas, which would help robustness.

   My concrete plan here is:

   * Use the GCC cleanup-checking plugin I already wrote to detect
     cleanup-aware functions.

   * Modify these functions, using a script, to add an RAII-using
     object to manage the local cleanups.  This is important so that
     we run cleanups at the correct time during stack unwinding.

   * Change throw_exception to use 'throw' and all TRY_EXCEPT
     instances to try...catch.

   * Finally, convert functions to static RAII usage when appropriate;
     this will be an ongoing transition.

   I think our second target will be sorting out Python reference
   counting, so we can avoid the many problems we have had there.


Tom

Re: Will therefore GDB utilize C++ or not?

[Mark Kettenis]

> From: Tom Tromey <tromey@redhat.com>
> Date: Wed, 04 Apr 2012 14:47:39 -0600
> 
> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> 
> Jan> To C++ or not to C++?  Unfortunately the discussion was here
> Jan> already before and I am aware several contributors are not welcome
> Jan> with it, I think it does not need to affect readability of C code
> Jan> much, there is not enough workforce to rewrite all the GDB code
> Jan> into C++ style anyway.  Still C++ would help a lot, some kinds of
> Jan> bugs are not solvable without it.
> 
> I'm strongly in favor of C++ for reasons I'll lay out below.

And my position on this has not changed: I'm strongly against.  C++ is
horrible language that should never have been invented.

Re: Will therefore GDB utilize C++ or not?

[Sergio Durigan Junior]

On Wednesday, April 04 2012, Mark Kettenis wrote:

>> From: Tom Tromey <tromey@redhat.com>
>> Date: Wed, 04 Apr 2012 14:47:39 -0600
>> 
>> >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
>> 
>> Jan> To C++ or not to C++?  Unfortunately the discussion was here
>> Jan> already before and I am aware several contributors are not welcome
>> Jan> with it, I think it does not need to affect readability of C code
>> Jan> much, there is not enough workforce to rewrite all the GDB code
>> Jan> into C++ style anyway.  Still C++ would help a lot, some kinds of
>> Jan> bugs are not solvable without it.
>> 
>> I'm strongly in favor of C++ for reasons I'll lay out below.
>
> And my position on this has not changed: I'm strongly against.  C++ is
> horrible language that should never have been invented.

I believe I understand your "rationale", but I would like to know if the
approval (by the majority) and eventual use of C++ in GDB (mentioning,
again, that GDB will not be rewritten in C++) would make you stop
contributing to the project.

I am not a maintainer, and I understand that C++ is not the best
language out there, but I've seen (more than once) other people saying
that "if the project ABC adopts XYZ, then I'm out".  I don't think this
is the most reasonable thing to do, and I'm pretty sure this kind of
behaviour slows down some kinds of progresses (such as this C++ thing),
mostly because nobody wants to miss talented (and needed!) people
contributing to the project, I think.  That's why I'm asking you this
question (but really, I would be asking to anyone objecting with
arguments like "the language is horrible").

Thanks,

-- 
Sergio

Re: Will therefore GDB utilize C++ or not?

[Phil Muldoon]

On 04/04/2012 10:55 PM, Mark Kettenis wrote:
>> From: Tom Tromey <tromey@redhat.com>
>> Date: Wed, 04 Apr 2012 14:47:39 -0600
>>
>>>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
>>
>> Jan> To C++ or not to C++? Unfortunately the discussion was here
>> Jan> already before and I am aware several contributors are not welcome
>> Jan> with it, I think it does not need to affect readability of C code
>> Jan> much, there is not enough workforce to rewrite all the GDB code
>> Jan> into C++ style anyway. Still C++ would help a lot, some kinds of
>> Jan> bugs are not solvable without it.
>>
>> I'm strongly in favor of C++ for reasons I'll lay out below.
>
> And my position on this has not changed: I'm strongly against. C++ is
> horrible language that should never have been invented.

Beyond the obvious question of "why is it a horrible language", I'd
like to ask you to consider another approach.

Is it because of some horribly obfuscated C++ code out there you may
have witnessed? You know the type, takes take the OOP concept and
batters it to atoms?  Useless implementation of esoteric template
designs, not because it is needed, but because it was cool?

There is a lot of C++ code that I do not like, but there is also a lot
of C code that sucks too.  I've written some.  We all have, at some point. 
There is some in GDB.

My belief is that you can write clear, concise, efficient code in
any language; similarly, you can write complete rubbish in any
language too.  C++ debates seem to be a fertile garden for this kind
of discussion, but, eventually, I recognized I was criticizing the
implementer/implementation of the project, not the language itself.

So focusing on the language, and not any previous implementations one
might have witnessed, what is acceptable? My approach to the
discussion is C++ is OK, as in a "C with objects" approach.  That may
be too far for you, and not far enough for others.  But it is a point
to defend and/or compromise on.

Personally, I don't think GDB is going to go crazy with variadic
templates, or other concepts I am not totally keen on.  And, I think,
maintainers need a balance of skeptics and champions, to balance this
out. Every line of code that goes into GDB is subject to review --
even by global maintainers themselves.  That's why this discussion is
not opening the flood-gates, but creaking them open a little.  Say
this discussion results in C++ being acceptable.  Every patch still
has to be posted, reviewed and (if not a maintainer) approved.  There
are safeties at every turn.

So, please, if you can write a concise argument, I for one would like
to read it.  Balance is good, but arguments that we cannot challenge,
or defend just lead us to a dead-end.

Cheers,

Phil

Re: Will therefore GDB utilize C++? Not.

[John Gilmore]

I introduced many of the "tables of C pointers" into GDB.  I could've
opted to switch to C++ at that point.  I did not and am happy that I
did not.  The paradigms we introduced were simple, maintainable,
useful, and documented.  I see nothing wrong with writing in C and
occassionally using a table of pointers (like the dispatch tables in
BFD, or the target selectors) where appropriate.  Just because you
sometimes call through a pointer, or arrange values in data
structures, doesn't mean you need to "move to an object oriented
language".  People who can't do object-oriented programming in a
procedural language perhaps don't understand object-oriented
programming, which is not about syntax, nor about enforcement, but
about deliberately choosing a narrower subset of mechanisms to produce
programs that are easier to maintain.

One of our original reasons for sticking with C is less relevant
today.  GDB is one of the first programs you want to bring up on a new
system, since it can help you debug itself and every other program.
To be useful for that, it needed to be compilable with a very broad
spectrum of relatively simple compilers.  Being written in C++ would
have foiled that.  Nowadays we merely cross-compile and cross-debug,
or emulate the target system from some well-supported host system.
Avoiding the need for a tricky, complicated, and working compiler to
compile GDB is less of a constraint.

I have not yet found an easy-to-maintain large production C++ program;
not in 1991 and not in the intervening 20 years.  I've written a
medium sized C++ program (smqueue).  Based on that experience, I was
never tempted to write a large program in C++.  I have found many C++
programs that are hard to maintain.  Hard to understand, hard to
compile, hard to debug.  As an example, I am currently wrestling with
a commercial success, a production program running at thousands of
sites, that took 12 years of a team of half a dozen programmers to
write and maintain in C++.  It now no longer even compiles, because
the recently graduated programmers who wrote it embedded questionable
C++ constructs deep into its infrastructure, and failed to document
the structures they were building.  I could and will rewrite the
broken parts, but it's very painful to even understand what they were
TRYING to do, because it's undocumented and wrapped up in layer after
layer after layer of templates and inclusion and C++ junk.  They
aren't making objects that have accessors and such; they're using a
"pattern language" that abuses C++ objects to do cheap runtime
type-checking -- or something!  It took hours to just narrow the
program down to a one-page program that would reproduce the compiler
error while being something a human could grasp.  Of course every C++
programmer denies that they are designing or writing a monster like
that.  However, a surprising number end up that way.  It is much
harder to screw up a C program beyond human recognition.  There's not
even a contest for Obfuscated C++, since it's trivial to do without
even intending to!  C++ fails at simplicity and predictability.

The 1990's idea that C++ was the obvious successor to C has clearly
been proven false over the last 25 years.  C is still here and going
strongly.  C++ was an experiment that disproved its thesis -- a
valuable contribution, certainly, but not an example to follow.  Even
the thesis that objected oriented programming is superior to
traditional procedural programming has been disproved (in my mind), or
is at least unresolved at this date.  I would say that over the last
20-40 years the key new insights in programming have been in
portability, simplicity, and pan-global collaboration of focused teams
(version control, automating distributed discussions and bug reports,
distribution, packaging, etc).  The mainstream of system and
application development continues in directions other than C++, such
as C, Java, and Python, not to mention big corners like PHP, C# and
Objective-C.

If you ended up writing parts of GDB in C++ and other parts in C,
anyone who did maintenance on it would have to understand both.  But
C++ is full of ugly traps for the unwary, and things seldom mean what
they appear to a C programmer to mean.  You'd narrow your potential
pool of talented contributors.  And you'd be basing your core debugger
on one of the least well supported parts of C++ -- its
interoperability with traditional C code.

I do not recommend that GDB use C++.

	John

Re: Will therefore GDB utilize C++? Not.

[Russell Shaw]

On 06/04/12 10:34, John Gilmore wrote:

...

> I do not recommend that GDB use C++.

I agree 100% on all points. I came to the same conclusions 10 years ago. 
Everything i do now is C, and i only poke with C++ to grab something out of it 
or to reverse engineer.

Most C++ programmers i've seen have this mentality that they don't need to know 
what's "under the hood" such as what some library is doing or how inefficient it is.

As a result, you get layers upon layers upon layers of absolute crud piled sky high.

OTOH, i don't recommend trying to emulate C++ in plain C, or you end up with a 
maintenance disaster like GTK.

All it requires is a few more short lines of explanatory design notes scattered 
through the code and clarity of thought.

Re: Will therefore GDB utilize C++? Not.

[Joel Brobecker]

> >I do not recommend that GDB use C++.
> 
> I agree 100% on all points. I came to the same conclusions 10 years
> ago. Everything i do now is C, and i only poke with C++ to grab
> something out of it or to reverse engineer.

I wish we would stop discussing about the language itself, and argue
the technical points that the pro-C++ camp were bringing up. There are
a number of issues with GDB's design there were raised, and solutions
involving the use of C++ were proposed. As far as I know, the anti-C++
camp has rejected C++ in general based on general and vague arguments,
rather than argue the specific points that have been brought up. We are
NOT talking about using ALL of C++, we are talking about using
a reasonable subset that would allow us to expand a bit what the language
can do for us.

If the non-discussion continues, we're going to have to make a decision
on how to decide on this issue, and I am afraid that the only fair
way would be for the Global Maintainers to vote. To my knowledge,
we have never resorted to such an extreme approach, but I don't see
a real discussion happening here.

> Most C++ programmers i've seen have this mentality that they don't
> need to know what's "under the hood" such as what some library is
> doing or how inefficient it is.

Please, we're talking about the GDB Maintainers and the few contributors
who actually participate in GDB's development. This argument means
nothing because the only side-effect is that such programers would
be limited in how much they can contribute. But on the other hand,
if we follow your reasoning, they would not be able to contribute
anyway, since using C makes the language too low-level for them.

I will just go out and say it, but I think about half of the active
maintainer, if not more, are in favor of using some features of C++.
And I can tell you right here and now that they are no dummies.

> OTOH, i don't recommend trying to emulate C++ in plain C, or you end
> up with a maintenance disaster like GTK.

And yet, that's exactly what we are doing:
  - unit elaboration;
  - gdbarch/language dispatching
  - exception handling
  - use of unions to emulate polymorphism;
  - etc, etc, etc.

And frankly, you criticize GTK's design, but it was exactly the design
I was thinking about of emulating if we wanted a more OO approach
without using C++. To my knowledge, KDE is doing very well, and is
written in C++.

So again, the proposal that was put on the table a long time ago
was that some specific features of C++ be used in order to simplify
certain areas of GDB's code. The pro-C++ camps has, in my opinion,
successfully shown how C++ was going to help. The specific arguments,
in my opinion, should be brought up again, and those specific arguments
should be discussed, rather than just discussing generalities about
how horrible C++ is.

> All it requires is a few more short lines of explanatory design
> notes scattered through the code and clarity of thought.

This is almost offensive. If it was that easy, how about you start
sending some patches?

-- 
Joel

Re: Will therefore GDB utilize C++? Not.

[Russell Shaw]

On 06/04/12 23:16, Joel Brobecker wrote:
>>> I do not recommend that GDB use C++.
>>

...

>> All it requires is a few more short lines of explanatory design
>> notes scattered through the code and clarity of thought.
>
> This is almost offensive. If it was that easy, how about you start
> sending some patches?

I made up a heap of gdb patches over several months for a microcontroller a few 
years ago, and used those patches for real work. There was still a bit of 
buggyness i couldn't fix.

I did not submit them because i could not verify them in a robust way due to the 
gdb internals documentation i found very lacking, but my (lack of) knowledge of 
unix process handling was a contributor too.

I definitely would not have put in the effort if it meant dealing with C++.

I'm not doing any gdb work until i understand how the debugging format works.
There is not much documentation on that.

The coding is easy. Lack of documentation is the hard part. Using C++ isn't 
magically going to make the internals of gdb easier to maintain.

Re: Will therefore GDB utilize C++? Not.

[Michael Eager]

On 04/06/2012 06:16 AM, Joel Brobecker wrote:
>>> I do not recommend that GDB use C++.
>>
>> I agree 100% on all points. I came to the same conclusions 10 years
>> ago. Everything i do now is C, and i only poke with C++ to grab
>> something out of it or to reverse engineer.
>
> I wish we would stop discussing about the language itself, and argue
> the technical points that the pro-C++ camp were bringing up. There are
> a number of issues with GDB's design there were raised, and solutions
> involving the use of C++ were proposed. As far as I know, the anti-C++
> camp has rejected C++ in general based on general and vague arguments,
> rather than argue the specific points that have been brought up. We are
> NOT talking about using ALL of C++, we are talking about using
> a reasonable subset that would allow us to expand a bit what the language
> can do for us.

I'll echo Joel -- complaints about C++ language design don't add much to
the discussion.

I've long been an advocate of C With Classes.  I'm less in favor of
using other features in C++, perhaps not so much from the technical concerns,
which I do have, but because gcc provides horrible C++ error messages and gdb
provides horrible C++ debugging.  It's been suggested that if gcc/gdb converted
to C++ that both would improve as the developers ate their own dog food.

> And yet, that's exactly what we are doing:
>    - unit elaboration;
>    - gdbarch/language dispatching
>    - exception handling
>    - use of unions to emulate polymorphism;
>    - etc, etc, etc.

Writing several different versions of object-oriented C to implement
these features doesn't make gdb easier to debug or extend.

> So again, the proposal that was put on the table a long time ago
> was that some specific features of C++ be used in order to simplify
> certain areas of GDB's code. The pro-C++ camps has, in my opinion,
> successfully shown how C++ was going to help. The specific arguments,
> in my opinion, should be brought up again, and those specific arguments
> should be discussed, rather than just discussing generalities about
> how horrible C++ is.
>
>> All it requires is a few more short lines of explanatory design
>> notes scattered through the code and clarity of thought.

In many places, gdb comments and descriptions range from meaningless to
useless.  The internals document is far out of date.  In many areas, it
is difficult to understand why the code does the odd things it does.
I'm not sure where "clarity of thought" would be applied.

Working in gdb is not easy.  It doesn't seem to be getting better.
There are many changes which, IMO, would reverse this trend.  One would
be to rewrite the parts which are currently written in object oriented
code with incomplete encapsulation with clear C++ classes and member
functions.  Several parts of gdb are overly complex and would benefit
from refactoring and redesign.  As parts are converted to C++, perhaps
this would give the opportunity for a long overdue review of the design.

There's been an argument that poorly written C++ code is the only
possible outcome of converting gdb to C++.  I don't think that this is
the inevitable result.  Developers can write good C or good C++, as
well as poor C or poor C++.  Especially with gdb maintainers' concerns
for the quality of C++ code, I would expect that converting gdb to C++
would favor (if not demand) producing good C++ rather than just checking
in anything submitted.

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

Re: Will therefore GDB utilize C++? Not.

[John Gilmore]

> And yet, that's exactly what we are doing:
>   - unit elaboration;
>   - gdbarch/language dispatching
>   - exception handling
>   - use of unions to emulate polymorphism;

Writing modular programs is a good idea even if we don't do it in C++.
I have heard it claimed that many techniques of modular programming
were even invented before C++ existed - though that may be doubted.

If people have the energy to rewrite large chunks of GDB, why argue
about it?  Go off and do it.  It's free software -- you don't even
have to start from scratch like GNU did.  The world can always use a
new debugger.  You can make a politically correct debugger (pcdb?)
with an identical interface but a C++ implementation under the hood.
If it's better than GDB in the long run, maintainers will migrate to
it, GDB will fall into disrepair, and GNU will adopt it.

It's always easier to see how a completely paper design is cleaner
than a piece of running code whose warts are in front of you.  And it
means you can respond to critics by saying, "See - you can't find any
problems in our nonexistent code, you are just making generalized
statements about the implementation language, which we should all
ignore as irrelevant."  By the time you actually get the new design
working, it too will have compromises, bugs, and won't match its
documentation.  Then again, if you had put that prodigious energy into
updating the original piece of running code, perhaps it would have
fewer bugs, fewer compromises, and updated documentation.

	John

PS: Which particular unions in gdb are you complaining about ("used to
emulate polymorphism")?  I grepped the sources, and see a bunch used
in BFD, in SIM, and in GDB's expression parser.  It seems to me that
they are all used to unify storage and access to disparate types of
elements in a list or array -- not to make or fake polymorphism.  This
is what unions were designed for.  Did I miss some corner where unions
are cowering under the lash of abuse?

PPS: What is "unit elaboration" and what does that have to do with
GDB?  All I can find from a quick web search is that it has something
to do with Ada.  Perhaps other languages don't do it -- or have 
another name for it.  "Linking"?  Are you sure we shouldn't rewrite
bits of GDB in Ada instead of C++?

Re: Will therefore GDB utilize C++? Not.

[Robert Dewar]

On 4/6/2012 7:32 PM, John Gilmore wrote:
>> And yet, that's exactly what we are doing:
>>    - unit elaboration;
>>    - gdbarch/language dispatching
>>    - exception handling
>>    - use of unions to emulate polymorphism;
>
> Writing modular programs is a good idea even if we don't do it in C++.
> I have heard it claimed that many techniques of modular programming
> were even invented before C++ existed - though that may be doubted.

Doubted by whom? Certainly not by anyone with any awareness of the
history of programming languages. The notions of modular programming
existed LONG LONG before C++ was invented and are represented in
many programming languages! Next someone will be thinking that C++
invented object oriented programming :-)

> PPS: What is "unit elaboration" and what does that have to do with
> GDB?  All I can find from a quick web search is that it has something
> to do with Ada.  Perhaps other languages don't do it -- or have
> another name for it.  "Linking"?  Are you sure we shouldn't rewrite
> bits of GDB in Ada instead of C++?

:-)

Re: Will therefore GDB utilize C++? Not.

[Thomas Dineen]

Gentle People:

Re: History of programming languages:

    Who is the mother of modular programming?

    Do you believe that modular programming began with invention
of the computer subroutine?

    If Yes then here is a tidbit from a class on patents that I took years
ago:

    Who first patented the computer subroutine?

    Answer: Mary Wollstonecraft Bancroft in Brittan in or around 1865!!!
Working on mechanical calculating machines!

    Mary's aunt is considered the mother of science fiction! Why?

    Mary's great aunt is considered the mother of the women's rights
movement! Why?

    Mary's great uncle is considered the father of the anarchy movement?
Why?

    An interesting family!

Happy Easter, and in respect for the holidays be kind to each other!
Thomas Dineen




On 4/6/2012 6:03 PM, Robert Dewar wrote:
> On 4/6/2012 7:32 PM, John Gilmore wrote:
>>> And yet, that's exactly what we are doing:
>>>    - unit elaboration;
>>>    - gdbarch/language dispatching
>>>    - exception handling
>>>    - use of unions to emulate polymorphism;
>>
>> Writing modular programs is a good idea even if we don't do it in C++.
>> I have heard it claimed that many techniques of modular programming
>> were even invented before C++ existed - though that may be doubted.
>
> Doubted by whom? Certainly not by anyone with any awareness of the
> history of programming languages. The notions of modular programming
> existed LONG LONG before C++ was invented and are represented in
> many programming languages! Next someone will be thinking that C++
> invented object oriented programming :-)
>
>> PPS: What is "unit elaboration" and what does that have to do with
>> GDB?  All I can find from a quick web search is that it has something
>> to do with Ada.  Perhaps other languages don't do it -- or have
>> another name for it.  "Linking"?  Are you sure we shouldn't rewrite
>> bits of GDB in Ada instead of C++?
>
> :-)
>
>

Re: Will therefore GDB utilize C++? Not.

[Michael Eager]

On 04/06/2012 04:32 PM, John Gilmore wrote:
>> And yet, that's exactly what we are doing:
>>    - unit elaboration;
>>    - gdbarch/language dispatching
>>    - exception handling
>>    - use of unions to emulate polymorphism;
>
> Writing modular programs is a good idea even if we don't do it in C++.
> I have heard it claimed that many techniques of modular programming
> were even invented before C++ existed - though that may be doubted.

If a discussion about the design of C++ adds little to the discussion
about converting gdb to C++, I think that discussing the origins of
modular or object-oriented programming offers even less.

> If people have the energy to rewrite large chunks of GDB, why argue
> about it?  Go off and do it.  It's free software -- you don't even
> have to start from scratch like GNU did.  The world can always use a
> new debugger.  You can make a politically correct debugger (pcdb?)
> with an identical interface but a C++ implementation under the hood.
> If it's better than GDB in the long run, maintainers will migrate to
> it, GDB will fall into disrepair, and GNU will adopt it.

That is actually not that bad an idea.  This isn't a matter of
political correctness, but one of technical merit.

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

Re: Will therefore GDB utilize C++? Not.

[Stan Shebs]

On 4/6/12 4:32 PM, John Gilmore wrote:
>
> If people have the energy to rewrite large chunks of GDB, why argue
> about it?  Go off and do it.  It's free software -- you don't even
> have to start from scratch like GNU did.  The world can always use a
> new debugger.  You can make a politically correct debugger (pcdb?)
> with an identical interface but a C++ implementation under the hood.
> If it's better than GDB in the long run, maintainers will migrate to
> it, GDB will fall into disrepair, and GNU will adopt it.
>
>

My initial reaction on reading this was "oh that bomb-thrower Gilmore is 
at it again", but upon rereading, I'm not sure whether you're being 
serious, or maybe a little tongue-in-cheek.

In any case, one of the key underlying motivations for the C++ plan is 
that we *don't* have the energy to rewrite large chunks of GDB, nor to 
start over from scratch.  (We delegated that to the LLVM folks. :-) )  
Instead, we need to look for ways to keep growth under control, or to 
simplify things.  For instance, these days we're much more likely to 
delete bits of code that are not in current use, even if one could 
imagine them being helpful in some future scenario.

Another way to simplify the code is to offload work to the compiler.  
Anybody that's known me for any length of time knows that I'm not a big 
fan of C++, but even I have to admit there are some things that can be 
done better in C++ than in C, such as compiler-checked exception 
handling.  Also, it's not like we're working in a vacuum - our friends 
in GCC-land have done a lot to provide good C++ functionality, and I 
know that they would be happy to help us make effective use of C++ in GDB.

Stan

Re: Will therefore GDB utilize C++ or not?

[asmwarrior]

On 2012-4-5 4:47, Tom Tromey wrote:
> My view is that GDB is already written in a poor cousin of C++.
> Nearly every feature that people hate about C++ is already in use in
> GDB.  This list is not exhaustive, just informational:
>
> * Subclasses.  See general_symbol_info.  struct value and struct type
>    would be improved by them.
>
> * Virtual functions.  gdbarch, languages, and values all use these.
>
> * Overloaded functions.  Anywhere you see a _1 suffix.
>
> * Templates.  Both observers and VEC are templates.
>
> * Exceptions.  Used ubiquitously.
>
> * RAII.  Cleanups, but they are dynamic and more error-prone.
>
> * Even global constructors -- init.c.
>
> In most cases, GDB's implementation of these features is inferior to
> that of the C++ compiler.

Agreed. Simulate C++ feature in plain C style macros and callbacks are boring and hard to maintain.

BTW: There are some discussion about C++ in GCC 4.8, maybe, your gdb administrators (committee) can also give a plane.



Asmwarrior
Code::Blocks developer

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

If you asked me not too long ago, I'd have been strongly in favor
of C++.  However, that is no longer the case.  I'm now pending
towards "no C++".

Indeed, gdbserver would need to remain pure C, and likewise any
code shared between gdbserver and gdb should have to be kept
as such.  This is important, because we want gdbserver to be usable
in #1, resource constrained scenarios where the C++ dependency would
be unacceptable.  We don't want there to need to be other gdbserver-like
programs specialized for such environments, and gdbserver to be usable only
on bigger machines.  We want gdbserver to run everywhere.  And #2, the debugger
is one of the first programs that is desirable to get running on a new
system/board.  Usually you get C going much sooner than C++.

This, above, mainly #1, made me spend the last few days thinking about
the "to C++ or not to C++" dilema, and I ended up concluding that C++
may not be a good idea afterall.

I'm very wary that introducing C++ will make it increasingly
difficult to share between the C++ and C parts.  Currently not
that much is shared between gdb and gdbserver, but it is long desired,
and in actually in this year's plan to merge gdb's and gdbserver's
backends (am I am actively working on this.  See
<http://sourceware.org/gdb/wiki/LocalRemoteFeatureParity>).
Another set of code that could also be shared, and thus would need to
remain C is the ser*.c files.  The ser_ops vector is one of those bits that would
be "obvious" candidates for turning into C++ classes, but given the desire to
reuse, it would need to stay C.  The event-loop.c file is yet another thing.
It is currently duplicated (though a bit simplified) in gdbserver/event-loop.c.
There goes another use for C++ classes.

The "monitor foo" commands are implemented completely by the target.  E.g., try
"monitor help" in gdbserver.  GDBserver's implementation of monitor commands
is ad hoc.  This mechanism isn't transparent to GDB and users.  E.g., completion
can't work with these commands.  I have desired before to rip out
GDB's command registration machinery under cli/, making it more modular, and
reusing it in GDBserver.  There goes another big potential user for C++-fication.

And then, there's the exceptions support.  GDBserver's current error handling
is like GDB's was 10 years ago.  There's a simple setjmp at the top
level, and any error longjmp's there.  The debugging session tends
to gets broken when an "error" happens  This is even more likely to happen
with multi-inferior debugging.  As such, and with the gdb -> gdbserver
backend merging in mind, it'd be desirable to make gdbserver's backends
use GDB's TRY_CATCH and friends too.  GDB's backends already do...
Now, if parts of GDB are written in C++, which will be made to
throw/catch C++ exceptions, we end up with the case that we need to wrap
cross-language calls in both directions, in order to bridge/wrap the
incompatible exceptions mechanisms.  IMO, this is a _worse_ state than having
the whole of the GDB core in C, and having everything and everyone speak
the same language.

The target_ops vector is yet another candidate for sharing between native
gdb and gdbserver.  Currently in gdbserver, linux-low.c calls into thread_db.c
directly, while in the native debugger the flow is reversed.  Even if
the target vector ends up being replaced by some other form of chaining,
it'd be very desirable to use the same mechanism in either the native debugger
or gdbserver.  So this means that the target_ops vector is something else
that is probably not good to consider converting to C++ classes, although
it always shows up high on the list of candidates.

And I'm sure I could come up with other examples of things that would be
nice C++ classes, but, we better not make them so.

We can't really tell at this point what could or not be C++-ified
freely, and I'd hate it to see some code converted to C++, only to
end up needing to fork it and convert it to C down the road.  Or worse,
rewrite it from scratch.

(On a sidenote: I get the impression from some that C++ would be mostly
useful for the stronger static typing, but I can't help finding it in
contrast with the simultaneous push of some of GDB functionality towards
being implemented in python, with duck typing and all, which people
are happy with.  One (uninvestigated) idea I had was to take a look at
Linux's sparse tool for catching issues like the "offsets" case that
led to this thread.)

There's also the issue with in-process code, which is also
desirable to remain as C code.  Latest developments push towards having
debugger code run _within_ the inferior.  Witness gdbserver's current IPA
(in-process agent; libinproctrace.so), which has a lot of coupling in its
implementation (and a lot of code shared), and a bunch of code shared with
gdbserver.  We can't predict which bits of GDB will we want to be able to
reuse in GDBserver or an IPA, but I do believe that we will be considering
it (reuse something more) the future.

So all in all, I believe that in a C++ world, GDB's "C++ in C" wouldn't
really go away; it would end up still being prominent, not as hidden as
libbfd or other dependencies.  Not hidden enough that we could just
tuck it under the carpet.  I worry that this actually makes it _worse_
for new contributers, who will need to learn about GDB's C idiomatic usage,
and whatever new C++ idiomatic usage GDB would end up with.  With that, and
the worry about the new source of trouble and bugs and confusion that
it would be the bridging between the parts written in the different languages,
I do believe we're better off staying in C land, at least for a couple years more.

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
> Indeed, gdbserver would need to remain pure C,
[...]
> This is important, because we want gdbserver to be usable
> in #1, resource constrained scenarios where the C++ dependency would
> be unacceptable.  We don't want there to need to be other gdbserver-like
> programs specialized for such environments, and gdbserver to be usable only
> on bigger machines.  We want gdbserver to run everywhere.  And #2, the debugger
> is one of the first programs that is desirable to get running on a new
> system/board.  Usually you get C going much sooner than C++.

While it was said before gdbserver should stay in C I did not see it long-term
maintainable - due to the code sharing goals.  While I wanted to simplify the
talk excluding gdbserver first we can talk even about C++ization of gdbserver.

Which specific platforms do you talk about which is UNIX compatible (=FSF
gdbserver compatible, not just an embedded stub) and cannot run C++ programs?
(*)  Please give examples of viable platforms with future development.

(*) The smallest device I know about is SIM card - and it runs Java (Card) VM,
    therefore more heavy environment than C++.


> The event-loop.c file is yet another thing.
> It is currently duplicated (though a bit simplified) in gdbserver/event-loop.c.
> There goes another use for C++ classes.

The mail lists all the code parts which cannot be C++ized.  I do not find that
too interesting.  I find interesting code parts which can be C++ized - such as
anything about symbols/types outside of gdbserver.


> (On a sidenote: I get the impression from some that C++ would be mostly
> useful for the stronger static typing,

Not just that one, std::string vs. cleanups vs. exceptions are even more
wanted (by me); just static typing (probably) cannot be done without C++,
the other parts are still being fixed up without C++.


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 04/09/2012 08:05 PM, Jan Kratochvil wrote:

> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
>> Indeed, gdbserver would need to remain pure C,
> [...]
>> This is important, because we want gdbserver to be usable
>> in #1, resource constrained scenarios where the C++ dependency would
>> be unacceptable.  We don't want there to need to be other gdbserver-like
>> programs specialized for such environments, and gdbserver to be usable only
>> on bigger machines.  We want gdbserver to run everywhere.  And #2, the debugger
>> is one of the first programs that is desirable to get running on a new
>> system/board.  Usually you get C going much sooner than C++.
> 
> While it was said before gdbserver should stay in C I did not see it long-term
> maintainable - due to the code sharing goals.  


I do.

> While I wanted to simplify the
> talk excluding gdbserver first we can talk even about C++ization of gdbserver.
> 
> Which specific platforms do you talk about which is UNIX compatible (=FSF
> gdbserver compatible, not just an embedded stub) and cannot run C++ programs?
> (*)  Please give examples of viable platforms with future development.


GNU's not UNIX.  Haven't you heard?  And why do you keep excluding embedded
things?  This is a recurrent point you raise in several discussions.
Haven't you noticed the trend towards mobile computing?  Even Red Hat
has business in the embedded world since a long long time (GNUPro and
services).  Even Android/Bionic doesn't support C++ exceptions (not sure
if it doesn't in recent versions or not).

I don't even need to leave my office to find such a system.

$ssh 192.168.0.253
[pedro@NAS][~]
>ls /usr/lib/libstd*
ls: cannot access /usr/lib/libstdc*: No such file or directory
> uname -a
Linux NAS 2.6.24.4 #1 Tue Feb 10 11:00:22 GMT 2009 armv5tejl unknown

>> The event-loop.c file is yet another thing.
>> It is currently duplicated (though a bit simplified) in gdbserver/event-loop.c.
>> There goes another use for C++ classes.
> 
> The mail lists all the code parts which cannot be C++ized.  I do not find that
> too interesting.  


It explained that many core parts of GDB should stay in C.  Which served
to raise awareness that converting just a few parts to avoid a few bugs and making
things neater here and there has a lot of potential for making things worse.
I find interesting code parts which can be C++ized - such as

> anything about symbols/types outside of gdbserver.


It is very much not clear to me that it is worth the pain (that I tried to show
we will end up with) to bring in C++ for this.  Symbol/types even are long lived
objects, it's not common at all to need to worry about leaks (RAII/exceptions)
here.  And all we have are simple hierarchies.  As much as I like C++, C does
quite fine here too.  The language it is written in is not the problem with
our symbol tables.

>

> 
>> (On a sidenote: I get the impression from some that C++ would be mostly
>> useful for the stronger static typing,
> 
> Not just that one, std::string vs. cleanups vs. exceptions are even more
> wanted (by me); just static typing (probably) cannot be done without C++,
> the other parts are still being fixed up without C++.


Sure, there will always be bugs.  C++ doesn't magically make all bugs go away.
Even RAII is not _that_ different from cleanups.  We still need to have a
way to tell the RAII wrapper objects to stop managing whatever they're managing,
for instance.  And with C++98/03, we have to write these things out of line, like
cleanups too.  What I'm saying is that our C mechanisms work.  There is no need to
rush to replace them.  We should consider this very very carefully, not just
flip just because.

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Paul Smith]

On Mon, 2012-04-09 at 20:48 +0100, Pedro Alves wrote:
> I don't even need to leave my office to find such a system.
> 
> $ssh 192.168.0.253
> [pedro@NAS][~]
> >ls /usr/lib/libstd*
> ls: cannot access /usr/lib/libstdc*: No such file or directory

I personally have no strong feelings about this either way but note the
above is not an argument against C++ on embedded systems.  On many of
the systems I use I statically link libstdc++ with at least some
programs; this is well-supported (by GCC at least) and IMO a quite
reasonable solution for utilities such as gdbserver.

The question is not whether systems provide a C++ userspace environment
by default (such as libstdc++): static linking can take care of that
very neatly.  The question is how many of them WOULD be able to run
gdbserver in C, but NOT able to run gdbserver in C++ (from a resource
point of view).

Re: Will therefore GDB utilize C++ or not?

[Daniel Jacobowitz]

On Mon, Apr 9, 2012 at 3:48 PM, Pedro Alves <palves@redhat.com> wrote:
> On 04/09/2012 08:05 PM, Jan Kratochvil wrote:
>
>> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
>>> Indeed, gdbserver would need to remain pure C,
>> [...]
>>> This is important, because we want gdbserver to be usable
>>> in #1, resource constrained scenarios where the C++ dependency would
>>> be unacceptable.  We don't want there to need to be other gdbserver-like
>>> programs specialized for such environments, and gdbserver to be usable only
>>> on bigger machines.  We want gdbserver to run everywhere.  And #2, the debugger
>>> is one of the first programs that is desirable to get running on a new
>>> system/board.  Usually you get C going much sooner than C++.

The more things we add to gdbserver, the less I think it meets the
goal of "simple, light-weight target agent".  I resisted code sharing
with GDB for a long time.  If the consensus nowadays is that code
sharing is the way to go, then I think it behooves someone to figure
out the needs of a modern light-weight target agent that's a lot
smaller than gdbserver.

Yes, multiprocess debugging with gdbserver is an awesome development.
No, you don't need it in the stage of system bringup where you don't
have C++, if you're planning to have C++ eventually.  So I think
there's room for a potential C++ gdbserver and a small C gdbserver.

How did I end up being the curmudgeon?  I'm confused.

-- 
Thanks,
Daniel

RE: Will therefore GDB utilize C++ or not?

[Paul_Koning]

Yes, it's good to be watchful for code bloat on gdbserver.  But a very big difference between it and gdb is that the symbol tables are at the gdb end.  In our case, that's the main reason we use gdbserver.  It would be tolerable for the executable to be bigger, but we don't have space for many of the inferior's symbol tables on the target system.

	paul

-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Daniel Jacobowitz
Sent: Thursday, April 12, 2012 4:06 PM
To: Pedro Alves
Cc: Jan Kratochvil; Tom Tromey; gdb@sourceware.org
Subject: Re: Will therefore GDB utilize C++ or not?

On Mon, Apr 9, 2012 at 3:48 PM, Pedro Alves <palves@redhat.com> wrote:
> On 04/09/2012 08:05 PM, Jan Kratochvil wrote:
>
>> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
>>> Indeed, gdbserver would need to remain pure C,
>> [...]
>>> This is important, because we want gdbserver to be usable in #1, 
>>> resource constrained scenarios where the C++ dependency would be 
>>> unacceptable.  We don't want there to need to be other 
>>> gdbserver-like programs specialized for such environments, and 
>>> gdbserver to be usable only on bigger machines.  We want gdbserver 
>>> to run everywhere.  And #2, the debugger is one of the first 
>>> programs that is desirable to get running on a new system/board.  Usually you get C going much sooner than C++.

The more things we add to gdbserver, the less I think it meets the goal of "simple, light-weight target agent".  I resisted code sharing with GDB for a long time.  If the consensus nowadays is that code sharing is the way to go, then I think it behooves someone to figure out the needs of a modern light-weight target agent that's a lot smaller than gdbserver.

Yes, multiprocess debugging with gdbserver is an awesome development.
No, you don't need it in the stage of system bringup where you don't have C++, if you're planning to have C++ eventually.  So I think there's room for a potential C++ gdbserver and a small C gdbserver.

How did I end up being the curmudgeon?  I'm confused.

--
Thanks,
Daniel

Re: Will therefore GDB utilize C++ or not?

[Doug Evans]

On Thu, Apr 12, 2012 at 1:06 PM, Daniel Jacobowitz
<daniel.jacobowitz@gmail.com> wrote:
> The more things we add to gdbserver, the less I think it meets the
> goal of "simple, light-weight target agent".  I resisted code sharing
> with GDB for a long time.  If the consensus nowadays is that code
> sharing is the way to go, then I think it behooves someone to figure
> out the needs of a modern light-weight target agent that's a lot
> smaller than gdbserver.
>
> Yes, multiprocess debugging with gdbserver is an awesome development.
> No, you don't need it in the stage of system bringup where you don't
> have C++, if you're planning to have C++ eventually.  So I think
> there's room for a potential C++ gdbserver and a small C gdbserver.

[filing for reference sake]

I'd (ultimately) like to see gdb and gdbserver built up out of a set
of, umm, libraries ("We need more libraries!").
Exporting the functionality of the libraries to scripting languages
(e.g., python) through these libraries would involve more of a C API
than C++.

With said partitioning of functionality, it shouldn't be that hard to
have either a small and simple gdbserver or a large and feature-rich
gdbserver.

[side question: Do people that want a small embedded-system-like
gdbserver, also want it to have same features as the the massively
feature rich gdbserver of a non-embedded-system gdbserver?  I'd expect
that they're ok that the overarching need of smallness precluding
some, umm, bloatware. :-)]

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 04/13/2012 01:04 AM, Doug Evans wrote:

> On Thu, Apr 12, 2012 at 1:06 PM, Daniel Jacobowitz
> <daniel.jacobowitz@gmail.com> wrote:
>> The more things we add to gdbserver, the less I think it meets the
>> goal of "simple, light-weight target agent".  I resisted code sharing
>> with GDB for a long time.  If the consensus nowadays is that code
>> sharing is the way to go, then I think it behooves someone to figure
>> out the needs of a modern light-weight target agent that's a lot
>> smaller than gdbserver.
>>
>> Yes, multiprocess debugging with gdbserver is an awesome development.
>> No, you don't need it in the stage of system bringup where you don't
>> have C++, if you're planning to have C++ eventually.  So I think
>> there's room for a potential C++ gdbserver and a small C gdbserver.
> 
> [filing for reference sake]
> 
> I'd (ultimately) like to see gdb and gdbserver built up out of a set
> of, umm, libraries ("We need more libraries!").


I'm aiming torwards making the gdbserver backends be a library that
is reused by both gdb and gdbserver.  Gotta start somewhere.

> Exporting the functionality of the libraries to scripting languages
> (e.g., python) through these libraries would involve more of a C API
> than C++.
> 
> With said partitioning of functionality, it shouldn't be that hard to
> have either a small and simple gdbserver or a large and feature-rich
> gdbserver.


Exactly.

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Doug" == Doug Evans <dje@google.com> writes:

Doug> Exporting the functionality of the libraries to scripting languages
Doug> (e.g., python) through these libraries would involve more of a C API
Doug> than C++.

I think you can wrap a C++ library in Python just fine, especially since
we're writing all the bindings manually anyhow.

Tom

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 04/12/2012 09:06 PM, Daniel Jacobowitz wrote:

> On Mon, Apr 9, 2012 at 3:48 PM, Pedro Alves <palves@redhat.com> wrote:
>> On 04/09/2012 08:05 PM, Jan Kratochvil wrote:
>>
>>> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
>>>> Indeed, gdbserver would need to remain pure C,
>>> [...]
>>>> This is important, because we want gdbserver to be usable
>>>> in #1, resource constrained scenarios where the C++ dependency would
>>>> be unacceptable.  We don't want there to need to be other gdbserver-like
>>>> programs specialized for such environments, and gdbserver to be usable only
>>>> on bigger machines.  We want gdbserver to run everywhere.  And #2, the debugger
>>>> is one of the first programs that is desirable to get running on a new
>>>> system/board.  Usually you get C going much sooner than C++.
> 
> The more things we add to gdbserver, the less I think it meets the
> goal of "simple, light-weight target agent".


Most things we add to gdbserver are optional.  E.g., tracepoints, and the
accelerated DSO list reading.  It'd be simple to add a --bare-bones configure
switch that disabled all the optional features.

> Yes, multiprocess debugging with gdbserver is an awesome development.

> No, you don't need it in the stage of system bringup where you don't
> have C++, if you're planning to have C++ eventually.  


I don't think multiprocess debugging adds much in terms of
code size.  It touches a lot, because it paremetrizes things with
additional structures instead of globals, but mostly, that's it.
A lot of code needed to _change_, not be added.

> So I think
> there's room for a potential C++ gdbserver and a small C gdbserver.

Seriously, I'd very very much like to fuse GDB's and GDBserver's backends,
to eliminate the duplication, which really gets in the way.  I should know;
adding multi-process and non-stop to gdbserver wasn't that much accelerated
from having added it to gdb itself, given how the codebases are similar, yet
so different.
So on order to remove the duplication, we'd end up with _two_ gdbservers, written
in different languages, each with its own bugs and need for maintenance, adding of
new arch ports, etc.?  Doesn't seem like a net win to me.  :-)

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Daniel Jacobowitz]

On Wed, Apr 18, 2012 at 10:07 AM, Pedro Alves <palves@redhat.com> wrote:
> On 04/12/2012 09:06 PM, Daniel Jacobowitz wrote:
>> The more things we add to gdbserver, the less I think it meets the
>> goal of "simple, light-weight target agent".
>
>
> Most things we add to gdbserver are optional.  E.g., tracepoints, and the
> accelerated DSO list reading.  It'd be simple to add a --bare-bones configure
> switch that disabled all the optional features.

A complex program with optional features doesn't get simpler just
because the optional
bits are turned off.  The more configuration options there are, the
less likely any of them
work.  That's my position.

>> Yes, multiprocess debugging with gdbserver is an awesome development.
>
>> No, you don't need it in the stage of system bringup where you don't
>> have C++, if you're planning to have C++ eventually.
>
>
> I don't think multiprocess debugging adds much in terms of
> code size.  It touches a lot, because it paremetrizes things with
> additional structures instead of globals, but mostly, that's it.
> A lot of code needed to _change_, not be added.

A lot of code needs to be *more complicated* because of it.  That's
what I think is the mistake.
I'll even argue that multi-threaded support with a C++ dependency is
basically OK.  If we're going to have
trouble because of uclibc or Android or LynxOS, then we can either
change the minimal feature set supported
by the C version or we can make the necessary runtime work on the
bigger platforms.

I really don't think it's infeasible.  I don't think that there's a
good reason to restrict the progress of the larger
program because we need a small program too.

>
>> So I think
>> there's room for a potential C++ gdbserver and a small C gdbserver.
>
> Seriously, I'd very very much like to fuse GDB's and GDBserver's backends,
> to eliminate the duplication, which really gets in the way.  I should know;
> adding multi-process and non-stop to gdbserver wasn't that much accelerated
> from having added it to gdb itself, given how the codebases are similar, yet
> so different.
> So on order to remove the duplication, we'd end up with _two_ gdbservers, written
> in different languages, each with its own bugs and need for maintenance, adding of
> new arch ports, etc.?  Doesn't seem like a net win to me.  :-)

Does seem like a win to me.  I think people overestimate how
complicated a basic gdbserver port is.
The bits that are hard to figure out you have to figure out for GDB
anyway, if you're going
to bother with GDB.  Especially if threading ends up above the language bar.

-- 
Thanks,
Daniel

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Mon, 09 Apr 2012 21:48:57 +0200, Pedro Alves wrote:
> Symbol/types even are long lived objects, it's not common at all to need to
> worry about leaks (RAII/exceptions) here.

They are and they should not be, this is what archer-jankratochvil-vla with
dynamic types is there for and which are not well maintainable without C++.
There was Tom's reference counting implementation which I found fragile
+ complicated so I wrote a custom garbage collector
	[patch 0/8] Types Garbage Collector (for VLA+Python)
	http://sourceware.org/ml/gdb-patches/2009-05/msg00543.html
but it was sure also a wheel reinvention, with RAII it would be all easier
(sure not automagical but some parts of reference counting done
automatically).


> On 04/09/2012 08:05 PM, Jan Kratochvil wrote:
> > Not just that one, std::string vs. cleanups vs. exceptions are even more
> > wanted (by me); just static typing (probably) cannot be done without C++,
> > the other parts are still being fixed up without C++.
> 
> Sure, there will always be bugs.  C++ doesn't magically make all bugs go away.
> Even RAII is not _that_ different from cleanups.

It is very different, for the very common std::string one does not even have
to start thinking about any cleanups.


If GDB should stay with C then OK (although FYI I am not so in favor of it).
But then it should be real C - therefore  without GDB cleanups, without GDB
TRY_CATCH etc. etc., proper C code returning error codes from each function
and each caller checking it and doing all the local cleanups by hand.

I do not know any larger project in C with proper error checking, there are:

 * Linux kernel lacks proper error reporting, common unclear EPERM from ptrace
   for 100+ different reasons is a great illustration.  At most it uses printk,
   not too good and even reusable for GDB.

 * GCC uses an extra garbage collector with terrible markers in C code, that
   is also not a good example to follow.  I do not remember / know how they
   resolve error reporting / exceptions in GCC.

 * There sure are more larger projects in plain C, but which ones?


Daniel's idea of having two - light (C, separate code) + heavy (C++, GDB
sharing code) - gdbservers I had on my mind myself before his post.


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 04/16/2012 07:54 AM, Jan Kratochvil wrote:

> On Mon, 09 Apr 2012 21:48:57 +0200, Pedro Alves wrote:
>> Symbol/types even are long lived objects, it's not common at all to need to
>> worry about leaks (RAII/exceptions) here.
> 
> They are and they should not be, this is what archer-jankratochvil-vla with
> dynamic types is there for and which are not well maintainable without C++.


I don't even know how to begin to respond to that.  :-)  The symbols side is perhaps
the part of a debugger that needs the most care about memory, and where you'll
most likely to see the need for POD types, and lower level handling of
memory, like the bcache.

> If GDB should stay with C then OK (although FYI I am not so in favor of it).
> But then it should be real C - therefore  without GDB cleanups, without GDB
> TRY_CATCH etc. etc., proper C code returning error codes from each function
> and each caller checking it and doing all the local cleanups by hand.


This is going backwards, and can't really be a serious proposal.

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Wed, 18 Apr 2012 16:10:58 +0200, Pedro Alves wrote:
> On 04/16/2012 07:54 AM, Jan Kratochvil wrote:
> > They are and they should not be, this is what archer-jankratochvil-vla with
> > dynamic types is there for and which are not well maintainable without C++.
> 
> I don't even know how to begin to respond to that.  :-)  The symbols side is perhaps
> the part of a debugger that needs the most care about memory, and where you'll
> most likely to see the need for POD types, and lower level handling of
> memory, like the bcache.

This is the current wrong approach where
(a) CUs are expanded fully, not just the one or few symbols one started
    expanding that CU for.
(b) CUs are expanded needlessly, such as during <tab>-expansion, there are
    more cases I did not analyze.

And then with 99% of symbols not needed at all one tries to optimize every bit
out of each symbol to make the 100% total size bearable...  Just because
everything is statically accessed and the expansion cannot be easily done
on-demand when one accesses the fields by using getters everywhere.

I can't believe we do not agree on such basic way forward.

As one of the many examples the current main_type is unbelievable, I would not
think it is possible to create something so bizarre, it could be sure fixed by
redesigning it even in C (one big union with all fields specific per type and
not just generic fields each overloaded differently for each type).  But then
we would end up with GTK - it has the right design but it is still C++-in-C,
I hope everyone agrees GTK is wrong.


Regards,
Jan

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 04/18/2012 04:15 PM, Jan Kratochvil wrote:

> On Wed, 18 Apr 2012 16:10:58 +0200, Pedro Alves wrote:
>> On 04/16/2012 07:54 AM, Jan Kratochvil wrote:
>>> They are and they should not be, this is what archer-jankratochvil-vla with
>>> dynamic types is there for and which are not well maintainable without C++.
>>
>> I don't even know how to begin to respond to that.  :-)  The symbols side is perhaps
>> the part of a debugger that needs the most care about memory, and where you'll
>> most likely to see the need for POD types, and lower level handling of
>> memory, like the bcache.
> 
> This is the current wrong approach where
> (a) CUs are expanded fully, not just the one or few symbols one started
>     expanding that CU for.
> (b) CUs are expanded needlessly, such as during <tab>-expansion, there are
>     more cases I did not analyze.
> 
> And then with 99% of symbols not needed at all one tries to optimize every bit
> out of each symbol to make the 100% total size bearable... 


You appear to be talking again about high level design choices that really
doesn't have much to do with the language they're implemented in.

Sure, C++ would make some things easier, but it also makes
other objectives harder or impossible.  It's a compromise.

> Just because
> everything is statically accessed and the expansion cannot be easily done
> on-demand when one accesses the fields by using getters everywhere.

I don't understand what you mean.  Certainly adding the C++ getters would be
as much work as adding C getters.  It's not like C++ writes itself.

Again, you don't have to convince me that C++ is nice.  I know it is.
I like it.  I've written C++ for years and practically nothing else.
ut I don't like the prospect of a fragmented GDB with important
parts in C and others in C++, with all the same issues you don't like in C
still in important and wide use.  I loathe the idea of someone contributing
some new code, and having to say "nice, but please rewrite it in C, because we
may need it for X".  If we stick to one language everywhere, in the net sum,
there's less to learn for new comers.

> I can't believe we do not agree on such basic way forward.

> As one of the many examples the current main_type is unbelievable, I would not
> think it is possible to create something so bizarre, it could be sure fixed by
> redesigning it even in C (one big union with all fields specific per type and
> not just generic fields each overloaded differently for each type).  But then
> we would end up with GTK - it has the right design but it is still C++-in-C,
> I hope everyone agrees GTK is wrong.


...

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Wed, 18 Apr 2012 17:27:55 +0200, Pedro Alves wrote:
> I don't like the prospect of a fragmented GDB with important parts in C and
> others in C++,

OK, we can therefore target only this problem.  I do not think we should
seriously code anything in C.

Primarily one can argue there will be already some problem GDB itself will
require C++ environment so that one can no longer run GDB in the early system
bootstrap phases.  I think this disadvantage everyone has already agreed with
for the C++ benefits for GDB.

So there remain only the very niche cases of bootstrapping system without C++
yet and having connected rich system with GDB so that one wants to use
GDBSERVER.  I believe some very simplistic C gdbserver can be used for such
case.  I admit I never bootstrapped such new system myself.  I believe only
few people in the world do so, AFAIK new architectures are no longer being
created so commonly as before even for those few toolchain developers.

Making GDB crashing for every GNU/Linux end-user developer just to make easier
bootstrapping system for the few toolchain developers is IMNSHO not worth it.

I do not repeat all the Bugs here leading to GDB crashes I get continuously
from ABRT (bugreporting system) in Bugzilla due to missing automatic code
sanity checking possible with C++.


We can talk about the C gdbserver, I believe it can be forked from the current
codebase and removed almost everything there, including threading support.
But I do not have experience with new architectures bootstrapping myself.


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 04/18/2012 04:53 PM, Jan Kratochvil wrote:

> On Wed, 18 Apr 2012 17:27:55 +0200, Pedro Alves wrote:
>> I don't like the prospect of a fragmented GDB with important parts in C and
>> others in C++,
> 
> OK, we can therefore target only this problem.  I do not think we should
> seriously code anything in C.


> Making GDB crashing for every GNU/Linux end-user developer just to make easier
> bootstrapping system for the few toolchain developers is IMNSHO not worth it.


Non sequitur.

> We can talk about the C gdbserver, I believe it can be forked from the current

> codebase and removed almost everything there, including threading support.
> But I do not have experience with new architectures bootstrapping myself.


I've already replied to the same point today, 2 times:

 http://sourceware.org/ml/gdb/2012-04/msg00113.html
 http://sourceware.org/ml/gdb/2012-04/msg00110.html

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Joel Brobecker]

> We can talk about the C gdbserver, I believe it can be forked from
> the current codebase and removed almost everything there, including
> threading support.  But I do not have experience with new
> architectures bootstrapping myself.

I we are going to share GDBserver and GDB (understand making GDBserver
a library that GDB uses), I do not think that having a forked copy
of GDBserver in C is a good idea. I'd much rather we evaluate the
concerns of linking with the C++ runtime, for instance.

After reading the whole discussion, I think that there are not enough
advantages outweighing the drawbacks for us to move to C++. Things
may change in the future, but I also feel that there is too much
resitance (within the group of GDB Maintainers) at this time, to make
such a drastic change. I am a little bit surprised by that, since
I thought only one or two of us had reservations, but clearly not so.

-- 
Joel

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Wed, 18 Apr 2012 18:06:44 +0200, Joel Brobecker wrote:
> Things may change in the future,

What can change?  C++ usage is already decreasing, most of the new development
is in Java.  If C++ is already not suitable it will never be.

We should start discussing about moving to Java if C++ is not feasible now.
This paragraph is not meant too seriously but I see no other possibily.


Regards,
Jan

Re: Will therefore GDB utilize C++ or not?

[Joel Brobecker]

> What can change?  C++ usage is already decreasing, most of the new
> development is in Java.  If C++ is already not suitable it will never
> be.

Many things can change. Just one example: The constraints placed
on GDB/GDBserver could change and lead to a more positive terrain
for C++ adoption. Maybe, one day, the conditions will be right.
Just not today.

-- 
Joel

Re: Will therefore GDB utilize C++ or not?

[Joel Sherrill]

On 04/18/2012 11:22 AM, Joel Brobecker wrote:
>> What can change?  C++ usage is already decreasing, most of the new
>> development is in Java.  If C++ is already not suitable it will never
>> be.
> Many things can change. Just one example: The constraints placed
> on GDB/GDBserver could change and lead to a more positive terrain
> for C++ adoption. Maybe, one day, the conditions will be right.
> Just not today.
>
Wading in late .. but is the gdbserver intended to run
on an embedded RTOS with just threads?

If so, then as a broad over generalization, it would be a
shame to push any C++ run-time requirements on a
target that is likely resource constrained. Plus some of
the smaller gcc targets do not support C++.

C++ for tools that will always run on a development host
is a technical programming benefits decision.

But please remember that host does not universally
equal target. What may be right for one side may not
be for the other.

-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 04/18/2012 05:31 PM, Joel Sherrill wrote:

> On 04/18/2012 11:22 AM, Joel Brobecker wrote:
>>> What can change?  C++ usage is already decreasing, most of the new
>>> development is in Java.  If C++ is already not suitable it will never
>>> be.
>> Many things can change. Just one example: The constraints placed
>> on GDB/GDBserver could change and lead to a more positive terrain
>> for C++ adoption. Maybe, one day, the conditions will be right.
>> Just not today.
>>
> Wading in late .. but is the gdbserver intended to run
> on an embedded RTOS with just threads?


No, it assumes some more unixy-ish OS what spawns processes,
though it scales down to Linux with uclibc, bionic, and other
userspaces (along with supporting a few other OSs, like Lynx,
Windows and Windows CE.)  It could be made to bolt into
such embedded targets, but nobody has ever done that, AFAIK.

> 
> If so, then as a broad over generalization, it would be a
> shame to push any C++ run-time requirements on a
> target that is likely resource constrained. Plus some of
> the smaller gcc targets do not support C++.
> 
> C++ for tools that will always run on a development host
> is a technical programming benefits decision.
> 
> But please remember that host does not universally
> equal target. What may be right for one side may not
> be for the other.
> 



-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Joel Brobecker]

> > Wading in late .. but is the gdbserver intended to run
> > on an embedded RTOS with just threads?
> 
> No, it assumes some more unixy-ish OS what spawns processes,
> though it scales down to Linux with uclibc, bionic, and other
> userspaces [...]

The point remains valid, though, that GDBserver needs to remain
reasonably small. We run LynxOS on boards that occasionally run
out of memory, so resource management is a concern...

-- 
Joel

Re: Will therefore GDB utilize C++ or not?

[Joel Sherrill]

On 04/18/2012 11:57 AM, Joel Brobecker wrote:
>>> Wading in late .. but is the gdbserver intended to run
>>> on an embedded RTOS with just threads?
>> No, it assumes some more unixy-ish OS what spawns processes,
>> though it scales down to Linux with uclibc, bionic, and other
>> userspaces [...]
> The point remains valid, though, that GDBserver needs to remain
> reasonably small. We run LynxOS on boards that occasionally run
> out of memory, so resource management is a concern...
>
Defining run-time requirements for gdb stubs, gdbserver,
gdb itself and any other gdb components would be good
as you discuss what changes might be considered for
each.

Introducing an undesirable dependency is easy.

FWIW your LynxOS target board is likely what I could
consider a large target for RTEMS. :)

-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985

RE: Will therefore GDB utilize C++ or not?

[Paul_Koning]

Same here.  A NetBSD system with 128 MB of memory (there is more elsewhere, but not for that OS or for its processes).  Gdbserver is a wonderful tool, making possible debugging that gdb could not possibly do because of its size.  But for that to work it has to remain small.  It's already pushing the limits (300k or so when linked statically).

	paul

-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Joel Brobecker
Sent: Wednesday, April 18, 2012 12:57 PM
To: Pedro Alves
Cc: Joel Sherrill; Jan Kratochvil; Tom Tromey; gdb@sourceware.org
Subject: Re: Will therefore GDB utilize C++ or not?

> > Wading in late .. but is the gdbserver intended to run on an 
> > embedded RTOS with just threads?
> 
> No, it assumes some more unixy-ish OS what spawns processes, though it 
> scales down to Linux with uclibc, bionic, and other userspaces [...]

The point remains valid, though, that GDBserver needs to remain reasonably small. We run LynxOS on boards that occasionally run out of memory, so resource management is a concern...

--
Joel

Re: Will therefore GDB utilize C++ or not?

[Frank Ch. Eigler]

<Paul_Koning@Dell.com> writes:

> Same here.  A NetBSD system with 128 MB of memory (there is more
> elsewhere, but not for that OS or for its processes).  Gdbserver is
> a wonderful tool [...] It's already pushing the limits (300k or so when
> linked statically).

Has there been some experimentation performed to produce evidence 
that a C++ized gdbserver would be substantially larger?

- FChE

RE: Will therefore GDB utilize C++ or not?

[Paul_Koning]

I don't know.  Not by me, certainly.  I just wanted to point out that space is a very real concern already.

	paul

-----Original Message-----
From: Frank Ch. Eigler [mailto:fche@redhat.com] 
Sent: Wednesday, April 18, 2012 4:37 PM
To: Koning, Paul
Cc: brobecker@adacore.com; palves@redhat.com; joel.sherrill@oarcorp.com; jan.kratochvil@redhat.com; tromey@redhat.com; gdb@sourceware.org
Subject: Re: Will therefore GDB utilize C++ or not?

<Paul_Koning@Dell.com> writes:

> Same here.  A NetBSD system with 128 MB of memory (there is more 
> elsewhere, but not for that OS or for its processes).  Gdbserver is a 
> wonderful tool [...] It's already pushing the limits (300k or so when 
> linked statically).

Has there been some experimentation performed to produce evidence that a C++ized gdbserver would be substantially larger?

- FChE

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> After reading the whole discussion, I think that there are not enough
Joel> advantages outweighing the drawbacks for us to move to C++. Things
Joel> may change in the future, but I also feel that there is too much
Joel> resitance (within the group of GDB Maintainers) at this time, to make
Joel> such a drastic change. I am a little bit surprised by that, since
Joel> I thought only one or two of us had reservations, but clearly not so.

Don't give up yet, maybe I will convince Pedro :-)

But if not, I think we will have to drop it and move on.

Tom

Re: Will therefore GDB utilize C++ or not?

[John Gilmore]

> I do not repeat all the Bugs here leading to GDB crashes I get continuously
> from ABRT (bugreporting system) in Bugzilla due to missing automatic code
> sanity checking possible with C++.

If you are arguing that our test suite does not exercise gdb well
enough to detect simple coding bugs, that argues for spending more
time on the test suite, not rewriting working code into C++.

BTW, someone argued that C++ would improve memory allocation for
e.g. symtabs.  We used to allocate those in our own region-based memory
allocator, so thousands of symbols could be freed at once when new
symbol files are loaded.  Do we not do that any more?

        John

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "John" == John Gilmore <gnu@toad.com> writes:

I didn't reply to some of your earlier notes since they were just
clearly bogus -- straw men, weird characterizations and generalizations
bordering on the insulting, etc -- but a couple people asked me
privately about these.  So I guess I'll respond to this one after all.

John> If you are arguing that our test suite does not exercise gdb well
John> enough to detect simple coding bugs, that argues for spending more
John> time on the test suite, not rewriting working code into C++.

It doesn't really work this way.  Test suites and reviews are good tools
but of course they are imperfect.  You can grind away to the point of
diminishing returns, but the point is not perfection but rather to
accelerate development at a reasonable cost, not an unreasonable one.

The thrust of the argument that I posted, which you have basically
ignored in all its particulars, is (1) gdb is already quite close to C++
in practice, albeit a badly broken dialect, and (2) the constructs gdb
implements are in fact difficult to use correctly in practice.  The
evidence for #2 is all in the gdb-patches archives, mostly along the
lines of bug fixes for various purely avoidable problems.

In programming there are usually two sets of problems to solve.  First,
there are the domain problems.  Then, there are the problems of
expression; these are largely self-induced problems which tend to get
worse as your program ages.  My view is that gdb is hampered, though not
crippled, by the latter class.

John> BTW, someone argued that C++ would improve memory allocation for
John> e.g. symtabs.  We used to allocate those in our own region-based memory
John> allocator, so thousands of symbols could be freed at once when new
John> symbol files are loaded.  Do we not do that any more?

We do.

Full symbols are already reasonably C++y, what with the ops vector.

There are some threads on gdb-patches recently about lazy CU expansion
where, reading between the lines (as one must usually do on gdb-patches,
since bringing up C++ just makes for a distracting argument), you can
see how C++ would help.  Namely, we'd like to change symbol so that it
can optionally point to the corresponding psymbol, but that means
wackiness in the accessors; a problem easily and cleanly solved by
subclassing and virtual methods.  Note that we already have one subclass
of symbols, and there's some indication we'll need more regardless.
Anyway, this is a case where there would be a clarity benefit without
any loss of space (in fact it would be in service of space and
performance gains).

Partial symbols are a different matter.  I think they are a bad
candidate for any sort of change, on the grounds that they are both
reasonably isolated and also extremely space critical.

Tom

Re: Will therefore GDB utilize C++ or not?

[John Gilmore]

> I didn't reply to some of your earlier notes since they were just
> clearly bogus -- straw men, weird characterizations and generalizations
> bordering on the insulting, etc -- but a couple people asked me
> privately about these.  So I guess I'll respond to this one after all.

I had no desire to insult anyone, and I apologize if you were offended.

I wish you'd retract the terms you used for my ideas (bogus, straw
men, weird, etc).  All of my messages on this topic have been serious.
I do realize that I'm a decade out of doing regular daily programming
on GDB, so I try to preface my characterizations with things like "If
this is still true in the GDB design, then ...".

> The thrust of the argument that I posted, which you have basically
> ignored in all its particulars, is (1) gdb is already quite close to C++
> in practice, albeit a badly broken dialect, and (2) the constructs gdb
> implements are in fact difficult to use correctly in practice.  The
> evidence for #2 is all in the gdb-patches archives, mostly along the
> lines of bug fixes for various purely avoidable problems.

Re (1), I could say that C is already quite close to C++, since GDB
is written in C and you say GDB is already quite close to C++.  But
that is not an argument for converting C to C++ (or GDB to C++), it's
just an observation.  Large modular programs use modularity
techniques.  Some of those are also used by C++.  Again, nice
observation, but what does it have to do with converting GDB to C++?

The crux of your argument is (2), that GDB is hard to maintain.  And
the key differences in our opinions on that are that:

  *  Just because it's written in C++ doesn't make it maintainable.  My
     experience so far is that large C programs tend to be more
     maintainable than large C++ programs.  You may dismiss this as an
     insulting generalization, but again, I can't comment on the
     actual maintainability of the actual C++ version of GDB, because
     it doesn't exist.  All I have is experience to guide me.  And
     below is my experience with the maintainability of the C GDB.

  *  I introduced the first ops-vector into GDB (and co-designed and
     built BFD, which made the second ops-vector).  But I was
     receiving many patches on bug-gdb long before we had any
     ops-vectors and long before we had any exceptions, and it was the
     rare patch that actually worked.  My own early patches to GDB
     produced a variety of bugs, before I understood it.  And
     touching anything in wait_for_inferior was guar-an-teeeeeed to
     produce obscure bugs.

See, GDB was a large, complex program even in 1991.  And the average
guy who makes a patch to a large program, makes it solve his
particular problem but usually breaks six other things in the process.
Those patches that people submitted were great guides to intuiting
"what the user's actual problem is", which was often unclear from the
bug report.  But the GDB maintainer (in that case me) had to apply
their knowledge of the structure of GDB in order to *fix* the problem
in a correct way, once they understood what the problem is.

Most such posted patches I would just read, debug the real problem,
and patch it my own way.  With a few people who seemed to have more
insight, I would point out the problems in their patch and ask them to
revise it to solve those problems.  Or I'd point out that e.g. they'd
patched the code but not the documentation, and would they please also
do that.  By training them up that way, ultimately many of those
people (like Fred Fish) became valuable GDB contributors and even were
hired as valuable Cygnus employees.  But you can't afford to do that
for more than about 10% of the patches.  The guy who wrote the patch
has solved his own problem and usually doesn't care to rewrite his
patch, doesn't have the insight to fix it up, or doesn't have the
programming chops to do it well.  And it takes more work to train
somebody, than to just do the work yourself, so you have to ration
your own time.  You just have to resolutely NOT APPLY the other 90% of
the patches, using them only as an informal guide to where problems
might be lurking.

So if there are tons of contributed patches in gdb-patches, for
"purely avoidable problems" that are in the shipping version of GDB,
then they probably result from prior acts of the GDB maintainers, who
inappropriately applied patches from people who don't understand the
structure of GDB.  I would strongly doubt the integrity of these tons
of subsequent contributed patches too, unless they came from a small
set of people who have already made a bunch of GDB patches; they are
again more likely to tear up the guts of GDB and create four other
problems, than they are to fix an existing problem.  Again I'm
speaking in generalities, but these generalities are grounded in years
of being the GDB maintainer and reading all the patches posted to
bug-gdb and gdb-patches.

In summary, I don't think the fact that the average guy can't patch
GDB is an artifact of its being written in C.  I think it's an
artifact of it being a large, complex program.  I don't think a
rewrite, into any language, is going to fix that.

> There are some threads on gdb-patches recently about lazy CU expansion

Also, I'm not sure what "lazy CU expansion" is.  I did find a bug (PR
12708 at http://sourceware.org/bugzilla/show_bug.cgi?id=12708) that
mentions "CU expansion" but it never says what that means.  Clearly
it's something to do with tab-expansion of mangled C++ types.  It
seems to have been a psymtab bug, since --readnow fixed it.  Aha!  The
test case for that bug mentions "Compilation Unit" expansion.  Of
course, must be obvious (to somebody -- though web search engines
did not turn up any useful references).  This, it seems to me, means
turning a psymtab into a symtab.  Is that what we're talking about?

>		  Namely, we'd like to change symbol so that it
> can optionally point to the corresponding psymbol, but that means
> wackiness in the accessors; a problem easily and cleanly solved by
> subclassing and virtual methods.  Note that we already have one subclass
> of symbols, and there's some indication we'll need more regardless.

By psymbol I presume you mean partial_symbol.  And I'm working from
your email message (in which you read between the lines of some
gdb-patches); I haven't looked at those patches since you weren't
specific about which ones you're talking about.

The whole design of partial_symbols was that they're only needed when
the real symbols haven't been read in.  This is well documented.  In
fact the partial_symtab for a file can be (or used to be able to be)
thrown away when the real symtab is created, and many symbol-readers
never bothered to create partial_symbols.  Partial symtabs were only a
speed optimization to avoid parsing Stabs debugging info when host
machines ran at 20 megahertz.  You could probably get rid of them
entirely nowadays.

Now, you could conceivably keep the partial_symtab (and hope that it
pages out since you'll never access it), and at some later point,
throw away the entire real symtab.  Then subsequent accesses to this
range of addresses or symbols would again start accessing the
partial_symtab.  This would let you reclaim some memory, but would
require a reread of these symbols the next time execution stopped
inside this file (or someone accessed a partial_symbol from it).
(You'd also have to do a sweep of all other symbol pointers, e.g. for
saved $37 values, to make sure that none of them point into the symtab
you're trying to throw away.)  But I think the idea in these patches
is some idea that's much more granular than that, like throwing away
95% of the symbols in a file, while retaining 5%?  Or only reading in
5%, and then going back to reread other symbols into the same symtab
later?

Is it really faster and cheaper to throw away and reread symbols, than
it is to let the operating system's virtual memory page them in and
out?  The beauty of virtual memory is that it does cacheing without
requiring any programming changes.  (Yes, you can optimize virtual
memory based programs by avoiding accesses that would run all over
the memory space.  That was part of the idea of keeping the
symbols in obstacks, where they're all close to each other in memory.
If you want to throw 95% of them away, what kind of memory
allocator do you plan to use to preserve the locality of reference of
the remaining 5%?)

The GDB Internals manual (which I originated when I discovered that
there was no internals documentation) makes it clear that there are
only a few ways to look up a symbol.  Has that nice clean bit of
modular C programming has been retained over the last decade?  If so,
then you could change the implementation of symbol tables in just
those few places, so that the lookup code would handle symbols that
pointed to partial_symbols.  And as long as the full symbol got
created before those few lookup functions returned and some other bit
of code went poking around in the guts of the symbol, then the rest of
GDB wouldn't need to change.  (That modularity is how psymtabs work, too;
most of GDB never needs to care about them, and none of it needs to
depend upon their existence.)

But if you're going to have a struct symbol that other things can
point to, but which internally only contains a psymbol pointer, you'll
still need to allocate all the space for the whole struct symbol.
Because when someone touches it and you need to read the real symbol
in, you can't change the address of the struct symbol.  (If you did
change its address, then you'd have to find all the things that point
to it, and revise those pointers to point to the new one.)  So how is
this idea of pointing to psymbols going to save any memory?  And if
you're going to have to allocate all the memory for the struct symbol,
then why not populate it with the real information for the symbol,
instead of just a psymbol pointer?

Or else are you talking about only reading in a few symbols from 
a symbol-file when a lookup indicates that you need to expand a psymtab
into a symtab?  You could try that, but it's probably a hive of
bugs, because you'd have to recurse to find all the symbols that
the symbol-of-interest needs.  It's much simpler to read all the
symbols in a symbol file, in order, and once you're doing that
anyway, you might as well save them all.

(You could try doing a super cheap optimization and merely stop
reading and creating symbols after you've defined the particular
symbol that you are looking for.  This wouldn't require
symbols-that-point-to-psymbols; it would instead require lookups to
look in both the psymtab and the symtab, even if there's a symtab.
This would also involve removing duplicates, now that we'd look at
both, or require some fancy footwork to only look in the PART of the
psymtab that hadn't already been read into a symtab.  Subsequent
efforts to expand the psymtab to find some different symbol, would
resume reading from where the previous symbol-reading-and-creation
left off.  This would probably be a much easier change than to 
make a symtab entry be able to point to a psymtab entry.)

> Full symbols are already reasonably C++y, what with the ops vector.

It looks to me like the "ops vector" in symbols in gdb-7.4 is pretty
minimal, only applying to a tiny number of symbol categories (and the
comments in findvar.c -- from 2004 -- report that DWARF2 symbols screw
up the ops vector anyway).  Large parts of GDB touch symbols; is the
idea that all of these will be rewritten to indirect through an
ops-table (either explicitly in C, or implicitly in C++) without ever
accessing fields (like SYMBOL_CLASS(sym)) directly?  Do you think this
will make GDB faster and smaller?  I don't.

(There's a comment in symtab.c from 2003 that says address classes and
ops vectors should be merged.  But clearly nobody has felt like doing
that work in the last 9 years -- probably because so many places in the
code would need to be touched.  You can't use C++ to overload
those symbols without touching all the same places that nobody wanted
to touch for a decade.)

In conclusion, why does making this change require (or encourage) C++?
The idea seems to require changing a ton of working code, whether it's
ultimately done in C or in C++, which makes it an unappetizing change
in any language.  It would take a powerful heap of benefit to make
it worth doing that.

	John

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

I'm sorry this reply has taken so long.  I didn't mean to let this drop
off -- I think a sort of generic problem in gdb is over-use of the
pocket veto -- but I've been away, sick, etc.

John> I wish you'd retract the terms you used for my ideas (bogus, straw
John> men, weird, etc).

Ok, I retract those adjectives.

John> All of my messages on this topic have been serious.

Ok.

John> Re (1), I could say that C is already quite close to C++, since GDB
John> is written in C and you say GDB is already quite close to C++.

Your statement here is a generic one, disconnected from any particular
fact about GDB -- a problem that pervades your response.  It could apply
to any C program.  But, my argument is about GDB in particular; and
cannot be transferred to any C program as-is.

You can see this most easily if you re-read the bullet list in
http://sourceware.org/ml/gdb/2012-04/msg00044.html

John> Large modular programs use modularity techniques.  Some of those
John> are also used by C++.  Again, nice observation, but what does it
John> have to do with converting GDB to C++?

The list isn't only about modularity techniques.  For instance, few pure
C programs use exceptions -- it is a rarity.  But, GDB uses them
ubiquitously, and we know that their current expression in GDB causes
bugs; bugs which are easily avoided in C++.

John>   *  Just because it's written in C++ doesn't make it
John>   maintainable.

Nobody claims this.

John> See, GDB was a large, complex program even in 1991.  And the average
John> guy who makes a patch to a large program, makes it solve his
John> particular problem but usually breaks six other things in the process.

There are lots of kinds of patches.  And, there is no silver bullet.  I
don't think C++ will magically solve everything, but it will remove some
subset of bugs and make some planned changes easier.

And, this proposal can't really be disconnected from gdb as it currently
is.

For example, look at the Python layer.  Despite patch review and our
knowledge of the issues, we still have error-checking and
reference-counting bugs in the code.  You can go through the list
archives and find them.

This is an example of the sort of problem that we could define out of
existence.

Cleanups are another good example.  I've personally fixed any number of
small memory leaks, cleanup misuses, etc -- but more remain.  RAII is
simply a better programming technique.

The frame cache is yet another example.  There's a bunch of bugs
relating to keeping frame_info objects across invalidations of the frame
cache.  These are very tricky to see via patch review.  This is also a
hard problem to fix systematically in C.  In C++ you can do it pretty
easily though.

John> So if there are tons of contributed patches in gdb-patches, for
John> "purely avoidable problems" that are in the shipping version of GDB,
John> then they probably result from prior acts of the GDB maintainers, who
John> inappropriately applied patches from people who don't understand the
John> structure of GDB.

Patch review will never be perfect.  It is typical for even very
experienced gdb hackers to miss things during review.  My view is that
we should use multiple tools to eliminate bugs at their source -- and
that the cheapest way, by far, is to define them away by letting the
compiler do the heavy work.

Tom> There are some threads on gdb-patches recently about lazy CU expansion

John> Also, I'm not sure what "lazy CU expansion" is.

See http://sourceware.org/ml/gdb-patches/2012-04/msg00154.html

Basically it is an attempt to scale gdb's symbol reading performance.
Even this may not be sufficient, given the size of programs we're seeing
now.

I'll reply to the rest of this in a separate note.  It is really a
different thread.

Tom

Re: Will therefore GDB utilize C++ or not?

[Paul_Koning]

On May 18, 2012, at 2:36 PM, Tom Tromey wrote:

> ...
> For example, look at the Python layer.  Despite patch review and our
> knowledge of the issues, we still have error-checking and
> reference-counting bugs in the code.  You can go through the list
> archives and find them.

How would C++ help with reference counting bugs?  I could see how it might (or might not) help with the subset related to error handling that can be made clearer with exceptions.  But the reference counting errors I remember were straight algorithmic mistakes that, as far as I can see, would have existed in the exact same form if the algorithm had been expressed in C++.

	paul

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:

Tom> For example, look at the Python layer.  Despite patch review and our
Tom> knowledge of the issues, we still have error-checking and
Tom> reference-counting bugs in the code.  You can go through the list
Tom> archives and find them.

Paul> How would C++ help with reference counting bugs?  I could see how it
Paul> might (or might not) help with the subset related to error handling
Paul> that can be made clearer with exceptions.  But the reference counting
Paul> errors I remember were straight algorithmic mistakes that, as far as I
Paul> can see, would have existed in the exact same form if the algorithm
Paul> had been expressed in C++.

We'd use RAII to ensure that refcounts were automatically managed by the
C++ compiler.

Tom

Re: Will therefore GDB utilize C++ or not?

[Paul_Koning]

On May 18, 2012, at 3:20 PM, Tom Tromey wrote:

>>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:
> 
> Tom> For example, look at the Python layer.  Despite patch review and our
> Tom> knowledge of the issues, we still have error-checking and
> Tom> reference-counting bugs in the code.  You can go through the list
> Tom> archives and find them.
> 
> Paul> How would C++ help with reference counting bugs?  I could see how it
> Paul> might (or might not) help with the subset related to error handling
> Paul> that can be made clearer with exceptions.  But the reference counting
> Paul> errors I remember were straight algorithmic mistakes that, as far as I
> Paul> can see, would have existed in the exact same form if the algorithm
> Paul> had been expressed in C++.
> 
> We'd use RAII to ensure that refcounts were automatically managed by the
> C++ compiler.

That would be nice if the Python ABI is compatible with this.  It may not be, or not always.  For example, when some calls steal a reference while others (most of them) don't, and some return a borrowed reference while others return a new one, it isn't clear how a mechanical scheme like RAII will give you a full answer.  Maybe if you use only the subset that does reference counting in the one way you want it done?  There would be some performance impact but probably not much.

	paul

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Paul" ==   <Paul_Koning@Dell.com> writes:

Tom> We'd use RAII to ensure that refcounts were automatically managed
Tom> by the C++ compiler.

Paul> That would be nice if the Python ABI is compatible with this.  It may
Paul> not be, or not always.  For example, when some calls steal a reference
Paul> while others (most of them) don't, and some return a borrowed
Paul> reference while others return a new one, it isn't clear how a
Paul> mechanical scheme like RAII will give you a full answer.

I think you can write wrapper functions which abstract the details.
We'd want this anyway so we can turn Python exceptions into C++
exceptions.

boost::python basically does all this already, but I've been assuming
we'd roll our own.

Paul> Maybe if you use only the subset that does reference counting in
Paul> the one way you want it done?  There would be some performance
Paul> impact but probably not much.

I think the wrappers would be pretty thin, and there'd be no runtime hit
to speak of.

Tom

Re: Will therefore GDB utilize C++ or not?

[Aurelian Melinte]

On 18/05/2012 4:06 PM, Tom Tromey wrote:
>>>>>> "Paul" ==<Paul_Koning@Dell.com>  writes:
>>>>>>              
> Tom>  We'd use RAII to ensure that refcounts were automatically managed
> Tom>  by the C++ compiler.
>    

C++11 (that is g++ 4.3 and later) offers an std::shared_pointer; 
non-intrusive (the reference is not in the object being pointed to).

Regards,
a.

Lazy CU expansion (Was: Will therefore GDB utilize C++ or not?)

[Tom Tromey]

>>>>> "John" == John Gilmore <gnu@toad.com> writes:

Some comments on your comments about lazy CU expansion.

John> The whole design of partial_symbols was that they're only needed when
John> the real symbols haven't been read in.  This is well documented.  In
John> fact the partial_symtab for a file can be (or used to be able to be)
John> thrown away when the real symtab is created, and many symbol-readers
John> never bothered to create partial_symbols.

I don't think it's been possible to discard a partial symtab for many
years now.

It doesn't seem very worthwhile to do it, given that the bulk of the
memory is in the psymbols themselves, and these can't ever be deleted.
But, maybe it would be worth trying.

John> Partial symtabs were only a
John> speed optimization to avoid parsing Stabs debugging info when host
John> machines ran at 20 megahertz.  You could probably get rid of them
John> entirely nowadays.

This seems unlikely to me; but due to memory use, not CPU.

Partial symbols take a lot less memory than full symbols, partly because
they are smaller, but more importantly because they can be put into the
bcache, and this is quite effective in practice.

John> The GDB Internals manual (which I originated when I discovered that
John> there was no internals documentation) makes it clear that there are
John> only a few ways to look up a symbol.  Has that nice clean bit of
John> modular C programming has been retained over the last decade?

No, the symbol tables are a total mess, and the internals manual is out
of date.

John> So how is this idea of pointing to psymbols going to save any
John> memory?

'struct symbol' starts with a 'general_symbol_info', and also includes
'domain' and 'aclass' fields -- all of which are duplicated in the
partial symbol.

So, pointing to the partial symbol will save at least
sizeof(general_symbol_info) - sizeof(void*) bytes per symbol.  On x86-64
that is 32 bytes.  Maybe it could save more memory with more packing.

More importantly, this sort of thing would allow instantiation of a full
symtab without re-parsing the DWARF.  Re-parsing is slow, and also
mostly pointless, as most symbols in a given CU are never used.

John> And if you're going to have to allocate all the memory for the
John> struct symbol, then why not populate it with the real information
John> for the symbol, instead of just a psymbol pointer?

Reading the remaining information is slow and uses memory, but the
results are often not used.  So it would be preferable to fill in the
details on demand.

Just skipping function bodies alone saves ~30% of the CU expansion time.

John> It's much simpler to read all the symbols in a symbol file, in
John> order, and once you're doing that anyway, you might as well save
John> them all.

Yes, it is simpler.  This is what is done now.  I think it doesn't scale
very well... Jan has dug up some C++ libraries where there is one
enormous CU which sucks up a lot of time if you happen to have to expand
it.

Tom> Full symbols are already reasonably C++y, what with the ops vector.

John> It looks to me like the "ops vector" in symbols in gdb-7.4 is pretty
John> minimal, only applying to a tiny number of symbol categories (and the
John> comments in findvar.c -- from 2004 -- report that DWARF2 symbols screw
John> up the ops vector anyway).  Large parts of GDB touch symbols; is the
John> idea that all of these will be rewritten to indirect through an
John> ops-table (either explicitly in C, or implicitly in C++) without ever
John> accessing fields (like SYMBOL_CLASS(sym)) directly?  Do you think this
John> will make GDB faster and smaller?  I don't.

I doubt it would be smaller.  History indicates this is of zero
importance.

It would probably be faster.  At least for lazy CU expansion, the
changes are of the form:

#define SYMBOL_TYPE(sym) \
  ((sym)->type ? (sym)->type : compute_symbol_type (sym))

... or moral equivalent.

Rewriting is not necessary, you can redefine the macros.
But, rewriting the uses would be better if we were moving to C++.
This is easy though.

John> (There's a comment in symtab.c from 2003 that says address classes and
John> ops vectors should be merged.  But clearly nobody has felt like doing
John> that work in the last 9 years -- probably because so many places in the
John> code would need to be touched.

I'm not sure I trust that comment.  I find that in general, comments in
GDB relating to future maintenance issues are often questionable.

Tom

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> We can talk about the C gdbserver, I believe it can be forked from
Jan> the current codebase and removed almost everything there, including
Jan> threading support.  But I do not have experience with new
Jan> architectures bootstrapping myself.

Someone could resurrect RDA :)

http://sourceware.org/rda/

Tom

Will C++ proponents spend 20 minutes to try what they're proposing?

[John Gilmore]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 9184 bytes --]

Jan Kratochvil said:
> I can't believe we do not agree on such basic way forward.

Changing the implementation language of a huge program, more than
twenty years after its creation, is not "basic".

Has any of the proponents even *tried* to compile and run today's GDB
using a C++ compiler, to see what C constructs that it currently uses
will be rejected by the C++ compiler?  "./configure CC=g++; make check", or
something similar, should do most of that for you.

Recompiling the C code in C++ is the approach you're proposing to
take, right?  Or do you propose that we compile some source files with
a C compiler and others with a C++ compiler?

If it will compile easily with a C++ compiler, then you could start
migrating small bits of it here and there to C++.  If it won't compile
easily, then there's a more substantial hurdle to cross before even a
line of new C++ code could be written.  Ideally if we were going to
switch to C++, we'd migrate the current code base so that it would
compile with either C or C++.  Then and only then would we commit
ourselves by writing new C++ code, knowing that we still have a
working debugger.

When I configure gdb-7.4 with C++ and make it, it fails pretty early
here in libiberty:

./cplus-dem.c: In function ‘void demangle_arm_hp_template(work_stuff*, const char**, int, string*)’:
./cplus-dem.c:2351:46: error: invalid conversion from ‘const char*’ to ‘char*’

(I'm amused that the C++ demangler is the first C function to fail.)

I've appended a bunch of other errors that turn up from "make -i".
There are MANY more, and I didn't scan beyond the "f"s in BFD.  (The
GDB source files themselves also get a ton of errors).  Yes, I realize
many of these are simple fixes.  Perhaps a proponent should make these
fixes.  Some of them bother me, e.g. "deprecated string constant
conversion to char *".  C code regularly uses strings with char *'s.
Is this a foolish hobgoblin of const-correctness?

PS:  When did g++ start outputting non-ascii (Unicode) backquotes
and forward-quotes in its error messages?  That's truly ugly.  Look
at the compiler output in Emacs, for example.

	John

./md5.c: In function ‘void* md5_finish_ctx(md5_ctx*, void*)’:
./md5.c:117:43: warning: dereferencing type-punned pointer will break strict-aliasing rules
./md5.c:118:47: warning: dereferencing type-punned pointer will break strict-aliasing rules

./alloca.c: In function ‘void* C_alloca(size_t)’:
./alloca.c:164:3: warning: ‘auto’ will change meaning in C++0x; please remove it

./floatformat.c:22:0: warning: "_GNU_SOURCE" redefined
<command-line>:0:0: note: this is the location of the previous definition

./stack-limit.c:52:27: warning: use of C++0x long long integer constant
./stack-limit.c:54:28: warning: use of C++0x long long integer constant
./stack-limit.c:57:28: warning: use of C++0x long long integer constant

In file included from archive.c:131:0:
bfd.h:6246:31: error: ‘bfd_boolean bfd_section_already_linked(bfd*, asection*, bfd_link_info*)’ hides constructor for ‘struct bfd_section_already_linked’
In file included from archive.c:132:0:
./../include/libiberty.h:110:36: error: new declaration ‘char* basename(const char*)’
/usr/include/string.h:603:28: error: ambiguates old declaration ‘const char* basename(const char*)’
archive.c: In function ‘bfd_boolean _bfd_write_archive_contents(bfd*)’:
archive.c:2115:11: error: deprecated conversion from string constant to ‘char*’
archive.c:2117:13: error: deprecated conversion from string constant to ‘char*’
In file included from bfd.c:319:0:

cache.c: In function ‘void* cache_bmmap(bfd*, void*, bfd_size_type, int, int, file_ptr, void**, bfd_size_type*)’:
cache.c:440:27: error: pointer of type ‘void *’ used in arithmetic

srec.c:1324:1: error: deprecated conversion from string constant to ‘char*’
srec.c:1380:1: error: deprecated conversion from string constant to ‘char*’

binary.c: In function ‘char* mangle_name(bfd*, char*)’:
binary.c:135:12: error: deprecated conversion from string constant to ‘char*’
binary.c: In function ‘long int binary_canonicalize_symtab(bfd*, asymbol**)’:
binary.c:163:44: error: deprecated conversion from string constant to ‘char*’
binary.c:171:42: error: deprecated conversion from string constant to ‘char*’
binary.c:179:43: error: deprecated conversion from string constant to ‘char*’
binary.c: At global scope:
binary.c:369:1: error: deprecated conversion from string constant to ‘char*’

tekhex.c:1016:1: error: deprecated conversion from string constant to ‘char*’

./dwarf2.c: In function ‘int compare_sequences(const void*, const void*)’:
./dwarf2.c:1299:38: error: invalid conversion from ‘const void*’ to ‘const line_sequence*’
./dwarf2.c:1300:38: error: invalid conversion from ‘const void*’ to ‘const line_sequence*’

elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c:185:1: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c: In function ‘bfd_boolean elf_i386_grok_prstatus(bfd*, Elf_Internal_Note*)’:
elf32-i386.c:454:36: error: deprecated conversion from string constant to ‘char*’
elf32-i386.c: In function ‘bfd_boolean elf_i386_create_dynamic_sections(bfd*, bfd_link_info*)’:
elf32-i386.c:1030:47: error: invalid conversion from ‘void*’ to ‘unsigned char*’
In file included from elf32-i386.c:4989:0:
elf32-target.h: At global scope:
elf32-target.h:987:1: error: deprecated conversion from string constant to ‘char*’
In file included from elf32-i386.c:5022:0:
elf32-target.h:987:1: error: deprecated conversion from string constant to ‘char*’
In file included from elf32-i386.c:5050:0:
elf32-target.h:987:1: error: deprecated conversion from string constant to ‘char*’
In file included from elf32-i386.c:5214:0:
elf32-target.h:987:1: error: deprecated conversion from string constant to ‘char*’
In file included from elf32-i386.c:5259:0:
elf32-target.h:987:1: error: deprecated conversion from string constant to ‘char*’

Re: Will C++ proponents spend 20 minutes to try what they're proposing?

[Jan Kratochvil]

On Wed, 18 Apr 2012 21:18:21 +0200, John Gilmore wrote:
> Has any of the proponents even *tried* to compile and run today's GDB
> using a C++ compiler,

Yes (OK, not myself), using:
	http://sourceware.org/gdb/wiki/ArcherBranchManagement
	archer-ratmice-compile-Wc++-compat

Ratmice has even preliminarily confirmed he would update the branch for HEAD
if the C++ move happens.


Thanks,
Jan

Re: Will C++ proponents spend 20 minutes to try what they're proposing?

[Tom Tromey]

>>>>> "John" == John Gilmore <gnu@toad.com> writes:

John> Has any of the proponents even *tried* to compile and run today's GDB
John> using a C++ compiler, to see what C constructs that it currently uses
John> will be rejected by the C++ compiler?

Yeah.  Also with -Wc++-compat.

John> Recompiling the C code in C++ is the approach you're proposing to
John> take, right?  Or do you propose that we compile some source files with
John> a C compiler and others with a C++ compiler?

No, please see the plan that I posted upthread.  It lays out exactly
what we propose.

http://sourceware.org/ml/gdb/2012-04/msg00044.html

Search for "concrete transition proposal".

John> When I configure gdb-7.4 with C++ and make it, it fails pretty early
John> here in libiberty:

We'd only convert gdb, not libiberty, bfd, etc.

John> PS:  When did g++ start outputting non-ascii (Unicode) backquotes
John> and forward-quotes in its error messages?  That's truly ugly.  Look
John> at the compiler output in Emacs, for example.

There's some long threads about this all over GNUdom.
I can't remember when, it seems like a long time ago now.

Tom

Re: Will C++ proponents spend 20 minutes to try what they're proposing?

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1152 bytes --]

On Wednesday 18 April 2012 16:39:53 Tom Tromey wrote:
> >>>>> "John" == John Gilmore <gnu@toad.com> writes:
> John> PS:  When did g++ start outputting non-ascii (Unicode) backquotes
> John> and forward-quotes in its error messages?  That's truly ugly.  Look
> John> at the compiler output in Emacs, for example.
> 
> There's some long threads about this all over GNUdom.
> I can't remember when, it seems like a long time ago now.

at least they've started moving away from the left quote being a backtick.  
but yes, i believe GNU projects have been doing unicode quotes for a while.

recent gnulib commit:
commit 1a43a982c927eaf26bbc2701a872009d9be4b33b
Author: Paolo Bonzini <bonzini@gnu.org>
Date:   Sun Dec 18 15:44:17 2011 +0100

    quotearg: do not use grave accent for left quote
    
    * lib/quotearg.c (gettext_quote): Map "`" to "'" for locale_quoting_style.
    (quotearg_buffer_restyled): Fix example.
    * tests/test-quotearg-simple.c (results_g): Adjust test vectors.

and indeed, grep-2.11 says:
	Try 'grep --help' for more information.
where it once said:
	Try `grep --help' for more information.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:

Jan> If GDB should stay with C then OK (although FYI I am not so in
Jan> favor of it).  But then it should be real C - therefore without GDB
Jan> cleanups, without GDB TRY_CATCH etc. etc., proper C code returning
Jan> error codes from each function and each caller checking it and
Jan> doing all the local cleanups by hand.

I can't tell if you're joking here, but I don't think it would be very
practical to do this.  It would be an enormous effort.

I have wondered whether we could limit gdbserver and the shared code in
this way.  But I assume that is impractical as well; and now I am more
interested in measuring the actual impact of C++, rather than assuming
it is very bad.

Tom

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> Even Android/Bionic doesn't support C++ exceptions (not sure
Pedro> if it doesn't in recent versions or not).

I think this is an interesting point, but downthread Paul Smith raised
the idea of statically linking libstdc++; and I was wondering whether on
really space-constrained systems one might enable SJLJ exceptions to try
to save space from the unwind tables, my thinking being that this would
reasonably faithfully mimic how the code actually works today.

Pedro> It is very much not clear to me that it is worth the pain (that I
Pedro> tried to show we will end up with) to bring in C++ for this.
Pedro> Symbol/types even are long lived objects, it's not common at all
Pedro> to need to worry about leaks (RAII/exceptions) here.  And all we
Pedro> have are simple hierarchies.  As much as I like C++, C does quite
Pedro> fine here too.  The language it is written in is not the problem
Pedro> with our symbol tables.

We're going to make symbols more complicated to make lazy CU expansion
work, and maybe some other things.

The issue isn't whether it is possible, but instead the cost.  On the
whole I think we spend a lot of time in gdb tending to self-created
problems.  Open data structures (symbol tables are particularly bad
here), inconsistent use of accessors, etc, make some kinds of
refactorings harder than they need to be.

I realize that switching to C++ is not a panacea for this.  Fixing
symbol tables is just hard regardless of how we do it, because the
original sins are all baked into the code already.

But, there are changes that this move would undoubtedly facilitate.
For example, I think we need to virtualize struct value storage to deal
with VLA and sliced arrays.  To me this looks pretty awful from C; but
simpler from C++.

Pedro> Even RAII is not _that_ different from cleanups.

No, it really is.  It is not dynamic, and you don't have to remember to
call do_cleanups on all exit paths.

I've fixed any number of memory (and, IIRC, file descriptor) leaks
caused precisely because cleanups are less good than RAII.

Basically, with cleanups the default is full generality, but this is
wrong.  With RAII the default is block scoping, and you have to expend
effort to do weird stuff.

Pedro> We still need to have a way to tell the RAII wrapper objects to
Pedro> stop managing whatever they're managing, for instance.

There are plenty of canned solutions.

Pedro> We should consider this very very carefully, not just flip just
Pedro> because.

I don't think that is an accurate characterization of the proposal.
I realize the threads get a bit heated though.

I agree that we should consider it very carefully.  And I think we are.

Tom

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 04/18/2012 09:24 PM, Tom Tromey wrote:

> Pedro> Even RAII is not _that_ different from cleanups.
> 
> No, it really is.  It is not dynamic, and you don't have to remember to
> call do_cleanups on all exit paths.


Cleanups are dynamic because they're been crafted that way.
We could tweak cleanups to allow creating them on the stack.

What I meant by not that different, is, that with RAII you get
to write something like (the dumbest version of a RAII object
that supports canceling possible):

class my_raii_thing
{
private:
   whatever_arg *arg; << moral equivalent of the cleanup args.
   bool discarded;

public:
   my_raii_thing (whatever_arg *p) : arg (p), discarded(false)
   {}

   ~my_raii_thing () << moral equivalent of a cleanup function.
   {
      if (!discarded)
        {
          // whatever to release this->arg or something like that.
        }
   }

   void discard ()
   {
      discarded = true;
   }
};

and then do:

  my_raii_thing foo (&whatever_arg);

  if (whatnot)
    {
       whatever_arg.discard();
       return SUCESS;
    }
  }

whereas we now write:

struct cleanup_args
{
  ...
};

void foo_cleanup (void *arg)
{
   // whatever to release this->arg or something like that.
}

and then:

  old_chain = make_cleanup (foo_cleanup, &whatever_arg);

  if (whatnot)
    {
       discard_cleanups (old_chain);
       return SUCESS;
    }
  do_cleanup (old_chain);

But yes, as I've said before elsewhere, give me destructors,
everything else I can live without.  :-)

Basically, whoever understands RAII should understand cleanups.
Not counting the auto-destruction issue, I'm saying that writing
raii classes vs writing cleanup function is mostly syntax sugar.

> 
> I've fixed any number of memory (and, IIRC, file descriptor) leaks
> caused precisely because cleanups are less good than RAII.
> 
> Basically, with cleanups the default is full generality, but this is
> wrong.  With RAII the default is block scoping, and you have to expend
> effort to do weird stuff.


We could make make_cleanup return a reference to this instead of to the
previous (as Doug suggested not long ago), and tweak cleanups to make
it possible to have them on the stack, making their use follow scope
closer too.

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Mon, 21 May 2012 18:27:48 +0200, Pedro Alves wrote:
> and then:
> 
>   old_chain = make_cleanup (foo_cleanup, &whatever_arg);
> 
>   if (whatnot)
>     {
>        discard_cleanups (old_chain);
>        return SUCESS;
>     }
>   do_cleanup (old_chain);
> 
> But yes, as I've said before elsewhere, give me destructors,
> everything else I can live without.  :-)
> 
> Basically, whoever understands RAII should understand cleanups.
> Not counting the auto-destruction issue, I'm saying that writing
> raii classes vs writing cleanup function is mostly syntax sugar.

With RAII you do not have to write many times in that function that do_cleanup
statement (for multiple cleanup markers), which makes one of the differences.


Jan

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Mon, 21 May 2012 18:27:48 +0200, Pedro Alves wrote:
> What I meant by not that different, is, that with RAII you get
> to write something like (the dumbest version of a RAII object
> that supports canceling possible):
> 
> class my_raii_thing
> {
> private:
>    whatever_arg *arg; << moral equivalent of the cleanup args.
>    bool discarded;
> 
> public:
>    my_raii_thing (whatever_arg *p) : arg (p), discarded(false)
>    {}
> 
>    ~my_raii_thing () << moral equivalent of a cleanup function.
>    {
>       if (!discarded)
>         {
>           // whatever to release this->arg or something like that.
>         }
>    }
> 
>    void discard ()
>    {
>       discarded = true;
>    }
> };
> 
> and then do:
> 
>   my_raii_thing foo (&whatever_arg);
> 
>   if (whatnot)
>     {
>        whatever_arg.discard();
>        return SUCESS;
>     }
>   }

I find it too complicated, why not just shared_ptr:

#include <memory>
#include <iostream>
using namespace std;
class R {
public:
  R() { cout << "R new" << endl; }
  ~R() { cout << "R delete" << endl; }
  string val() { return "isR"; }
};
static shared_ptr<R> getR(bool fail) {
  auto v=shared_ptr<R>(new R());
  if (fail)
    throw fail;
  return v;
}
int main() {
  try {
    getR(true);
  } catch (...) {}
  cout << getR(false)->val() << endl;
}

R new
R delete
R new
isR
R delete


As C++11 dependency is probably too strict one can use Boost instead and as GDB
does not like external dependencies stripped down Boost can be bundled to the
sourceware repository - on normal systems sure C++11 libraries get used instead.


Jan

Re: Will therefore GDB utilize C++ or not?

[Yao Qi]

On 04/10/2012 02:41 AM, Pedro Alves wrote:
> Indeed, gdbserver would need to remain pure C, and likewise any
> code shared between gdbserver and gdb should have to be kept
> as such.  This is important, because we want gdbserver to be usable
> in #1, resource constrained scenarios where the C++ dependency would
> be unacceptable.  We don't want there to need to be other gdbserver-like
> programs specialized for such environments, and gdbserver to be usable only
> on bigger machines.  We want gdbserver to run everywhere.  And #2, the debugger

I agree.  The system configure or capability of embedded devices are
diversiform, from tiny piece of memory to multiple giga-bytes of memory.
 GDBserver fits to low-end devices.  Even nowadays, the size of
GDBserver increases as more functionalities added, we should avoid
GDBserver depends on C++ libraries.

> is one of the first programs that is desirable to get running on a new
> system/board.  Usually you get C going much sooner than C++.
> 

Yes, when building up a system on a board, GDBserver is usually the
"first class" programs to build.

> 
> I'm very wary that introducing C++ will make it increasingly
> difficult to share between the C++ and C parts.  Currently not
> that much is shared between gdb and gdbserver, but it is long desired,
> and in actually in this year's plan to merge gdb's and gdbserver's
> backends (am I am actively working on this.  See
> <http://sourceware.org/gdb/wiki/LocalRemoteFeatureParity>).

Agree.  We have multiple codes to share among GDB and GDBserver, this
will reduce the scope of GDB C++-fication.

> There's also the issue with in-process code, which is also
> desirable to remain as C code.  Latest developments push towards having
> debugger code run _within_ the inferior.  Witness gdbserver's current IPA
> (in-process agent; libinproctrace.so), which has a lot of coupling in its
> implementation (and a lot of code shared), and a bunch of code shared with
> gdbserver.  We can't predict which bits of GDB will we want to be able to
> reuse in GDBserver or an IPA, but I do believe that we will be considering
> it (reuse something more) the future.
> 

As GDBserver and in-process agent becomes more and more powerful (which
is the trend of debugging, IMO), they will share more and more code with
GDB.  For example, when supporting ITSET in GDBserver and in-proc agent,
even the design is not mature, it shows that we need move some bits of
GDB to gdb/common, and share with GDBserver and in-proc agent.

> So all in all, I believe that in a C++ world, GDB's "C++ in C" wouldn't
> really go away; it would end up still being prominent, not as hidden as
> libbfd or other dependencies.  Not hidden enough that we could just
> tuck it under the carpet.  I worry that this actually makes it _worse_
> for new contributers, who will need to learn about GDB's C idiomatic usage,
> and whatever new C++ idiomatic usage GDB would end up with.  With that, and
> the worry about the new source of trouble and bugs and confusion that
> it would be the bridging between the parts written in the different languages,
> I do believe we're better off staying in C land, at least for a couple years more.

In short, I am not against using C++ in GDB.

-- 
Yao (齐尧)

Re: Will therefore GDB utilize C++ or not?

[Yao Qi]

On 04/10/2012 08:22 AM, Yao Qi wrote:
> In short, I am not against using C++ in GDB.

Looks like this sentence is conflict with my words above. :)  I am NOT
against using C++ in GDB, but we should carefully identify the areas to
C++-fy, because they may/will be shared with GDBserver, which is not
C++-fied.

-- 
Yao (齐尧)

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> If you asked me not too long ago, I'd have been strongly in favor
Pedro> of C++.  However, that is no longer the case.  I'm now pending
Pedro> towards "no C++".

First, let me say, thanks for your considered opinion.

I'm sorry it has taken me so long to reply, but various personal events
have made it hard to do so in a more timely way.  Luckily (?) the thread
rages on, so I don't feel too awfully tardy.

Pedro> Indeed, gdbserver would need to remain pure C, and likewise any
Pedro> code shared between gdbserver and gdb should have to be kept
Pedro> as such.  This is important, because we want gdbserver to be usable
Pedro> in #1, resource constrained scenarios where the C++ dependency would
Pedro> be unacceptable.

I found this post to be sensible and I basically agreed with everything
you said -- I'm sort of dog-like and easily swayed by the last thing I
saw -- but on reflection I think the above paragraph is the crux of the
argument, and I am not sure I agree with it.

I think this relies on the idea that the C++ runtime dependency is
unavoidably very heavy.  And, in earlier discussions on the Archer list,
I agreed with this idea without giving it too much thought.

But, that seems to me to be an empirical question.  We could measure the
impact.

This would mean having some criteria for what is acceptable.  I think
that would probably be a good thing to have.  It seems weird that the
current status is that code goes into gdbserver without any sort of
measurement impact -- if resources are an issue, then they should be an
issue generally, not just due to the specter of C++.

Pedro> (On a sidenote: I get the impression from some that C++ would be mostly
Pedro> useful for the stronger static typing, but I can't help finding it in
Pedro> contrast with the simultaneous push of some of GDB functionality towards
Pedro> being implemented in python, with duck typing and all, which people
Pedro> are happy with.

The two programming environments are very different, though; and the
core-versus-extension difference is essential.  One thing I like about
scripting gdb in Python is that I can write quickly -- but also that I
can write lower-quality code without caring about it.

Pedro> One (uninvestigated) idea I had was to take a look at Linux's
Pedro> sparse tool for catching issues like the "offsets" case that led
Pedro> to this thread.)

For the offsets case it might have worked; but in many interesting cases
static analysis (and thus modification) of gdb is just crazily hard,
because gdb is written in such a weird way.  E.g., read the Coverity
reports sometime -- tons and tons of false reports due to cleanups.
Cleanups are hard to even check when you write a tool specifically for
checking them (I did this...).  They are also what will make it very
difficult for us to use the Python refcount checker (we probably just
won't).

Pedro> There's also the issue with in-process code, which is also
Pedro> desirable to remain as C code.  Latest developments push towards
Pedro> having debugger code run _within_ the inferior.  Witness
Pedro> gdbserver's current IPA (in-process agent; libinproctrace.so),
Pedro> which has a lot of coupling in its implementation (and a lot of
Pedro> code shared), and a bunch of code shared with gdbserver.  We
Pedro> can't predict which bits of GDB will we want to be able to reuse
Pedro> in GDBserver or an IPA, but I do believe that we will be
Pedro> considering it (reuse something more) the future.

It seems to me that we must have a licensing issue here.
Can it really be ok to map GPL'd code into any old process?

It seems mildly absurd to me to couple the implementation language
choice of a large, complicated, interactive host-side tool like gdb to
that of an in-process debug agent.

Tom

Re: Can it really be ok to map GPL'd code into any old process?

[John Gilmore]

> It seems to me that we must have a licensing issue here.
> Can it really be ok to map GPL'd code into any old process?

I think you can map it without trouble (just as you can mmap a text
file into a process address space, regardless of its copyright).  Or
GDB can mmap a propriatary executable into its address space in order
to read its symbols, read or patch its object code, or run it in a
simulator.

The problem, if any, is that you can't *link* GPL code to proprietary
code (except system libraries).  FSF took the position (with NeXT)
that you can't even do that dynamically, if your goal is to circumvent
the GPL (which WAS NeXT's goal).

Ultimately it isn't up to FSF to decide what copyright law allows you
to do -- it's the courts that would figure out whether linking or
mmap-ing GPL'd code to proprietary code produces a derived work (and
thus one whose copyright is derived from the copyright on the GPL'd
code).  So far I think it's pretty clear that static linking produces
a derived work.  I don't think the courts have ruled about dynamic
linking.

	John

Re: Can it really be ok to map GPL'd code into any old process?

[Pedro Alves]

On 04/18/2012 09:30 PM, John Gilmore wrote:

>> It seems to me that we must have a licensing issue here.
>> Can it really be ok to map GPL'd code into any old process?


The IPA can also be injected into the target program with LD_PRELOAD.
The user doesn't have to distribute the result, and indeed that would
be shady area.  But I think just using it like that falls into freedom 0.
IANAL, and all that.

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

Tom> I think this relies on the idea that the C++ runtime dependency is
Tom> unavoidably very heavy.  And, in earlier discussions on the Archer list,
Tom> I agreed with this idea without giving it too much thought.

Tom> But, that seems to me to be an empirical question.  We could measure the
Tom> impact.

Today I built gdbserver a number of different ways.
In particular, I applied a few hacks, disabled all warnings, and used
-fpermissive, so that I could build it with g++ as well.

I'm appending my script, I can send the various hacks too if anybody
needs them.  They were trivial though.

Here's the results.  I did all builds on an x86-64 F16 box.  For g++ I
used -static-libstdc++; though it shouldn't pull in very much right now.
I used a trunk gcc from today, since F16 doesn't apparently package
libstdc++.a, but earlier runs with the system compiler were roughly
similar.  I threw in -fexceptions since I was curious what would happen.

    344064 g++ -O2
    331776 gcc -fexceptions -O2
    331776 gcc -O2
    311296 g++ -flto -O2
    303104 g++ -Os
    303104 gcc -flto -fexceptions -O2
    303104 gcc -flto -O2
    290816 gcc -fexceptions -Os
    290816 gcc -Os
    278528 g++ -flto -Os
    270336 gcc -flto -fexceptions -Os
    270336 gcc -flto -Os

First, clearly, if you care about size you should be using -flto -Os.
This is a clear win.  Our default of -O2 is much worse.

Second, g++ induces very little bloat on the current code base.
It is about 3%.

Now, I realize this is not necessarily indicative of the ultimate size
increase.  "Zero-cost" exceptions do in fact have a cost in the size of
the executable.  I failed to easily build an SJLJ compiler, so I didn't
try to do any measurements of this.

This process did discover a bad "return 1" in the middle of
ax.c:gdb_eval_agent_expr.  I think  it should return
expr_eval_unrecognized_opcode.

Tom

#!/bin/sh

for comp in gcc g++; do
    if test $comp = gcc; then
	cc=$comp
	compflags=
    else
	cc='g++ -fpermissive'
	compflags='LDFLAGS=-static-libstdc++'
    fi
    for base in '' -flto; do
	for exc in '' -fexceptions; do
	    if test $comp = g++ && test x$exc = x-fexceptions; then
		continue
	    fi
	    for opts in -O2 -Os; do
		echo ================================================================
		flags=$(echo $base $exc $opts)
		echo ===== $flags
		echo
		make clean-local
		make CC="$cc" CFLAGS="$flags" WARN_CFLAGS= WERROR_CFLAGS= $compflags gdbserver
		f2=$(echo $comp $flags | sed -e 's/ /_/g')
		cp gdbserver gdbserver-$f2
	    done
	done
    done
done

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:

Pedro> This is important, because we want gdbserver to be usable in #1,
Pedro> resource constrained scenarios where the C++ dependency would be
Pedro> unacceptable.

I wonder whether you would reconsider this given the size measurements I
did.

In particular, C++ is something like 3% space overhead today, and that
gdbserver is already ~300K.  I think that size growth is quite
acceptable.

Pedro> We don't want there to need to be other gdbserver-like programs
Pedro> specialized for such environments, and gdbserver to be usable
Pedro> only on bigger machines.  We want gdbserver to run everywhere.

The recent gdb-patches thread from Jonathan Larmour indicates that we
already lost this one.  He was concerned about the use of 2183 bytes.

Pedro> And #2, the debugger is one of the first programs that is
Pedro> desirable to get running on a new system/board.  Usually you get
Pedro> C going much sooner than C++.

I think there are multiple options for this scenario.  People could
start with a basic port of RDA, or an older gdbserver, or just bump up
the priority of getting C++ working.

Tom

Re: Will therefore GDB utilize C++ or not?

[Joel Brobecker]

> Pedro> And #2, the debugger is one of the first programs that is
> Pedro> desirable to get running on a new system/board.  Usually you get
> Pedro> C going much sooner than C++.
> 
> I think there are multiple options for this scenario.  People could
> start with a basic port of RDA, or an older gdbserver, or just bump up
> the priority of getting C++ working.

I would really like us to avoid making GDBserver a C++ program.
I said in the past that I was concerned that making GDB a C++ program
would make it less accessible on the less used platforms. But I am
ready to accept that constraint to build GDB if it can help general
development. For GDBserver, however, which is often cross-compiled
to bare systems, I feel that getting a C++ compiler could be even more
challenging that on those exotic but otherwise relatively rich
platforms.

-- 
Joel

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

Joel> For GDBserver, however, which is often cross-compiled to bare
Joel> systems, I feel that getting a C++ compiler could be even more
Joel> challenging that on those exotic but otherwise relatively rich
Joel> platforms.

Ok.

I think in that case we must drop this idea.

That's too bad, but I guess we will soldier on.

Tom

Re: Will therefore GDB utilize C++ or not?

[Daniel Jacobowitz]

On Fri, May 18, 2012 at 10:17 PM, Tom Tromey <tromey@redhat.com> wrote:
>
> >>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:
>
> Joel> For GDBserver, however, which is often cross-compiled to bare
> Joel> systems, I feel that getting a C++ compiler could be even more
> Joel> challenging that on those exotic but otherwise relatively rich
> Joel> platforms.
>
> Ok.
>
> I think in that case we must drop this idea.

For the record, I stand by my earlier messages in this thread about
code sharing with gdbserver; I think there is plenty of room for a C
gdbserver and a C++ one, and the times when C++ doesn't work on your
target are definitely times when you prefer the simplest possible and
most bulletproof gdbserver.

What I'd really love to see, in C or C++, would be unit testing;
having worked in a unit test intensive environment for the past year,
I think it's a bit nuts that anyone *doesn't*.  It seems to me that
there are better tools for this in C++ than in C, but I have
definitely not done a serious investigation of the options.

--
Thanks,
Daniel

Re: Will therefore GDB utilize C++ or not?

[Joel Brobecker]

> For the record, I stand by my earlier messages in this thread about
> code sharing with gdbserver; I think there is plenty of room for a C
> gdbserver and a C++ one, and the times when C++ doesn't work on your
> target are definitely times when you prefer the simplest possible and
> most bulletproof gdbserver.

I wouldn't mind something like this either. I don't have much of
an idea of what optional features could be better implemented in C++,
though, given the fact that GDBserver is a very small piece of code
as it is... But that's easy to discuss some other day if someone
wants to take that project further.

> What I'd really love to see, in C or C++, would be unit testing;
> having worked in a unit test intensive environment for the past year,
> I think it's a bit nuts that anyone *doesn't*.  It seems to me that
> there are better tools for this in C++ than in C, but I have
> definitely not done a serious investigation of the options.

I agree.  For one thing, it would allow us to test the observers
without have to go through debugging GDB with GDB and make inferior
function calls.

As an aside, I used to work on an Air Traffic Control system,
and did a lot of Unit Testing and Deep Unit Testing. I know
from this experience that this is time and effort well invested,
and I tend to use them for my own projects as well.

-- 
Joel

Re: Will therefore GDB utilize C++ or not?

[Frank Ch. Eigler]

Joel Brobecker <brobecker@adacore.com> writes:

> [...]  GDBserver, however, which is often cross-compiled to bare
> systems, I feel that getting a C++ compiler could be even more
> challenging that on those exotic but otherwise relatively rich
> platforms.

Could y'all embrace a minimal gdbserver for cross-compilation bringup
purposes, instead of holding back relatively rich working platforms?
http://sourceware.org/rda/ et al., maybe connected tighter to the gdb
build system?

- FChE

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 05/18/2012 08:55 PM, Tom Tromey wrote:

>>>>>> "Pedro" == Pedro Alves <palves@redhat.com> writes:
> 
> Pedro> This is important, because we want gdbserver to be usable in #1,
> Pedro> resource constrained scenarios where the C++ dependency would be
> Pedro> unacceptable.
> 
> I wonder whether you would reconsider this given the size measurements I
> did.


Thanks.  I appreciate them.  I didn't expect the code size to grow significantly,
as we had already seem similar comparisons done for gcc in the course of
the various C vs C++ discussions over there with similar results.
However, I'll note that such comparisons assume an unchanged C-style codebase,
and ignore the size increase you get when you actually start using C++
features, such as, throwing exceptions, or using iostream.  In my quick
experiment adding a cout << "foo" (-static-libstdc++ -flto -Os + strip) more
than triples the binary size.

> In particular, C++ is something like 3% space overhead today, and that
> gdbserver is already ~300K.  I think that size growth is quite
> acceptable.
> 
> Pedro> We don't want there to need to be other gdbserver-like programs
> Pedro> specialized for such environments, and gdbserver to be usable
> Pedro> only on bigger machines.  We want gdbserver to run everywhere.
> 
> The recent gdb-patches thread from Jonathan Larmour indicates that we
> already lost this one.  He was concerned about the use of 2183 bytes.


That was for eCos, running on tiny embedded micro-controllers though.

I'm talking about things such as uclinux based routers vs big iron
GNU/Linux mainframes -- having only one codebase to maintain that
has to know ptrace intricasy, for example.

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote:
> In my quick experiment adding a cout << "foo" (-static-libstdc++ -flto -Os
> + strip) more than triples the binary size.

Could you give specific still used device example where the current codebase
is OK while the triple gdbserver size is no longer OK?  All the discussions
are still very abstract.


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[Paul_Koning]

I'm working on a system where the boot device has about a megabyte free space, on a good day.

	paul

On May 21, 2012, at 12:14 PM, Jan Kratochvil wrote:

> On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote:
>> In my quick experiment adding a cout << "foo" (-static-libstdc++ -flto -Os
>> + strip) more than triples the binary size.
> 
> Could you give specific still used device example where the current codebase
> is OK while the triple gdbserver size is no longer OK?  All the discussions
> are still very abstract.
> 
> 
> Thanks,
> Jan

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Mon, 21 May 2012 19:36:57 +0200, Paul_Koning@Dell.com wrote:
> I'm working on a system where the boot device has about a megabyte free
> space, on a good day.

Which arch/os is that (to guess the gdbserver size differences)?  Is some
secondary storage really unavailable?  How much simple gdbserver would be
enough - for example do you need threading in that stage?


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[Paul_Koning]

It's a NetBSD/MIPS64 derivative embedded system.  No other secondary storage for code.  Threading support is needed.  (That doesn't add much.)  I don't currently have multi-inferior support, although I've thought about adding that.

	paul

On May 21, 2012, at 1:57 PM, Jan Kratochvil wrote:

> On Mon, 21 May 2012 19:36:57 +0200, Paul_Koning@Dell.com wrote:
>> I'm working on a system where the boot device has about a megabyte free
>> space, on a good day.
> 
> Which arch/os is that (to guess the gdbserver size differences)?  Is some
> secondary storage really unavailable?  How much simple gdbserver would be
> enough - for example do you need threading in that stage?
> 
> 
> Thanks,
> Jan

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 05/21/2012 05:14 PM, Jan Kratochvil wrote:

> On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote:
>> In my quick experiment adding a cout << "foo" (-static-libstdc++ -flto -Os
>> + strip) more than triples the binary size.
> 
> Could you give specific still used device example where the current codebase
> is OK while the triple gdbserver size is no longer OK?  All the discussions
> are still very abstract.


I should point out that that question is a bit backwards.  If you can
shrink the storage to save costs, you'll do it.  But obviously you won't
shrink more than what necessary to run your software.
That - shrink storage - is the reasoning why e.g., one feature eglibc
has over glibc, is a way to configure out things that may not be needed
on an embedded system.

Google around for OpenWrt or DD-WRT for example, to find configurations
where 4-32MB flash is common.

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

Jan> Could you give specific still used device example where the current
Jan> codebase is OK while the triple gdbserver size is no longer OK?
Jan> All the discussions are still very abstract.

Pedro> I should point out that that question is a bit backwards.  If you can
Pedro> shrink the storage to save costs, you'll do it.  But obviously you won't
Pedro> shrink more than what necessary to run your software.

If size is a critical argument against C++, then it has to be a critical
argument in other cases as well.

I think it is important for us to establish the desirable bounds on the
size of gdbserver, so that we can request this data in future gdbserver
patch reviews.

Tom

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Mon, 21 May 2012 18:52:09 +0200, Pedro Alves wrote:
> But obviously you won't shrink more than what necessary to run your
> software.

Proposed C++ is not a clear win-win, it is a compromise.  I have found this
discussion gives enough reasons (~from Tom) to consider C++ "very important".

The size has some importance but these mails try to decide whether the size
regressions is globally as important as the C++ benefits for GDB or not.

If the size is important enough then there is also the alternative gdbserver
for bootstraps without C++ (older FSF gdbserver, RDA, #ifdef-out-ed HEAD FSF
gdbserver etc.).  It has also various disadvantages but again I consider them
globally less important than the C++ benefits for GDB.


> Google around for OpenWrt or DD-WRT for example, to find configurations
> where 4-32MB flash is common.

This is not the specific enough answer I was asking for.


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[Matt Rice]

On Mon, May 21, 2012 at 9:52 AM, Pedro Alves <palves@redhat.com> wrote:
>
> Google around for OpenWrt or DD-WRT for example, to find configurations
> where 4-32MB flash is common.

FWIW, I have an openwrt install on a 4MB flash, and figuring out how
to find enough space for the existing gdbserver was a pain.
to the point where I just made a ramdisk and copied gdbserver to it
when i needed it (which lucky for me wasn't debugging any issue at
boot time/user space worked enough to get gdbserver to its
destination.)

many of these newer openwrt/dd-wrt systems also have usb they can use
to add additional storage.

that is to say, i think regardless of c/c++ gdbserver is possibly too
big for some of these small but not tiny installations or at least on
the cusp of being so, and getting larger, thus a smaller gdbserver
might be warranted regardless of c/c++

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote:
> However, I'll note that such comparisons assume an unchanged C-style codebase,
> and ignore the size increase you get when you actually start using C++
> features, such as, throwing exceptions, or using iostream.  In my quick
> experiment adding a cout << "foo" (-static-libstdc++ -flto -Os + strip) more
> than triples the binary size.

FSF GDB HEAD plain C build:
x86_64 -Os -flto gcc (GCC) 4.7.1 20120526 (prerelease)
        linux-vdso.so.1 =>  (0x00007fff4b093000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fb835780000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fb8353c8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fb835994000)
-rwxr-xr-x 1 jkratoch jkratoch 265000 May 26 16:05 gdbserver*

After adding that cout I really get ~1.1MB bytes build.  But iostream is not
useful for gdbserver.

With the useful C++ features exploited by
  #include <vector>
  #include <unordered_map>
  #include <string>
  {
    unordered_map<string, string> foo;
    foo["bar"] = "b";
    vector<string> bar;
    try {
      throw 0;
    } catch (int e) {
      bar.push_back(string("bar"));
    }
  }
I get:
x86_64 -Os -flto gcc (GCC) 4.7.1 20120526 (prerelease)
        linux-vdso.so.1 =>  (0x00007fff084b5000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fa35d6e8000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fa35d3e4000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fa35d0e9000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fa35ced4000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fa35cb1c000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa35d8fc000)
-rwxr-xr-x 1 jkratoch jkratoch 285816 May 26 16:50 gdbserver*

With linking statically the additional libraries the C build has not depended
upon:
x86_64 -Os -flto gcc (GCC) 4.7.1 20120526 (prerelease)
        linux-vdso.so.1 =>  (0x00007fffee9ff000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f54fbf07000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f54fbb4f000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f54fc11b000)
-rwxr-xr-x 1 jkratoch jkratoch 453728 May 26 17:22 gdbserver*

453728 vs. 265000 bytes is +71% increase.
It still seems perfectly worth to me for all the discussed C++ benefits for GDB.

(Maybe one could also look for some inadvertent libraries parts brought in.)


On Tue, 22 May 2012 20:03:41 +0200, Paul_Koning@Dell.com wrote:
> > On Mon, 21 May 2012 19:36:57 +0200, Paul_Koning@Dell.com wrote:
> > > I'm working on a system where the boot device has about a megabyte free
> > > space, on a good day.
> It's a NetBSD/MIPS64 derivative embedded system.  No other secondary storage
> for code.

I have used gcc42.fsffrance.org producing:
  gdbserver: ELF 32-bit LSB executable, MIPS, MIPS-I version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), stripped

FSF GDB HEAD plain C build:
mips32 -Os gcc (RAYS 4.3.0-4.rays0) 4.3.1 20080501 (prerelease)
	libdl.so.2 => /lib/libdl.so.2 (0x2aaec000)
	libc.so.6 => /lib/libc.so.6 (0x2ab00000)
	/lib/ld.so.1 (0x2aaa8000)
-rwxr-xr-x 1 jankratochvil jankratochvil 306092 2012-05-26 05:12 gdbserver*

With the <vector>/<unordered_map>/<string> C++ features I get:
	libdl.so.2 => /lib/libdl.so.2 (0x2aaec000)
	libc.so.6 => /lib/libc.so.6 (0x2ab00000)
	/lib/ld.so.1 (0x2aaa8000)
-rwxr-xr-x 1 jankratochvil jankratochvil 846668 2012-05-26 17:44 gdbserver*

The size increase is primarily due to libm.a, with libm.so I get:
	libdl.so.2 => /lib/libdl.so.2 (0x2aaec000)
	libm.so.6 => /lib/libm.so.6 (0x2ab00000)
	libc.so.6 => /lib/libc.so.6 (0x2ab98000)
	/lib/ld.so.1 (0x2aaa8000)
-rwxr-xr-x 1 jankratochvil jankratochvil 462188 2012-05-26 17:41 gdbserver*

I believe we can get mips under 500KB as libm should not be needed anywhere.


For 64-bit mips64:
When I used CFLAGS="-Os -mips64 -mabi=64" there producing:
  gdbserver: ELF 64-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), for GNU/Linux 2.6.8, dynamically linked (uses shared libs), not stripped
I did not have static 64-bit libstdc++ available on gcc42.fsffrance.org.  I had
some issues building mips64 toolchain and I did not spend too much time on it.
64-bit libstdc++.so would work but it would not provide the size benchmark
numbers here.  64-bit FSF GDB HEAD gdbserver was 289496 bytes (instead of
32-bit 306092) so 64-bit mips build size numbers should not be in disadvantage.



Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[Russell Shaw]

On 27/05/12 01:50, Jan Kratochvil wrote:
> On Mon, 21 May 2012 17:55:47 +0200, Pedro Alves wrote:

...

> 453728 vs. 265000 bytes is +71% increase.
> It still seems perfectly worth to me for all the discussed C++ benefits for GDB.

...

A few of the things i didn't like about C++ have been fixed in the C++11 
standard. In particular, under: Rvalue references and move constructors

<http://en.wikipedia.org/wiki/C%2B%2B11#Rvalue_references_and_move_constructors>

A lot of C++ code was copying objects by value, which means the copy constructor 
had to deep-copy and malloc to make temporaries, only to throw them away later.

That is *slow* and fragments the heap, especially on smaller systems.

With C11, new "move constructors" have been added for copying malloc'd memory to 
avoid that problem.

Parsing C++ has also been improved. <http://en.wikipedia.org/wiki/Most_vexing_parse>

A lot of other improvements too.

I just read the C11 standard (close to final version), and am re-considering the 
use of C++ for smaller microcontrollers.


If gdb is done in C++, run-time performance and bloat should be kept in check by 
avoiding gratuitous use of generalized template libraries. C-like libraries for 
things like bit-sets and symbol tables should work equally as efficient in C++ 
if translated with some superficial C++ syntax.

Hitting my F9 "compile" button would result in an annoying half-second delay 
when compiling simple programs using the STL (years ago when i did C++). Self 
written utility libraries such as those already done in C in gdb could avoid that.

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Sat, 02 Jun 2012 09:01:03 +0200, Russell Shaw wrote:
> Hitting my F9 "compile" button would result in an annoying
> half-second delay when compiling simple programs using the STL
> (years ago when i did C++). Self written utility libraries such as
> those already done in C in gdb could avoid that.

Saving that half-second discourages contributors by using non-standard
libraries for the same basic functionality they already know well from C++.


Regards,
Jan

Re: Will therefore GDB utilize C++ or not?

[Russell Shaw]

On 02/06/12 17:13, Jan Kratochvil wrote:
> On Sat, 02 Jun 2012 09:01:03 +0200, Russell Shaw wrote:
>> Hitting my F9 "compile" button would result in an annoying
>> half-second delay when compiling simple programs using the STL
>> (years ago when i did C++). Self written utility libraries such as
>> those already done in C in gdb could avoid that.
>
> Saving that half-second discourages contributors by using non-standard
> libraries for the same basic functionality they already know well from C++.

A friend said when he was using the full STL, the delay was 8 seconds.

It's completely intolerable when one is used to incremental 
editing/compiling/running with instant C compilations.

Wouldn't there be far more existing GDB contributors that would understand 
C++'ified gdb libraries, than C++ coders that know anything about the internals 
of gdb?

General STL libraries could be ok to a degree, where there is little performance 
or resource impact, and where it simplifies current code.

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Sat, 02 Jun 2012 12:47:22 +0200, Russell Shaw wrote:
> A friend said when he was using the full STL, the delay was 8 seconds.

This is too vague claim.  Which hardware he used?  Why was full STL used by
a single CU?  Was he using gold?  And its incremental linking?


> Wouldn't there be far more existing GDB contributors that would
> understand C++'ified gdb libraries, than C++ coders that know
> anything about the internals of gdb?

It is a good question, my assumptions sure may be wrong.


Regards,
Jan

Re: Will therefore GDB utilize C++ or not?

[Russell Shaw]

On 02/06/12 21:10, Jan Kratochvil wrote:
> On Sat, 02 Jun 2012 12:47:22 +0200, Russell Shaw wrote:
>> A friend said when he was using the full STL, the delay was 8 seconds.
>
> This is too vague claim.  Which hardware he used?  Why was full STL used by
> a single CU?  Was he using gold?  And its incremental linking?

I don't know. The fact that it can happen is just something to be aware of.

He was using in a mingw or whatever environment on a windows XP box which 
probably doesn't help either.

>> Wouldn't there be far more existing GDB contributors that would
>> understand C++'ified gdb libraries, than C++ coders that know
>> anything about the internals of gdb?
>
> It is a good question, my assumptions sure may be wrong.

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Sat, 02 Jun 2012 13:10:19 +0200, Jan Kratochvil wrote:
> On Sat, 02 Jun 2012 12:47:22 +0200, Russell Shaw wrote:
> > Wouldn't there be far more existing GDB contributors that would
> > understand C++'ified gdb libraries, than C++ coders that know
> > anything about the internals of gdb?
> 
> It is a good question, my assumptions sure may be wrong.

If not clear this is a question about how heavy usage of STL there should be.

There is still worth C++ at least just the fixes of crashes from the GDB
cleanups system.


Regards,
Jan

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
> If you asked me not too long ago, I'd have been strongly in favor
> of C++.  However, that is no longer the case.  I'm now pending
> towards "no C++".

I have re-read now the thread and I have not found any blocker issues left.

Here is a plan that should IMHO satisfy all the requirements stated here.
I did not reply to C++ disagreements which were already well enough replied
here.


Current gdbserver will be also in C++.

For most embedded Linux kernel targets it will be enough to build the standard
fully featured gdbserver with static libstdc++ (making it only ~2x larger).

There will be also separate minimal gdbserver in plain C.  For some very
minimal targets still running Linux kernel but no longer having C++-capable
compiler or having some other problem running C++.  There was stated no
concrete such target but maybe there exists one.  This minimal server has no
need for non-stop/multi-inferior etc., it will be created by stripping down
the current one; but in fact one can be also easily code it from scratch.

libinproctrace.so will remain in C so far.  I do not think this sole reason
should block the GDB + gdbserver move to C++.  In the future I believe it can
move to statically built libstdc++ without problem.  It will never be
supported on the minimal C gdbserver which also is not a problem.


There should be provided a list of systems GDB needs to remain compatible with
and which are available for login directly or which can be at least promptly
regression tested upon request.  As could be seen for example on Solaris
recently the compatibility with a system which GDB is not tested against will
break.  The compatibility is not kept automatically just thanks to the reviews.

Then we can find out the minimal C++ level can be required.  I assume some
-std=c++98 with a bundled subset of Boost should be OK.


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[John Gilmore]

> For most embedded Linux kernel targets it will be enough to build the standard
> fully featured gdbserver with static libstdc++ (making it only ~2x larger).

It becomes ~2x larger for what benefit?

> There will be also separate minimal gdbserver in plain C.
>					...	 This minimal server has no
> need for non-stop/multi-inferior etc., it will be created by stripping down
> the current one; but in fact one can be also easily code it from scratch.

Why in heaven's name would you take working code that's in the release
today, and "strip it down" to be less functional?  What's wrong with
continuing to ship it merely the way it is?

	John

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Thu, 22 Nov 2012 22:42:42 +0100, John Gilmore wrote:
> > For most embedded Linux kernel targets it will be enough to build the standard
> > fully featured gdbserver with static libstdc++ (making it only ~2x larger).
> 
> It becomes ~2x larger for what benefit?

http://sourceware.org/ml/gdb/2012-04/msg00044.html

Specifically the size of code itself is irrelevant.  It may have rather other
disadvantages such as clearly lower compatibility with compilers.  Not that it
would be a problem nowadays on GDB supported platforms.


> > There will be also separate minimal gdbserver in plain C.
> >					...	 This minimal server has no
> > need for non-stop/multi-inferior etc., it will be created by stripping down
> > the current one; but in fact one can be also easily code it from scratch.
> 
> Why in heaven's name would you take working code that's in the release
> today, and "strip it down" to be less functional?  What's wrong with
> continuing to ship it merely the way it is?

Because the advanced features (non-stop/multi-inferior etc.) are still not
fully stable, their require more fixes and extensions.

Coincidentally these features are not required on the very few target
platforms possibly not supporting C++ for gdbserver.

One option is to use existing C gdbserver as is on those few non-C++ target
platforms.  But if anyone tries to use some advanced feature there s/he may
face bugs/incompatibilities in those.  Therefore I believe it is easier for
everyone not to ship broken and unmaintained features at all.

The other option of keeping gdbserver in C faces the problem it could no
longer share significant code parts with gdb.  Problems from such design were
described by Pedro as not feasible:
	http://sourceware.org/ml/gdb/2012-04/msg00063.html


I was always against C++ till and including first years od GDB, this is why
I always preferred GTK with its C++-in-C GObject framework compared to Qt.
The reasons in my case were:
 * Compiler incompatibility, around 2000 C++ across GCC and compilers on
   commercial Unices was not compatible.  AFAIK C++ standardization is now OK
   and also the set of compilers/platforms in use is reduced compared to 2000.
 * Debugging C++ was a problem as GDB did not handle it well.  It has improved
   a lot and besides that the remaining issues will get fixed faster with GDB
   in C++.
 * That "tables of C pointers" as in GObject is good enough replacement for
   C++.  That was a misunderstand what is C++, virtual method table is
   a negligible part of what provides C++ and its STL/Boost libraries.

I do not want to start showing how easier are C constructs when written in
a proper way in C++, one such was already posted here with shared_ptr:
	http://sourceware.org/ml/gdb/2012-11/msg00063.html
	Although that was still overcomplicated to match Pedro's real pointer
	in the former code.  Usually one can keep and pass the variable by
	value (with no shared_ptr) thanks to the move constructor efficiency.

The repeating simple crasher bugs just due to the C++-in-C GDB framework which
is only reviewer checked and not compiler checked is too fragile.  You can
takeover fixing all these annoying crasher bugs like:
	https://bugzilla.redhat.com/show_bug.cgi?id=864575
Fortunately compilers have evolved during the years and what had to be
verified by hand can be now automated by the compiler.  There are still bugs
in the programs but people can spend more time fixing the bugs not caught by
the compiler instead of doing the same what the compiler does automatically.

While not the typical C++ purpose specifically now (again) I push for C++
because I have to upstream the 64-bit inferior offsets/sizes as present in
many patches posted by Siddhesh Poyarekar <siddhesh@redhat.com>.  After almost
the year of work we/I can start again as there no way for easy refactorization
of C code.  splint or compiler warnings were shown as incomplete for that
purpose, fixing very every '-Wconversion -Wno-sign-conversion' warning is many
times more expensive (than fixing just the cases requested to be fixed).
With C++ one can provide container classes for the numerical types and catch
just the operations violating the type width safety.
	#include <stdlib.h>
	class Type64 {
	private:
	  int64_t v;
	  operator int32_t () { abort (); } // error
	public:
	  operator int64_t () { return v; }
	  int64_t get () { return v; }
	  Type64() {}
	  Type64(int64_t i) { v = i; }
	  Type64& operator = (const Type64 &rhs) { v = rhs.v; return *this; }
	  Type64& operator ++ () { ++v; return *this; }
	  Type64 operator ++ (int) { Type64 retval(*this); ++v; return retval; }
	  Type64 operator += (const Type64 &rhs) { v += rhs.v; return *this; }
	};
	int main () {
	  Type64 v64 = 0;
	  v64++;
	  ++v64;
	  v64 += 2;
	  int error = v64; // error: ‘Type64::operator int32_t()’ is private
	  return v64.get (); // safe explicit request for width violation
	}


Jan

Re: Will therefore GDB utilize C++ or not?

[Stan Shebs]

On 11/22/12 10:46 AM, Jan Kratochvil wrote:
> On Mon, 09 Apr 2012 20:41:31 +0200, Pedro Alves wrote:
>> If you asked me not too long ago, I'd have been strongly in favor
>> of C++.  However, that is no longer the case.  I'm now pending
>> towards "no C++".
> I have re-read now the thread and I have not found any blocker issues left.
>
> Here is a plan that should IMHO satisfy all the requirements stated here.
> I did not reply to C++ disagreements which were already well enough replied
> here.
>
>
> Current gdbserver will be also in C++.
>
> For most embedded Linux kernel targets it will be enough to build the standard
> fully featured gdbserver with static libstdc++ (making it only ~2x larger).
>
> There will be also separate minimal gdbserver in plain C.  For some very
> minimal targets still running Linux kernel but no longer having C++-capable
> compiler or having some other problem running C++.  There was stated no
> concrete such target but maybe there exists one.  This minimal server has no
> need for non-stop/multi-inferior etc., it will be created by stripping down
> the current one; but in fact one can be also easily code it from scratch.
>

I think for this it should be sufficient to announce an end-of-C point 
for gdbserver, tag it, and record it on a web page; while it's certainly 
possible that someone in the future will have need for a C-only 
gdbserver, I think the chances are vanishingly small, and we shouldn't 
be using up too many brain cycles designing it.

People that are space-conscious are already using their own stubs or 
forked versions of gdbserver.  I note for instance that we nearly 
doubled the size of gdbserver's code when we added target-side 
tracepoint bits a couple years ago, and I don't recall any grousing 
about it getting too big then.  In a world where mega-programs like 
Firefox fit easily onto a cell phone *now*, I'm not just seeing that any 
future projects are going to be so tightly constrained that gdbserver 
size is noticeable.

Stan
stan@codesourcery.com

Re: Will therefore GDB utilize C++ or not?

[Paul_Koning]

On Nov 26, 2012, at 8:29 PM, Stan Shebs wrote:
> ...
> People that are space-conscious are already using their own stubs or forked versions of gdbserver.  I note for instance that we nearly doubled the size of gdbserver's code when we added target-side tracepoint bits a couple years ago, and I don't recall any grousing about it getting too big then.  In a world where mega-programs like Firefox fit easily onto a cell phone *now*, I'm not just seeing that any future projects are going to be so tightly constrained that gdbserver size is noticeable.
> 
> Stan
> stan@codesourcery.com

I guess I have to keep repeating it: multi-gigabyte cell phones are NOT examples of space constrained embedded systems.  I'm working on an embedded system that's physically much larger but has only 64 MB for the program store, and only a gigabyte of memory -- of which only 128 MB is available for the OS and user mode processes.

Yes, the stock gdbserver as delivered with GBD 7 is acceptable.  No, doubling it in size is not something you can just casually propose and assume no one will object.

And I know from previous discussions that the system I'm talking about is nowhere near the most space constrained of embedded systems under active development.  So can we please stop this silly assumption that everyone has gigabytes to spare?

Yes of course, if the GDB project starts to operate on the basis that space is no object, I can and will fork.  But isn't the whole point of open source projects that, while forking is of course allowed, it isn't something to be pushed as the best way to use the project?  If forking was such a wonderful thing, we'd still have EGCS.

	paul

Re: Will therefore GDB utilize C++ or not?

[Stan Shebs]

On 11/26/12 6:02 PM, Paul_Koning@Dell.com wrote:
> On Nov 26, 2012, at 8:29 PM, Stan Shebs wrote:
>> ...
>> People that are space-conscious are already using their own stubs or forked versions of gdbserver.  I note for instance that we nearly doubled the size of gdbserver's code when we added target-side tracepoint bits a couple years ago, and I don't recall any grousing about it getting too big then.  In a world where mega-programs like Firefox fit easily onto a cell phone *now*, I'm not just seeing that any future projects are going to be so tightly constrained that gdbserver size is noticeable.
>>
>> Stan
>> stan@codesourcery.com
> I guess I have to keep repeating it: multi-gigabyte cell phones are NOT examples of space constrained embedded systems.  I'm working on an embedded system that's physically much larger but has only 64 MB for the program store, and only a gigabyte of memory -- of which only 128 MB is available for the OS and user mode processes.
>
> Yes, the stock gdbserver as delivered with GBD 7 is acceptable.  No, doubling it in size is not something you can just casually propose and assume no one will object.
>
> And I know from previous discussions that the system I'm talking about is nowhere near the most space constrained of embedded systems under active development.  So can we please stop this silly assumption that everyone has gigabytes to spare?

:-)

>
> Yes of course, if the GDB project starts to operate on the basis that space is no object, I can and will fork.  But isn't the whole point of open source projects that, while forking is of course allowed, it isn't something to be pushed as the best way to use the project?  If forking was such a wonderful thing, we'd still have EGCS.
>
> 	paul
>

The flipside is that you're potentially making everybody else work 
harder for your sake.  If you're the only one with a space-constrained 
target using stock gdbserver, then it might make more sense to look into 
tweaking a C++ gdbserver to stay under the size you require.  For 
instance, when we discussed this before, 300K was OK for space, so 
presumably 600K is not good - perhaps just conditionalize the tracepoint 
bits to compensate for the space lost to C++ runtime?

It's always seemed a little sloppy to me that we advertise gdbserver as 
suitable for targets, but don't actually track its size, consider each 
patch's effect, etc.  For instance, a one-liner that brings in a bunch 
of library code might be more problematic for footprint than a page of 
new code.

Stan
stan@codesourcery.com

Re: Will therefore GDB utilize C++ or not?

[Paul_Koning]

On Nov 26, 2012, at 9:59 PM, Stan Shebs wrote:

> ...
> The flipside is that you're potentially making everybody else work harder for your sake.  If you're the only one with a space-constrained target using stock gdbserver, then it might make more sense to look into tweaking a C++ gdbserver to stay under the size you require.  For instance, when we discussed this before, 300K was OK for space, so presumably 600K is not good - perhaps just conditionalize the tracepoint bits to compensate for the space lost to C++ runtime?

That's a fair point.  If C++ makes gdbserver more maintainable or easier to improve, and those benefits outweigh the cost of dealing with space pressure for people who have it, that's a valid way to decide.  Given how C++ is "designed" it's not necessarily obvious that switching to it is a good thing, never mind that it brings benefits that outweigh the size costs, but I'll concede the possibility.

What concerned me was what seemed to be an assertion that space pressure doesn't exist.  It does and it's real, but it is indeed one factor in a set of factors that need to be traded off.
> 
> It's always seemed a little sloppy to me that we advertise gdbserver as suitable for targets, but don't actually track its size, consider each patch's effect, etc.  For instance, a one-liner that brings in a bunch of library code might be more problematic for footprint than a page of new code.

That's a very good point.

	paul

Re: Will therefore GDB utilize C++ or not?

[Tom Tromey]

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

Stan> It's always seemed a little sloppy to me that we advertise gdbserver
Stan> as suitable for targets, but don't actually track its size, consider
Stan> each patch's effect, etc.  For instance, a one-liner that brings in a
Stan> bunch of library code might be more problematic for footprint than a
Stan> page of new code.

Yeah, this was my main takeaway from the last round of C++ discussions.

If we are serious about gdbserver size, then we must set some
constraints, and reject patches that violate these.

However, I tend to think that either some interested party will have to
design a compile-time-configuration approach for gdbserver, so that its
size can be kept in check; or that we'll want to have two reference
gdbservers, and let the current one grow feature-by-feature.

There's always RDA:

    http://sourceware.org/rda/

Maybe there are others as well.

Tom

Re: Will therefore GDB utilize C++ or not?

[Stan Shebs]

On 4/4/12 1:47 PM, Tom Tromey wrote:
>
> At the GCC Summit, I once again brought up the perennial idea of
> moving GDB to be implemented in C++.  There, we agreed that as a
> follow-on to that discussion that I would raise the topic among the
> GDB maintainers, and in particular present my migration plan.

I support this plan.

Many of the existing poor-cousin bits of infrastructure date back to a 
time when C++ was not a viable candidate for a widely-available tool, 
and others, more recent, are conscious imitations of C++ capabilities.  
At this point it starts to look a little perverse that we are doing a 
half-million-line program in C.

The changes will be low-impact, perhaps even less visible than the 
K&R/ANSI C compatibility hacks that we maintained for so long.

A secondary benefit will be that it opens up the use of minor C++ 
features, without getting us into the C90-vs-99 dilemma that has kept us 
from taking advantage of those.

>
> I don't believe we should convert all of GDB to C++.  In particular I
> think gdbserver should remain as pure C, and likewise any code shared
> between gdbserver and gdb should be kept as such.

I don't know that it matters that much for GDBserver anymore.  When 
giant C++ apps like Firefox are running on handheld devices, it's a 
little hard to see that a handful of C++ library functions and and EH 
data section in GDBserver are going to make it or break it on targets 
that people are developing for today.  Plus I note that GDBserver is 
picking up a load of functionality, and the truly space-conscious are 
better-advised to build a custom stub that is stripped down to just the 
bits they're going to use.


Stan

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 04/10/2012 12:23 AM, Stan Shebs wrote:

> On 4/4/12 1:47 PM, Tom Tromey wrote:
>> I don't believe we should convert all of GDB to C++.  In particular I
>> think gdbserver should remain as pure C, and likewise any code shared
>> between gdbserver and gdb should be kept as such.
> 
> I don't know that it matters that much for GDBserver anymore.  When giant C++ apps like Firefox are running on handheld devices, it's a little hard to see that a handful of C++ library functions and and EH data section in GDBserver are going to make it or break it on targets that people are developing for today.  


You're forgetting about all those uclibc (and musl's and other libc's of the world) targets
that most probably don't even have a display, and some which don't support C++, and that
still need to be debugged.  A debugger agent is a system component that
should aim lower than a bloated browser.  Again, even the Android NDK doesn't support
C++ exceptions properly (or maybe it does nowadays, but it didn't only a couple years ago),
one of the biggest justifications for a C++ move.

> Plus I note that GDBserver is picking up a load of functionality, and the truly space-conscious are better-advised to build a custom stub that is stripped down to just the bits they're going to use.

If that's a concern, we can make the load of functionality build time optional.  Heck, the Linux kernel
can scale from tiny machines to the super computers of the world that way (and that no doubt
contributes very much to its ever-growing ubiquitousness).  I see no reason gdbserver can't.

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Stan Shebs]

On 4/18/12 7:21 AM, Pedro Alves wrote:
> On 04/10/2012 12:23 AM, Stan Shebs wrote:
>
>> On 4/4/12 1:47 PM, Tom Tromey wrote:
>>> I don't believe we should convert all of GDB to C++.  In particular I
>>> think gdbserver should remain as pure C, and likewise any code shared
>>> between gdbserver and gdb should be kept as such.
>> I don't know that it matters that much for GDBserver anymore.  When giant C++ apps like Firefox are running on handheld devices, it's a little hard to see that a handful of C++ library functions and and EH data section in GDBserver are going to make it or break it on targets that people are developing for today.
>
> You're forgetting about all those uclibc (and musl's and other libc's of the world) targets
> that most probably don't even have a display, and some which don't support C++, and that
> still need to be debugged.  A debugger agent is a system component that
> should aim lower than a bloated browser.  Again, even the Android NDK doesn't support
> C++ exceptions properly (or maybe it does nowadays, but it didn't only a couple years ago),
> one of the biggest justifications for a C++ move.
>

I've not forgotten them! :-)  I just wonder what the size numbers are 
really like.  We haven't really had to address GDBserver size before, 
not least because it wasn't getting much attention and people were OK 
with all kinds of functionality simply being left out.

Paul Koning's bit about it being 300K is interesting, that's nearly an 
order of magnitude larger than I would have expected.  But given the way 
our development timeframes operate, we might spend a lot of effort 
getting GDBserver down to 30K, only to find out it didn't really matter 
anymore because even GDB's smallest supported targets have 4G of RAM or 
more.

Without a well-defined size target, and input from C++ mavens about 
minimum overheads, I don't think we can objectively say whether C++ is 
or is not acceptable for GDBserver.

Stan

RE: Will therefore GDB utilize C++ or not?

[Paul_Koning]

-----Original Message-----
From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On Behalf Of Stan Shebs
Sent: Wednesday, April 18, 2012 2:13 PM
To: Pedro Alves
Cc: gdb@sourceware.org
Subject: Re: Will therefore GDB utilize C++ or not?

...
>Paul Koning's bit about it being 300K is interesting, that's nearly an order of magnitude larger than I would have expected.  But given the way our development timeframes operate, we might spend a lot of effort getting GDBserver down to 30K, only to find out it didn't really matter anymore because even GDB's smallest supported targets have 4G of RAM or more.

Note that I was describing a statically linked gdbserver.  If I was willing to have it dynamically linked it would presumably be quite a lot smaller, but that means it won't help me debug problems involving library loading.

	paul

Re: Will therefore GDB utilize C++ or not?

[Pedro Alves]

On 04/18/2012 07:12 PM, Stan Shebs wrote:

> On 4/18/12 7:21 AM, Pedro Alves wrote:
>> On 04/10/2012 12:23 AM, Stan Shebs wrote:
>>
>>> On 4/4/12 1:47 PM, Tom Tromey wrote:
>>>> I don't believe we should convert all of GDB to C++.  In particular I
>>>> think gdbserver should remain as pure C, and likewise any code shared
>>>> between gdbserver and gdb should be kept as such.
>>> I don't know that it matters that much for GDBserver anymore.  When giant C++ apps like Firefox are running on handheld devices, it's a little hard to see that a handful of C++ library functions and and EH data section in GDBserver are going to make it or break it on targets that people are developing for today.
>>
>> You're forgetting about all those uclibc (and musl's and other libc's of the world) targets
>> that most probably don't even have a display, and some which don't support C++, and that
>> still need to be debugged.  A debugger agent is a system component that
>> should aim lower than a bloated browser.  Again, even the Android NDK doesn't support
>> C++ exceptions properly (or maybe it does nowadays, but it didn't only a couple years ago),
>> one of the biggest justifications for a C++ move.
>>
> 
> I've not forgotten them! :-)  I just wonder what the size numbers are really like.  We haven't really had to address GDBserver size before, not least because it wasn't getting much attention and people were OK with all kinds of functionality simply being left out.
> 
> Paul Koning's bit about it being 300K is interesting, that's nearly an order of magnitude larger than I would have expected.  But given the way our development timeframes operate, we might spend a lot of effort getting GDBserver down to 30K, only to find out it didn't really matter anymore because even GDB's smallest supported targets have 4G of RAM or more.
> 
> Without a well-defined size target, and input from C++ mavens about minimum overheads, I don't think we can objectively say whether C++ is or is not acceptable for GDBserver.
> 


There was also the "share code with the IPA" argument.  I don't think making
the IPA a C++ library is a good idea.

-- 
Pedro Alves

Re: Will therefore GDB utilize C++ or not?

[Yao Qi]

On 04/05/2012 04:47 AM, Tom Tromey wrote:
> My concrete transition proposal is:
> 

I went through discussions in this thread, and go back to read Tom's
proposal again.  Get some additional thoughts, maybe, we can start from
something easy and less-controvesy,

> 1. Modify GDB so it can be compiled with -Wc++-compat.
>    This would be the first patch series.  There is already an archer
>    branch for this.
> 

Modify GDB as well as GDBserver/IPA so they can be compiled with
-Wc++-compat.

> 2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is
>    not complete).  This would be the second patch series.
> 

Change to use C++ compiler to compile GDB, GDBserver and IPA.  If this
is too aggressive, we can use C++ compiler to compile GDB and keep C
compiler to compiler GDBserver and IPA.  Sources in gdb/common/ will be
compiled by C compiler and C++ compiler respectively.  Is it possible?

> 3. Require C++.

Then, we can require C++ for GDB and keep GDBserver and IPA unchanged.

> 
> 4. Change selected modules to use C++ rather than C.
>    I don't think a wholesale change makes sense, but some areas would
>    benefit.
> 
>    My first target would be to change the exception handling system to
>    use C++ exceptions.  This would enable us to begin using RAII in
>    some areas, which would help robustness.
> 
>    My concrete plan here is:
> 
>    * Use the GCC cleanup-checking plugin I already wrote to detect
>      cleanup-aware functions.
> 
>    * Modify these functions, using a script, to add an RAII-using
>      object to manage the local cleanups.  This is important so that
>      we run cleanups at the correct time during stack unwinding.
> 
>    * Change throw_exception to use 'throw' and all TRY_EXCEPT
>      instances to try...catch.
> 
>    * Finally, convert functions to static RAII usage when appropriate;
>      this will be an ongoing transition.

Most of the objections are to these points.  We can postpone them, and ....

> 
>    I think our second target will be sorting out Python reference
>    counting, so we can avoid the many problems we have had there.

... start this first, if this is quite isolated and not dependent on #4
above.  Python reference counting will not be used in GDBserver, so we
don't have to worry about GDB/GDBserver code sharing.

-- 
Yao (齐尧)

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Thu, 19 Apr 2012 10:43:51 +0200, Yao Qi wrote:
[...]
> maybe, we can start from something easy and less-controvesy,
> 
> On 04/05/2012 04:47 AM, Tom Tromey wrote:
> > 1. Modify GDB so it can be compiled with -Wc++-compat.
> >    This would be the first patch series.  There is already an archer
> >    branch for this.
> 
> Modify GDB as well as GDBserver/IPA so they can be compiled with
> -Wc++-compat.
> 
> > 2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is
> >    not complete).  This would be the second patch series.
> > 
> 
> Change to use C++ compiler to compile GDB, GDBserver and IPA.  If this
> is too aggressive, we can use C++ compiler to compile GDB and keep C
> compiler to compiler GDBserver and IPA.  Sources in gdb/common/ will be
> compiled by C compiler and C++ compiler respectively.  Is it possible?

For one of the justifications of C++
	http://sourceware.org/ml/gdb/2012-11/msg00070.html
speficially to upstream the 64-bit inferior offsets/sizes as present in many
patches posted by Siddhesh Poyarekar <siddhesh@redhat.com>:

It would be enough to have GDB (neither gdbserver nor IPA) compilable as C++.
Explicit configure option would be required.  It would be used to create the
64-bit offsets patch and then also during nightly regression testing to catch
possible following 64-bit offsets type violations/regressions.


Is it enough plan to justify the -Wc++-compat compatibility step?
That is to update and check-in archer-ratmice-compile-Wc++-compat.


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[Mark Kettenis]

> Date: Tue, 4 Dec 2012 15:17:08 +0100
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> 
> On Thu, 19 Apr 2012 10:43:51 +0200, Yao Qi wrote:
> [...]
> > maybe, we can start from something easy and less-controvesy,
> > 
> > On 04/05/2012 04:47 AM, Tom Tromey wrote:
> > > 1. Modify GDB so it can be compiled with -Wc++-compat.
> > >    This would be the first patch series.  There is already an archer
> > >    branch for this.
> > 
> > Modify GDB as well as GDBserver/IPA so they can be compiled with
> > -Wc++-compat.
> > 
> > > 2. Then, change GDB to compile with a C++ compiler (-Wc++-compat is
> > >    not complete).  This would be the second patch series.
> > > 
> > 
> > Change to use C++ compiler to compile GDB, GDBserver and IPA.  If this
> > is too aggressive, we can use C++ compiler to compile GDB and keep C
> > compiler to compiler GDBserver and IPA.  Sources in gdb/common/ will be
> > compiled by C compiler and C++ compiler respectively.  Is it possible?
> 
> For one of the justifications of C++
> 	http://sourceware.org/ml/gdb/2012-11/msg00070.html
> speficially to upstream the 64-bit inferior offsets/sizes as present in many
> patches posted by Siddhesh Poyarekar <siddhesh@redhat.com>:
> 
> It would be enough to have GDB (neither gdbserver nor IPA) compilable as C++.
> Explicit configure option would be required.  It would be used to create the
> 64-bit offsets patch and then also during nightly regression testing to catch
> possible following 64-bit offsets type violations/regressions.
> 
> 
> Is it enough plan to justify the -Wc++-compat compatibility step?
> That is to update and check-in archer-ratmice-compile-Wc++-compat.

Not without proper review of the changes.  And since my position on
C++ has changed, I'd not really eager to do that.  But if -Wc++-compat
would make you happy, and stop pushing for switching GDB to C++, I'd
be willing to spend some time to help.

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Tue, 04 Dec 2012 15:44:16 +0100, Mark Kettenis wrote:
> > Is it enough plan to justify the -Wc++-compat compatibility step?
> > That is to update and check-in archer-ratmice-compile-Wc++-compat.
> 
> Not without proper review of the changes.  And since my position on
> C++ has changed, I'd not really eager to do that.  But if -Wc++-compat
> would make you happy, and stop pushing for switching GDB to C++,

No matter whether C++ will happen or not -Wc++-compat is already useful
(for the 64-bit offsets upstreaming).  This is why I ask for it on its own.

While -Wc++-compat enables fixing the 64-bit offsets in GDB it is only like
1% (random guess) of GDB bugs fixes C++ enables us to do.  So the decision of
-Wc++-compat is orthogonal to the C++ decision.


> I'd be willing to spend some time to help.

There is hopefully not much help needed, Matt Rice was offering to update
archer-ratmice-compile-Wc++-compat, and I think one can safely verify the
patch is valid (besides some eyes review) also by comparing byte-by-byte the
compiled stripped binaries.


Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[Matt Rice]

On Tue, Dec 4, 2012 at 6:51 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 04 Dec 2012 15:44:16 +0100, Mark Kettenis wrote:
>> > Is it enough plan to justify the -Wc++-compat compatibility step?
>> > That is to update and check-in archer-ratmice-compile-Wc++-compat.
>>
>> Not without proper review of the changes.  And since my position on
>> C++ has changed, I'd not really eager to do that.  But if -Wc++-compat
>> would make you happy, and stop pushing for switching GDB to C++,
>
> No matter whether C++ will happen or not -Wc++-compat is already useful
> (for the 64-bit offsets upstreaming).  This is why I ask for it on its own.
>
> While -Wc++-compat enables fixing the 64-bit offsets in GDB it is only like
> 1% (random guess) of GDB bugs fixes C++ enables us to do.  So the decision of
> -Wc++-compat is orthogonal to the C++ decision.
>
>
>> I'd be willing to spend some time to help.
>
> There is hopefully not much help needed, Matt Rice was offering to update
> archer-ratmice-compile-Wc++-compat, and I think one can safely verify the
> patch is valid (besides some eyes review) also by comparing byte-by-byte the
> compiled stripped binaries.
>

k, will go ahead and get started on this i've always felt we should at
least do -Wc++-compat since when doing the patch originally it did
make apparent at least one bug in gdb.

  If anyone has any particularly large change to an existing source
file, and they'd prefer I postpone work on that file until later
please let me know, it might save work for one of us or the other.

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Thu, 06 Dec 2012 21:39:27 +0100, Matt Rice wrote:
> k, will go ahead and get started on this i've always felt we should at
> least do -Wc++-compat

That would be great, thanks.

In fact I do not see any possible technical reason against -Wc++-compat, it
has no disadvantages (just possibly "needless" many mechanical changes of your
patch).


Jan

Re: Will therefore GDB utilize C++ or not?

[Yao Qi]

On 12/07/2012 04:39 AM, Matt Rice wrote:
>    If anyone has any particularly large change to an existing source
> file, and they'd prefer I postpone work on that file until later
> please let me know, it might save work for one of us or the other.

I have a not-small patch series 'rsp async notification' being reviewed 
recently and hopefully give new version V4 next Monday.  I don't want to 
postpone your work.  How do you change the source tree?  Are you going 
to post patches one by one to fix compilation errors, and finally turn 
-Wc++-compat on in the last step?

-- 
Yao (齐尧)

Re: Will therefore GDB utilize C++ or not?

[Matt Rice]

On Fri, Dec 7, 2012 at 5:24 AM, Yao Qi <yao@codesourcery.com> wrote:
> On 12/07/2012 04:39 AM, Matt Rice wrote:
>>
>>    If anyone has any particularly large change to an existing source
>> file, and they'd prefer I postpone work on that file until later
>> please let me know, it might save work for one of us or the other.
>
>
> I have a not-small patch series 'rsp async notification' being reviewed
> recently and hopefully give new version V4 next Monday.  I don't want to
> postpone your work.

k

>  How do you change the source tree?

I create a git branch for each type of error message which gets
rebased, write some scripts to create a merge branch to test
compilation and run testsuite, and a branch where self-conflicts go
which contains the lines which are covered by more than one error type.

this allows me a certain amount of flexibility as to how patches are
posted I can either do a series on a specific file/glob e.g. post
[1/?? mi/* error message 'foo'] [2/?? mi/* error message 'bar']

or a series error message 'foo' followed by a series for error message
'bar', this I think is easier for mass review, while the other maybe
better if each maintainer prefers to share the burden of review.

as far as the method, I'm doing a simple/stupid pass of 'fix the error
message robotically', introducing nothing new I don't have to, there
will be obvious cases of eyesores, where we may want to introduce new
types for example. we can consider this pass in bringing those to
light, and getting the other obvious changes out of the way. It will
probably be easier for me to just cherry-pick these later, than to
keep them on their own branch.

>  Are you going to
> post patches one by one to fix compilation errors, and finally turn
> -Wc++-compat on in the last step?

yes but I think that there should be a grace period in between
commiting the final patch to fix compilation errors, and comitting the
patch to turn -Wc++-compat on in order to allow target maintainers to
test *-tdep.c and any macro guarded code which may not be covered by
--enable-targets=all on a platform which I do not have access to.

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Tue, 11 Dec 2012 07:25:33 +0100, Matt Rice wrote:
> On Fri, Dec 7, 2012 at 5:24 AM, Yao Qi <yao@codesourcery.com> wrote:
> >  How do you change the source tree?
> 
> I create a git branch for each type of error message which gets
> rebased,

could you provide some small preview of the work?

I would like to prevent the case of 64-bit offsets were weeks/months of work
were invested to find in the end it is not well reviewable==usable.

On archer-ratmice-compile-Wc++-compat where the current trunk is
	b68c4be8e0c1236639c6e5fc98c6894a746dde4e (from 2010)
I have found the last FSF GDB merge was from
	e884cc5b62f170280dd49a35793bb516d95e7d8d
and while trying to /usr/bin/cmp a stripped binary (which does not match)
I have found this change:

-void *
-grow_vect (void *vect, size_t *size, size_t min_size, int element_size)
+void
+grow_vect (gdb_byte **vect, size_t *size, size_t min_size, int element_size)
[...]
-      vect = xrealloc (vect, *size * element_size);
+      *vect = (gdb_byte *) xrealloc (*vect, *size * element_size);
     }
-  return vect;
 }

which while (probably) correct I find it outside of the scope of this branch,
making it more difficult to verify.

BTW I was using ad hoc
	objdump -d --no-show-raw-insn gdb >1
	objdump -d --no-show-raw-insn gdb >2
	/usr/bin/diff -u [12] | vim -
and there
	/^ .*\n .*\n .*\n .*\n .*\n .*\n
to find:
   72e351:      mov    -0x8(%rbp),%rax
-  72e355:      mov    (%rax),%rax
-  72e358:      mov    %rdx,%rsi
-  72e35b:      mov    %rax,%rdi
-  72e35e:      callq  48ead0 <xrealloc>
+  72e355:      mov    %rdx,%rsi
+  72e358:      mov    %rax,%rdi
+  72e35b:      callq  48ead0 <xrealloc>



Thanks,
Jan

Re: Will therefore GDB utilize C++ or not?

[Matt Rice]

On Thu, Dec 13, 2012 at 7:12 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> wrote:
> On Tue, 11 Dec 2012 07:25:33 +0100, Matt Rice wrote:
>> On Fri, Dec 7, 2012 at 5:24 AM, Yao Qi <yao@codesourcery.com> wrote:
>> >  How do you change the source tree?
>>
>> I create a git branch for each type of error message which gets
>> rebased,
>
> could you provide some small preview of the work?
>
> I would like to prevent the case of 64-bit offsets were weeks/months of work
> were invested to find in the end it is not well reviewable==usable.

unfortunately I'm still trying to muster up motivation for this,
I'll post a repository on gitorious when I do manage to get started
since I don't want to litter the archer repo with a ton of branches.

> On archer-ratmice-compile-Wc++-compat where the current trunk is
>         b68c4be8e0c1236639c6e5fc98c6894a746dde4e (from 2010)
> I have found the last FSF GDB merge was from
>         e884cc5b62f170280dd49a35793bb516d95e7d8d
> and while trying to /usr/bin/cmp a stripped binary (which does not match)
> I have found this change:
>
> -void *
> -grow_vect (void *vect, size_t *size, size_t min_size, int element_size)
> +void
> +grow_vect (gdb_byte **vect, size_t *size, size_t min_size, int element_size)
> [...]
> -      vect = xrealloc (vect, *size * element_size);
> +      *vect = (gdb_byte *) xrealloc (*vect, *size * element_size);
>      }
> -  return vect;
>  }
>
> which while (probably) correct I find it outside of the scope of this branch,
> making it more difficult to verify.

This patch came from Joel Brobecker, after discussions on IRC about
the GROW_VECT macro of ada-lang.h
where we needed to add a cast to the (v) = grow_vect() call in the
macro like: (v) (cast) = grow_vect(...).

I believe my initial patch which I still have around added a cast
argument to the macro (which requires updating all callers)
similarly since we're now hard coding gdb_byte in the macro, we could
also just hard code the cast in the macro without updating the
grow_vect function, also forging updating callers (I don't believe it
was called with anything but gdb_byte's in the first place).

this really was the only place that had changes going beyond mundane.
and since ada is his territory I just went with his patch,
though I somewhat prefer adding the cast argument to the
macro/updating callers as it keeps hard coded types out of otherwise
generic code.
I'd rather not do that if it means someone later wants to go back and
deupdate all of the macro callers.

> BTW I was using ad hoc
>         objdump -d --no-show-raw-insn gdb >1
>         objdump -d --no-show-raw-insn gdb >2
>         /usr/bin/diff -u [12] | vim -
> and there
>         /^ .*\n .*\n .*\n .*\n .*\n .*\n
> to find:
>    72e351:      mov    -0x8(%rbp),%rax
> -  72e355:      mov    (%rax),%rax
> -  72e358:      mov    %rdx,%rsi
> -  72e35b:      mov    %rax,%rdi
> -  72e35e:      callq  48ead0 <xrealloc>
> +  72e355:      mov    %rdx,%rsi
> +  72e358:      mov    %rax,%rdi
> +  72e35b:      callq  48ead0 <xrealloc>

good to see that this picked up the change, and more importantly no others.

Re: Will therefore GDB utilize C++ or not?

[Jan Kratochvil]

On Fri, 14 Dec 2012 12:03:24 +0100, Matt Rice wrote:
> unfortunately I'm still trying to muster up motivation for this,

Please tell if you somehow suspend / stop the work.  I have now the fun of
377kB bitpos patch to maintain off-trunk until -Wc++-compat gets done.
So I have more than enough motivation for -Wc++-compat.


> I'll post a repository on gitorious when I do manage to get started
> since I don't want to litter the archer repo with a ton of branches.

I find myself sourceware archer.git a perfect place for it; in fact it has
very many dead branches, it is only important to track the live ones at
	http://sourceware.org/gdb/wiki/ArcherBranchManagement


> this really was the only place that had changes going beyond mundane.
> and since ada is his territory I just went with his patch,

Such patches may be fine but please keep them on a separate add-on branch to
make the review of the main -Wc++-compat patch easy/possible.


> I'd rather not do that if it means someone later wants to go back and
> deupdate all of the macro callers.

From my point of view one should just keep the current macro magic as is.
As - clarifying as unrelated to -Wc++-compat - hopefully in the future GDB may
switch to C++ and it all can be / gets normally (re)implemented in C++ there.


Thanks,
Jan