This is the mail archive of the
mailing list for the GDB project.
Re: [RFA] Artifical dwarf2 debug info
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: Michal Ludvig <mludvig at suse dot cz>,GDB Patches <gdb-patches at sources dot redhat dot com>
- Date: Thu, 02 Jan 2003 23:05:37 +0000
- Subject: Re: [RFA] Artifical dwarf2 debug info
- References: <3DFE289B.firstname.lastname@example.org> <20021216193459.GA27215@nevyn.them.org> <3DFE3007.email@example.com> <20021216201117.GA31474@nevyn.them.org> <3DFF185B.firstname.lastname@example.org> <3DFF3353.email@example.com> <20021217151304.GA5778@nevyn.them.org> <3E0057EB.firstname.lastname@example.org> <20021218153733.GA11738@nevyn.them.org> <3E14A709.email@example.com> <20030102211836.GA23173@nevyn.them.org>
Right. That gets removed. Instead that info gets passed to the CFI
code as a `parameter' (perhaphs explicitly, or perhaps implicitly as
part of a member of the CONTEXT object).
On Thu, Jan 02, 2003 at 08:54:33PM +0000, Andrew Cagney wrote:
fde = get_fde_for_addr (context->ra - 1);
> >+ if (fde == NULL)
> >+ fde = guess_generic_fde (context->ra - 1);
> > if (fde == NULL)
> > return;
Just to be clear. The above is the change that I think is wrong.
Instead of this function `guessing' the source of the FDE, the code
needs to be re-structured so that the caller always supplies a
That way a dwarf2 cfi frame can call the above function with an FDE
built from the object files debug info, while an artifical frame can
call it with an artifically created FDE. There is no guessing involved.
Hold a second here; I don't think we're really communicating on what
this change is supposed to do. Look at where that code is: it's in
frame_state_for. Its inputs are a CONTEXT and FS (struct frame_state
*). The first line in your quote is:
fde = get_fde_for_addr (context->ra - 1);
I just don't understand what you mean by "the caller supplies an FDE";
this is where we locate the FDE. The caller's got no business knowing
what an FDE is. This new mechanism is supposed to handled any code
which doesn't have a defined FDE, for which an architecutre-specific
(yes) hook can deduce the appropriate FDE from code inspection.
[`artificial frame' was a poor choice of name - a real frame that uses
artifically created dwarf2 debug info]
These are not "artificial frames". We've got four types of frames that
we've been talking about recently:
- the magical register frame/inner frame
- dummy frames
- sigtramp frames
- "normal" stack frames caused by compiled code calling other
The latter can be further broken down into:
dwarf2 fde / cfi frames
artifical fde / cfi frames
Maybe there will be others, but notice that all the above are
Why was the dwarf2cfi code even called? Since there is no dwarf2 cfi
that code path should not have been reached. Per my comment below, this
would have happend because the caller (or something up the stack) failed
to check for an edge condition. That change is patching things up after
conceptually different kinds of things. These "artifical" frames are
just normal frames, where we synthesize the debug information because
we didn't have any. It's a mechanism to coalesce things like prologue
readers. It is absolutely not a new type of frame.
That's why I think this code is in exactly the right place, right now.
Are you saying that the CFI code should just be returning, saying "no
idea, go away, don't talk to me", and leaving this be?
Instead, during `struct frame_info' creation, if there isn't any dwarf2
info, and the architecture really wants to use the dwarf2cfi logic, it
should create an `artifical fde / cfi frame' that first fakes up the FDE
info and then supplies that to the dwarf2cfi logic. Similarly, a dwarf2
cfi frame can first read the fde and then call the relevant code.
> That's all well
> and good but that way we end up duplicating the whole of the CFI
> reader. A good long term direction, with appropriate code factoring,
> but it's hardly practical.
How does this result in the duplication of the CFI reader?
Right. And init_frame_pc_default() is, again, typical of the problem.
It shouldn't need to refer to frame->next.
This is part of a long standing problem - it predates dwarf2cf by many
years. Instead of using recursion, people modify debug/target dependent
frame code so that it attempts to directly handle all cases. Cf all the
PC_IN_CALL_DUMMY(frame->next), PC_IN_SIGTRAMP(frame->next) and other
tests scattered through out the -tdep.c code; and the calls to
get_next_frame() in dwarf2cfi.c.
The one call to get_next_frame, which parallels init_frame_pc_default.