This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: C++ exceptions catching through GDB-patched .eh_frame
On Sun, 14 Dec 2008 13:23:59 +0100, Mark Wielaard wrote:
> 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.
I was thinking more about creating a copy of the CIE and point the specific
one FDE to this new CIE. Sure another trick is to find an empty space for
this CIE (but GDB already can allocate strings etc. in the inferior).
But I did not investigate this part much so I rather excluded it before.
> 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.
At least in the sample code I tried there was no personality routine present
for the appropriate FDE.
> 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)
.debug_frame is out of question here. We need a data structure which will be
interpreted by the native inferior libgcc unwinder. libgcc unwinder knows
nothing about .debug_frame.
> 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.
Another point is that we need to do the FDE-modification only in the case
where the libgcc unwinder would unwind above the frame we ran the inferior at
(="current frame"). In such case the current frame must have FDE as otherwise
unwinder would stop the unwinding - as I described in the (first) point (1) in
my mail before.
> 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).
IMO this part of testing is appropriate for backtraces which is the inferior
code not interested in. Here we are interested in the cases where the
inferior must have enough of the .eh_frame infrastructure to run on its own.
Regards,
Jan