This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa?] Add frame_align(); Was: ARM stack alignment on hand called functions
- From: Keith Walker <keith dot walker at arm dot com>
- To: Richard dot Earnshaw at arm dot com, Andreas Schwab <schwab at suse dot de>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Thu, 28 Nov 2002 11:07:11 +0000
- Subject: Re: [rfa?] Add frame_align(); Was: ARM stack alignment on hand called functions
- References: <Your message of "Thu, 28 Nov 2002 11:20:17 +0100." <jer8d65732.fsf@sykes.suse.de>
At 10:40 28/11/2002 +0000, Richard Earnshaw wrote:
> Richard Earnshaw <rearnsha@arm.com> writes:
>
> |> > +/* Ensure that the ARM's stack pointer has the correct alignment
for a
> |> > + new frame. */
> |> > +static CORE_ADDR
> |> > +arm_frame_align (struct gdbarch *gdbarch, CORE_ADDR addr)
> |> > +{
> |> > + return (addr & -16);
> |> > +}
> |>
> |> Yuck, two's complement assumption.
>
> No, -16 is implicitly cast to bfd_vma, which is unsigned, and this
> operation is completely defined independent of the representation of
> signed integers.
Hmm, strictly speaking you are correct. I don't have to like it though,
and it means that the code is heavily dependent on the non-obvious fact
that addr is an unsigned type to get the correct behaviour (if bfd_vma
were to be changed to a signed type then this code would quietly break).
So I'll change my comment to:
Yuck, implicit cast of negative number to unsigned.
I notice that the h8300-tdep.c file defines some macros to do this sort of
rounding ... round_up() and round_down(). As aligning addresses is a
reasonable common thing to do maybe these macros should be moved to a more
generic place and used whenever such rounding is required. It doesn't
fix the implicit cast issue, but would at least make finding where such
alignment occurs easier.
Keith