From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bharadwaj Yadavalli To: gdb@sources.redhat.com Subject: sigtramp offset on Linux/Alpha Date: Tue, 01 May 2001 08:53:00 -0000 Message-id: <200105011553.LAA28731@ives.lkg.dec.com> X-SW-Source: 2001-05/msg00006.html 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 : mov sp,a0 (0x47fe0410) : lda v0,103(zero) (0x201f0067) : callsys (0x00000083) : 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). : mov sp,a0 (0x47fe0410) : lda v0,351(zero) (0x201f015f) : 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