This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa?] Add frame_align(); Was: ARM stack alignment on hand called functions


> Richard Earnshaw <rearnsha@arm.com> writes:
> 
> |> > 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.
> 
> Note that ~0xf is even worse.  If sizeof(int) < sizeof(bfd_vma) then you
> get the wrong value, because ~0xf is _zero_ extended to bfd_vma.

But not if you write

	~(bfd_vma)0xf

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]