Re: C++ exceptions catching through GDB-patched .eh_frame

[Mark Wielaard <mark at klomp dot org>]

On Thu, 2008-12-11 at 12:20 +0100, Jan Kratochvil wrote:
> >> Unfortunately GDB would have to patch the existing in-memory .eh_frame
> 
> This may be tricky as GDB must not break other .eh_frames possibly sharing the
> same CIE being patched.  Multiple hacks may be possible, not aware which would
> be most viable.

Another complication might be that if the CIE doesn't yet have a
personality routine, you will need to modify the augmentation string and
adjust the augmentation data length. If so, you will have to move stuff
around to extend the actual augmentation data, which is probably too
much work because that means adjusting almost everything in
the .eh_frame data. This might be a non-issue if for c++ there always is
a personality routine registered already (then you just patch it and
store a lookup table somewhere to map the original address), but I
didn't actually look if it has or hasn't.

On irc Phil and I were discussion the different variants of .debug_frame
(which is always as complete as possible, but might not be available)
and .eh_frame available by default on different architectures and
distros partial or full (fedora always has full .eh_frames done through
-fasynchronous-unwind-info, while for example debian i386 doesn't have
any by default). And Phil asked me to comment on that in this thread.
But I don't believe that is an issue in this case since for c++ there
always at least is the partial .eh_frame available since the runtime
requires it.

Note that the frysk testsuites did contain some tests with binaries
where eh_frame and/or debug_frame were explicitly stripped out. Not
directly relevant for this discussion, but maybe interesting to lift if
you want to check that something at least keeps working with partial
information available (see the funit-stack-* variants in the
frysk-core/Makefile.am that are created through 
objcopy --remove-section).

Cheers,

Mark