This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA/RFC] ARM : one-line prologue analysis
- From: Richard Earnshaw <rearnsha at arm dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: Jerome Guitton <guitton at act-europe dot fr>, gdb-patches at sources dot redhat dot com, Richard dot Earnshaw at arm dot com
- Date: Fri, 26 Sep 2003 10:33:07 +0100
- Subject: Re: [RFA/RFC] ARM : one-line prologue analysis
- Organization: ARM Ltd.
- Reply-to: Richard dot Earnshaw at arm dot com
> > for (reg = 0; reg < NUM_REGS; reg++)
> > ! if (cache->saved_regs[reg].addr != -1)
> > cache->saved_regs[reg].addr += cache->prev_sp;
>
> Would trad_frame_addr_p() be better?
>
> Andrew
>
>
I think so. However, arm_scan_prologue (which is run just before this
loop) abuses the .addr field and puts an offset into it. That offset can
be (often is) negative at that point; the loop Jerome is fixing is the one
where that offset is turned back into a real address.
Fortunately, the stack will always be word aligned (your application is
really broken if it isn't), and registers are always at least four bytes
in size, so I don't think it's possible for -1 to ever get written in
there by the code itself.
So approved with Andrew's suggested change.
R.
PS Andrew,
We seem to be horribly overloading and then exposing these special values
in the trad_frame interface. Wouldn't it make more sense to add more
routines to get and update the values, then we can hide the special
meanings entirely (and maybe even change the way they are recorded if we
need to).
R.