sigtramp offset on Linux/Alpha

sigtramp offset on Linux/Alpha

[Bharadwaj Yadavalli]

Hi!

The function long alpha_linux_sigtramp_offset PARAMS ((CORE_ADDR pc))
in gdb/alpha-tdep.c considers the following three instructions
as "signal trampoline":

   bis $30,$30,$16     (0x47de0410)
   addq $31,0x67,$0    (0x43ecf400)
   call_pal callsys    (0x00000083)

A quick look in rt_sigaction.S in 
glibc sources glibc-2.2.2/sysdeps/unix/sysv/linux/alpha/ reveals the 
following code for sigreturn

	.align	5
	.ent	sigreturn
sigreturn:
	.prologue 0
	mov	sp,a0
	ldi	v0,__NR_sigreturn
	callsys
	.end	sigreturn

which assembles as

<sigreturn>:	mov	sp,a0          (0x47fe0410)	
<sigreturn+4>:	lda	v0,103(zero)   (0x201f0067)	
<sigreturn+8>:	callsys                (0x00000083)
<sigreturn+12>:	unop	               (0x2fe00000)

I realize that the second instruction in the version gdb is working
with and that in rt_sigaction.S do the same thing - load an
immediate value into v0 - but their encodings are different.

So, Question 1:

Shouldn't the function alpha_linux_sigtramp_offset() be looking 
for the encoding 0x201f0067 instead of 0x43ecf400 in the second 
instruction?

Further, the "trampoline" for signals with siginfo_t table is different
according to p. 268 of the book "Understanding Linux Kernel". The return
enters at rt_sigreturn instead of sigreturn as far as I understand. The 
existence of rt_sigreturn seems to indicate the same. 

So, Question 2:

Shouldn't gdb be checking for the pc to be in the chunk as well? 
(Basically difference is in the second instruction).

<rt_sigreturn>:	        mov	sp,a0           (0x47fe0410)
<rt_sigreturn+4>:	lda	v0,351(zero)    (0x201f015f)
<rt_sigreturn+8>:	callsys                 (0x00000083)

Am I missing something that led me to the above question? Thanks 
in advance for any clarifications from folks in the know of the 
internals.

Bharadwaj

Re: sigtramp offset on Linux/Alpha

[Andrew Cagney]

Bharadwaj Yadavalli wrote:

> Am I missing something that led me to the above question? Thanks
> in advance for any clarifications from folks in the know of the
> internals.

You're probably not missing anything.  The only extra thing to do is to
have a quick dig through the Linux kernel / libc source repository and
see if/when the linux code was changed.

I strongly suspect that at some point, GDB and the kernel/libc did match
but since then things have diverged.

	Andrew