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

[Phi Debian <phi dot debian at gmail dot com>]

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