Will GDB be rewritten in C++ (again)

Will GDB be rewritten in C++ (again)

[Phi Debian]

Hi,

Long long time ago (2012 or so) there was a (vivid) discution
regarding a C++ rewrite of GDB.

I stayed away at that time from participating, and ended up to do
other things (still debugger related though).

Now I retrieved some bandwith and consider going back on GDB dev, but
still today I am reluctant with C++

So my question is, does this rewrite of GDB in C++ has been shelved or
is is still going?

For what I see on my distro, the gdb-7.11.1 is still C, so i would
guess that no progress has been done since 2012 ?

PS: Don't flame on C++ vs C, my question is really about the road map
of GDB. If this is pure C I could refresh my mem to contribute, if
going C++ this is fine too, I would simply find other project there
are plenty :)

Cheers,
Phi

Re: Will GDB be rewritten in C++ (again)

[Joel Brobecker]

> So my question is, does this rewrite of GDB in C++ has been shelved or
> is is still going?

Starting with GDB 8.0, building GDB now requires a C++-11 compiler.
With 7.12, it tries to use a C++ compiler by default, but you can
force it back to using a C compiler at configure time.

-- 
Joel

Re: Will GDB be rewritten in C++ (again)

[Phi Debian]

Thanx Joel, I since then built the 8.0 and you right this is all c++
compiled, mangling the all thing in libgdb.a, double checked with
nm(1).

Cheers
Phi

On Wed, Aug 2, 2017 at 4:54 PM, Joel Brobecker <brobecker@adacore.com> wrote:
>> So my question is, does this rewrite of GDB in C++ has been shelved or
>> is is still going?
>
> Starting with GDB 8.0, building GDB now requires a C++-11 compiler.
> With 7.12, it tries to use a C++ compiler by default, but you can
> force it back to using a C compiler at configure time.
>
> --
> Joel

Re: Will GDB be rewritten in C++ (again)

[Yao Qi]

Phi Debian <phi.debian@gmail.com> writes:

> Now I retrieved some bandwith and consider going back on GDB dev, but
> still today I am reluctant with C++
>
> So my question is, does this rewrite of GDB in C++ has been shelved or
> is is still going?

Phi,
We don't _rewrite_ GDB in C++.  As Joel said, GDB requires a C++11
compiler, because we started to use some C++-11 features.  Most of the
code is still written in C, and the code base isn't changed dramatically.

>
> For what I see on my distro, the gdb-7.11.1 is still C, so i would
> guess that no progress has been done since 2012 ?
>
> PS: Don't flame on C++ vs C, my question is really about the road map
> of GDB. If this is pure C I could refresh my mem to contribute, if
> going C++ this is fine too, I would simply find other project there
> are plenty :)

One of the reasons that we move GDB to C++ is to make maintenance and
development easier, not harder.  You should feel easier to write code in
GDB nowadays.

-- 
Yao (齐尧)

Re: Will GDB be rewritten in C++ (again)

[Eli Zaretskii]

> From: Yao Qi <qiyaoltc@gmail.com>
> Cc: "gdb\@sourceware.org" <gdb@sourceware.org>
> Date: Fri, 04 Aug 2017 12:28:33 +0100
> 
> Phi Debian <phi.debian@gmail.com> writes:
> 
> > Now I retrieved some bandwith and consider going back on GDB dev, but
> > still today I am reluctant with C++
> >
> > So my question is, does this rewrite of GDB in C++ has been shelved or
> > is is still going?
> 
> Phi,
> We don't _rewrite_ GDB in C++.

Actually, we do, AFAICT.  I've seen many patch series lately whose
main intent is to C++-ify the codebase.

> Most of the code is still written in C, and the code base isn't
> changed dramatically.

That depends on the definition of "dramatically".  I think changes are
quite significant.

Re: Will GDB be rewritten in C++ (again)

[Phi Debian]

Hi All,

Thank you for your replies.

I am trying to see how I will move.

The fact is that since epoch I was using GDB as a code base for some
things I have never published, i.e my own things. One of them is
having my own TUI not curses based but HPTERM based. HPTERM (like
xterm but understand hp terminal esc sequence) has the ability of
split an hard display in two with a feature called memory lock, the
debugger can then manage and display sources in the memory locked
area, while all the stdio flaw is still directed to the tty, doing a
'windowing' at low cost and at a very low protocal over head (compared
to ddd, or the sloppines of the tui with stdout screwing uo the soruce
area)  My own TUI is so easy to do I just peek poke an a few GDB
function, the main() is mine and my code is C, how to make this happen
with C++ I dunno.

I also leaverage some GDB code to do my own lib, actually more than
GDB I need a libgdb, not the one that has been tried over and over,
but mine, to do programatical debugger, all this assume the code to be
C not C++. A programatic debugger is as debugger that is actually a
lib, and the main() is a C tool linked with the lib and can then
programtically use API's to unwind functions, retrieve args, walk on
the core, access struct/union member in a efficient way i.e C speed.

As another example of the problematic, long time ago I needed to have
a stack unwinder for ia64, the only one existing was C++, i had to
write my own then in C, and frankly there was no reasons this unwinder
was developped in C++ up front. I think I got tons of examples that
way, another that come in mind is the snappy compressor, some linux
kernel crash use this compressor, and the decompressor was written
whence in C++ until someone pest of did it in C, simple and easy,
that's the one I use.

I need stuff like libelf, libdwarf, when I say lib* it could be GDB
code extracted, and if all that is moving to C++ that mean I got to
make it C somewhere.

So I dunno yet where to stand, may be accept the C era is behind me, I
got my time on it, and may be it is time to go apple picking, fishing,
enjoy life :)

I still think there are big big application out there written in C,
linux kernel for instance, and my debugger (not GDB but using some GDB
parts) is aimed at BIG BIG application debbuging, mostly on crash
(core, vmcore) but on live as well, and digging into this huge core is
not doable with GDB, because we are talking here walking on gigantic
data structure, and automate the sorting of it, think for instance a
memory leak in a kernel crash, tons of mblock from various bucket, you
want to load them all (million) and corelate them with other thing to
somewhat figure out the good ones and the leaked ones, etc, this can
not be done by any interperted interaction with GDB, it just don't
scale, so no sial, no pkdump can do that. I do that with C access to
the crash and the processing is done at C speed over the dump.

So no need to say that gdb++ impairs my work.

As for the 'dramatic' level :) i.e the threshold when a C code got to
be moved to C++, I would say that the very basic low level should be C
with C namespace for the one who wants its acessible in C++, and keep
the low level source pure C so extractable for other.

For instance use a lot of the disasm code, I can extract it from the
GDB source get rid of the BFD dependencie and be selfsufficient, with
the C++ move I can't do that anymore. Luckillly this is pretty stable
and I don't see new architecture comming, I see more architecture
dying, so the snapshot of the GDB source at 7.x is good enough, but I
would say the future of hacking inthe GDB get darker :)

I think GDB fall in the trap the "LLVM do it C++ they must my right..."

May be (I am not in the GDB internals) so may be GDB C++ is need for
doing C++ debugging ?, so for the good old C that it is still in use,
may be a lighter debugger (CDB?) forked from GDB7.x could be good
enough, because may be C will not evolve much, and then the CDB would
be easy to maintain, i.e backporting some stuff from GDB++ like say
ptrace() update could be easy to do.

Well I will give it some toughts.

Cheers,
Phi