Re: [rfc] trad-frame change

Daniel Jacobowitz
2004-03-03T16:49:34Z

On Wed, Mar 03, 2004 at 11:43:20AM -0500, Andrew Cagney wrote:
> Think of this as a pseudo patch.
>
> I'm looking to extend the trad-frame code so that it includes the interface:
>
> trad_frame_append (gdbarch, frame_type, frame_sniffer, frame_cache);
>
> This would do all the housekeeping necessary to create a FRAME_TYPE
> unwinder implemented with FRAME_SNIFFER and FRAME_CACHE functions. The
> second function would have the interface:
>
> struct trad_frame_cache
> {
> struct frame_id this_id;
> CORE_ADDR this_base;
> struct trad_frame *saved_regs;
> };
>
> void frame_cache (struct frame_info *next_frame, struct
> trad_frame_cache *this_cache);
>
> and would be called _once_ to populate the entire trad-frame cache.
> After that frame ID and register requests would be handled directly.
>
> My rationale is simple. Having just churned out unwinders for two
> architectures I'm seeing a pattern that suggests this would make life
> easier:

Sounds pretty nice to me. For what it's worth, I'm testing a sigtramp
unwinder on MIPS/Linux that could almost but not quite use this:

+struct mips_prologue_cache
+{
+ /* The stack pointer at the time this frame was created; i.e. the
+ caller's stack pointer when this function was called. It is used
+ to identify this frame. */
+ CORE_ADDR prev_sp;
+
+ CORE_ADDR tramp_start;
+
+ int kind;
+
+ /* Saved register offsets. */
+ struct trad_frame_saved_reg *saved_regs;
+};

(so that the frame ID is constant for both instructions of the
trampoline).

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer