This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Add libkvm interface support for NetBSD/i386 and OpenBSD/i386
Date: Sun, 27 Jun 2004 10:38:54 -0700
From: Marcel Moolenaar <marcel@xcllnt.net>
> Defenitely. It should be pretty easy to add unwinders for trap and
> interrupt frames.
In a sense, yes. I needed to add a sniffer in some other context, but
had to tweak the framework a bit to allow me to add the sniffer before
the last sniffer (i.e. the default sniffer). Without that tweak the
default sniffer was tried before mine and since the default sniffer
always takes the frame, mine ended up not being used at all. Not a
big issue, but something that requires a bit of thought and rewrite
to work well in a more dynamic context. In my case the following
hack sufficed:
/* Insert a predicate before the last in the table. */
static void
penultimate_predicate (struct frame_unwind_table *table,
frame_unwind_sniffer_ftype *sniffer)
{
if (table->nr > 0)
{
table->sniffer = xrealloc (table->sniffer, (table->nr + 1)
* sizeof (frame_unwind_sniffer_ftype *));
table->sniffer[table->nr] = table->sniffer[table->nr - 1];
table->sniffer[table->nr - 1] = sniffer;
table->nr++;
}
else
append_predicate(table, sniffer);
}
:)
Hmm. Such a hack shouldn't be necessary. You might need to
re-arrange some of the code a bit though. Take a look at how the
unwinders are handled on i386/amd64.
> Termination of traces is a bit of an issue. If there is a fool-proof
> way to detect the end of a frame-chain, then we should defenitely use
> it. When debugging the kernel you'd probably want to terminate on
> frames that cross the protection boundary between user-space and
> kernel-space.
I think the frame sniffers can help here. However, I don't think GDB
should have all the various and weird sniffers embedded, because they
tend to be highly volatile. For example: some frames are known only
by the bounds of the function and thus can be detected only by the PC.
This can be different for every recompilation of the system to which
it applies (in theory).
In general it requires knowledge that goes beyond the ABI and runtime
specs. and it might be a good idea to off-load this to MI or CLI
clients or provide hooks so that one can easily "plug" these in.
Many of these special cases can be handled by adding unwind
information to the code. The latest gas has directives to make
generating CFI for assembler code much easier.
The same would apply to the unwind library on ia64. It's easy enough
to label a frame with unwind information, but knowing what to do with
such a frame may require more knowledge than what you like the unwind
library to have. Hooks to allow some "external" code to deal with it
would probably be the most flexible solution.
This only makes sense if it is possible to define a sane interface
between GDB and the "external" code. Otherwise keeping things
synchronized becomes a *really big* problem.
Mark