[PING][PATCH] ARM/Linux: Unwind restart_syscall(2) frames

[PING][PATCH] ARM/Linux: Unwind restart_syscall(2) frames

[Maciej W. Rozycki]

Hi,

 Would anyone please review this patch:

http://sourceware.org/ml/gdb-patches/2009-08/msg00431.html

 Thanks,

  Maciej

Re: [PING][PATCH] ARM/Linux: Unwind restart_syscall(2) frames

[Michael Snyder]

Maciej W. Rozycki wrote:
> Hi,
> 
>  Would anyone please review this patch:
> 
> http://sourceware.org/ml/gdb-patches/2009-08/msg00431.html
> 
>  Thanks,
> 
>   Maciej

Well, I don't see anything glaringly wrong with it...

Richard?

Re: [PING][PATCH] ARM/Linux: Unwind restart_syscall(2) frames

[Richard Earnshaw]

On Fri, 2009-12-18 at 11:32 -0800, Michael Snyder wrote:
> Maciej W. Rozycki wrote:
> > Hi,
> > 
> >  Would anyone please review this patch:
> > 
> > http://sourceware.org/ml/gdb-patches/2009-08/msg00431.html
> > 
> >  Thanks,
> > 
> >   Maciej
> 
> Well, I don't see anything glaringly wrong with it...
> 
> Richard?
> 
> 

It's not code that I'm familiar with, however...

	svc	0x00900000
	ldr	pc, [sp], #12
then

+  trad_frame_set_reg_value (this_cache, ARM_SP_REGNUM, sp + 12);

So why is the stack pointer /incremented/ by 12 at this point (which
deallocates stack) rather than decremented to compensate for the
increment that will follow?  Also, shouldn't the stack allocation be a
multiple of 8 to fully conform to the ABI stack alignment constraints?

What about thumb support?

Finally, do you need different code for Big-endian and BE-8 modes?

R.

Re: [PING][PATCH] ARM/Linux: Unwind restart_syscall(2) frames

[Daniel Jacobowitz]

On Tue, Dec 22, 2009 at 03:28:41PM +0000, Richard Earnshaw wrote:
> It's not code that I'm familiar with, however...
> 
> 	svc	0x00900000
> 	ldr	pc, [sp], #12
> then
> 
> +  trad_frame_set_reg_value (this_cache, ARM_SP_REGNUM, sp + 12);
> 
> So why is the stack pointer /incremented/ by 12 at this point (which
> deallocates stack) rather than decremented to compensate for the
> increment that will follow?  Also, shouldn't the stack allocation be a
> multiple of 8 to fully conform to the ABI stack alignment constraints?

We're before execution of the above trampoline at this point, trying
to compensate for it; that's why the stack goes up, we're simulating
return from the trampoline.  The code sequence was chosen by the
kernel, weird stack alignment and all.

-- 
Daniel Jacobowitz
CodeSourcery