
Very funny, gdb. Ve-ery funny - luu
http://www.yosefk.com/blog/very-funny-gdb-ve-ery-funny.html
======
DannyBee
It'd be nice to know what version of GDB this was.

Years ago, I used to be the C++ maintainer for GDB. By the time I left, things
like doing this on a live process worked about 90% of the time (up from 0%).
It turns out what he's trying to do is harder than one would think, but it
should actually work.

Part of the reason it doesn't really work all that often on coredumps is
because you often need access to vtables, thunk functions (which you could
theoretically execute without a live process in most ABI's, but it doesn't
know this). Depending on the class, there may also be runonce constructors
(for static data and associated guard variables), etc.

~~~
eliasmacpherson
[https://stackoverflow.com/questions/253099/how-do-i-print-
th...](https://stackoverflow.com/questions/253099/how-do-i-print-the-elements-
of-a-c-vector-in-gdb/253101#253101) I _think_ this _might possibly_ work for
the core dump? I don't have time to check now myself...

~~~
eliasmacpherson
Took the time to check and it doesn't work with a core dump. Oh well.

------
dded
In the hw world we debug with waveform viewers (Simvision, DVE, and the like).
You can see the value of any signal at any point in time. Move forward and
backward in time. Search for when a bus switches, or even for when it switches
to a particular value. You can even say "show me all points at which foo ==
16'hdead and bar == 16'hbeef and x is high but y is not 8'h7."

Now I understand it's a different problem, but sometimes I think you sw guys
live in the dark ages.

~~~
moron4hire
Oh come on. HW developers don't even use source control.

~~~
dded
Well, things have improved a lot, but there's way more truth in what you say
than there should be.

------
hansjorg
> There is this crazy effort underway to make every linux process
> serializable: allow not only memory be [un]dumped but all open file
> descriptors status (including bringing socked in the same mode) and other
> environment too.

Anyone got any pointers on this?

~~~
phaker
This is called application or process checkpointing. There are/were lots of
attempts to get it working under linux, some are more some less complete. It
was a hot topic several years ago, but the interest sort of fizzled out since
then because virtual machines sovle the same problem. A vm has more overhead
but freezing a vm is also much more reliable.

This wikipedia article mentions few approaches:
[http://en.wikipedia.org/wiki/Application_checkpointing](http://en.wikipedia.org/wiki/Application_checkpointing)

This page has many more projects, though most are probably dead by now:
[http://checkpointing.org/](http://checkpointing.org/)

Both are incomplete, googling "linux checkpointing" returns things not
mentioned in either, like
[https://ckpt.wiki.kernel.org/index.php/Main_Page](https://ckpt.wiki.kernel.org/index.php/Main_Page)

~~~
jevinskie
Yep, this is very important for grid computing where a user may log into an
organization's workstation and the grid job running on the workstation needs
to be evicted. With process checkpointing, you can resume the work later
(perhaps even on another node). Without it, all of the intermediate progress
is discarded.

------
haberman
> still-not-boundary-checked [...] std::vector

Huh? vector::at() is boundary-checked. So you can choose whether you want to
pay for boundary-checking or not.

~~~
roel_v
You can't switch between .at() and [] between two builds. There is a lot to be
said about MSVC's checked iterators, but it sure does catch a lot of mistakes
during debug builds. Any sane STL implementation should have something
similar.

~~~
sltkr
FYI, with libstdc++ (GCC) you can define _GLIBCXX_DEBUG and get a lot of
runtime checks too, including bounds checking on vectors.

[http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch30s...](http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt12ch30s04.html)

------
mappu
_> Nobody's holding a gnu to your head._

comment reproduced here without further context

~~~
tekacs
I noticed the same and was resisting the urge to post it here. :)

I certainly hope it was intentional. :D

------
exDM69
Yes, GDB can feel a little crappy at times. But on the other hand it is quite
versatile in that it can debug programs written in several different languages
running on several different hw architectures, user space or kernel space,
code running on bare metal or in QEMU, etc and remote debugged over a serial
line or network. All this comes at a price.

GDB can never be as nice as a language specific, graphical point and click
debuggers that some programming environments have which are built in
conjunction with the compiler/interpreter for that language.

And the problem is not only GDB, it's the whole infrastructure that is
involved, binary formats, debug symbols and protocols, binutils, etc. It is
easy to point the finger at GDB but there's only so much that GDB can do in
the environment(s) that it works in.

There's plenty of room for improvement but it's not only GDB that would
require work, it's the entire software ecosystem.

~~~
beefhash
Well, I guess it fits right in with GNU: If it sucks, add more features and
port it to more platforms.

------
stcredzero
From the comments:

 _Debugging std::vector isn 't too bad. You can dig in to the... _

Whenever a programmer says "[X] isn't too bad" this is the possible signature
of an opportunity.

------
pjmlp
Yet, C++ debuggers on Windows and Mac OS X do this since ages.

~~~
Timmmmbob
Yeah this is clearly a problem with gdb, not std::vector. Really gdb is pretty
rubbish and hasn't been improved for many years. LLDB should be much better.

~~~
marcosdumay
That's a "problem" with the compiler, not gdb. Also, the "problem" is that the
compiler actually optimized the code, when ordered to do so, instead of just
pretending it did (like MS tools do when debuging). It's also a very usefull
"problem" to have around.

I really doubt LLDB can discover what code operators execute if the compiler
does not include it at the binary.

~~~
comex
Probably the compiler should both inline it and include a standalone version
when debugging is enabled.

~~~
hdevalence
No, because you need to debug the code you're actually running, not some other
code that's easier to debug.

~~~
comex
I believe we're talking about a function such as std::vector::operator[]. You
wouldn't usually be debugging a particular attempt to access an element of a
vector, you'd have a vector and want to easily see what's in it, using a
debugger-constructed call to the function.

------
pilooch
don't know how others do but I find I have to recompile a program without
optimization flags in order to be able to fully debug a live C++ program.
Understandable but annoying.

~~~
pjmlp
This applies to any language with AOT compilation to native code. There are
lots of optimizations that cannot be properly mapped back to the original
source code.

In most languages compilers are allowed to do whatever they want as long as
the semantic outcome stays the same.

------
JoeAltmaier
Yeah I avoid gdb like the plague. Any other platform, any other debugger. Even
Microsoft VS does better.

~~~
TwoBit
"Even Microsoft VS does it better?" I have yet to see any debugger that's
better than Microsoft's. Their compiler is behind GCC, clang, and others, but
their debugging environment is unmatched.

~~~
seanmcdirmid
JVM code hotswapping is still more feature complete than edit and continue for
managed code, which is still way too conservative to be very useful. It is not
a clear overwhelming win for VS (perhaps it is for native, but I don't work
with C++).

------
tiziano88
"Unices"???

~~~
alextingle
Plural of Unix.

------
GFK_of_xmaspast
"No really, there used to be Unices with a program called undump that did just
that."

Isn't that how they used to build emacs, there was some multistage
bootstrapping procedure that culminated in undump'ing a thing that got turned
into a binary.

~~~
jws
emacs and some of the TeX programs worked that way. Maybe they still do. I
haven't looked at that in a quarter century.

To elaborate: the programs would do all of their initialization and loading of
things that would be used in any run, then dump themselves. The result of
undump was an executable that had already done all of its boilerplate loading
and was ready to process its arguments and inputs. It was bigger, since it had
a bunch of heap stored, but it was better than hammering away on your CPU at 1
million instructions per second.

~~~
eliasmacpherson
That's pretty cool. Is there a way of making a java program do this? The JVM
startup time on a desktop kills me.

~~~
judk
Java Web start or similar. It was called TSR in the DOS world "terminate and
stay resident".

