Problem with signal handling on itanium

Problem with signal handling on itanium

Post by Bren » Sun, 15 Oct 2006 06:36:55


'm having problems handling SIGSEGV and SIGILL on Linux 2.6/Itanium ...
new to Linux, so I'm probably missing something obvious, but the same
program works fine on an AMD processor.

What I'm getting is that my SECOND signal exit doesn't happen, and I
get a core dump instead. I was attempting to figure out which Itanium
registers were readable from user-space by attempting to read each of
them from each processor in my system. It takes the SIGILL exit on
each processor for the FIRST instruction that fails, but the SECOND
failure gets me a core dump without getting to the signal handling
routine. On further testing, I found I can take as many SIGILL or
SIGSEGV exits as I want as long as they come from the SAME address
but as soon as I take either from a different address the signal
exit does not happen and I get a core dump instead. I can handle
one SIGILL and one SIGSEGV from different addresses, but the second
of either at a different address nets a core dump.

The program uses the Intel ICC compiler because it needs access to
the Itanium internal registers that are defined within ICC.

Here's the program I'm using to test (badly formatted by my email program).
Anyone have any idea why I'm seeing this behavior? Am I missing something
basic in my understanding of how signal handlers are supposed to work?
(that could easily be the case since I'm a s/390 mainframe programmer who's
pretty well lost trying to learn Linux)

The results I get from this program are three SIGSEGV exits from the first
occurrence of "*(long *)0 = 0;", three SIGILL exits from the first
"__getReg(_IA64_REG_PSR)", and then a core dump from the second instance
of "*(long *)0 = 0;".

On the AMD processor, I get the results I expected ... the program takes
all the SEGV and ILL handler exits and ends normally.



#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
#include <signal.h>
#include <setjmp.h>
#ifdef __ia64
#include <sys/ucontext.h>
#include <ia64intrin.h>
#define BAD_OP __getReg(_IA64_REG_PSR)
#else
#define __USE_GNU
#include <sys/ucontext.h>
#define BAD_OP asm(".byte 0xf,0xff")
#endif

static struct sigaction sa_segv, sa_segv_save, sa_ill, sa_ill_save;
static jmp_buf sigexit_save;
static int ruptcount = 0;
static int rupt_retries = 0;

//----------------------------------------------------------
// signal handler
//----------------------------------------------------------
void signal_handler(int signo, siginfo_t *info, void *ptr)
{
ucontext_t *uc;
printf("SIGNAL signo=%d, info=%p, ptr=%p\n", signo, info, ptr);
printf(" si_signo=%d, si_errno=%d, si_code=%d, si_value=%i, si_addr=%p\n",
info->si_signo, info->si_errno, info->si_code, info->si_value.sival_int, info->si_addr);
uc = (ucontext_t *)ptr;
#ifdef __ia64
struct sigcontext *sc = &uc->uc_mcontext;
printf(" sc_ip=%016lx\n", sc->sc_ip);
#else /* not __ia64 */
mcontext_t *mc = &uc->uc_mcontext;
#if __WORDSIZE == 64
printf(" IP=%016lx\n", mc->gregs[REG_RIP]);
#else
printf(" EIP=%08lx\n", mc->gregs[REG_EIP]);
#endif
#endif

// this mess with the counter is for debugging itanium handlers
// it seems to take any number of ints from the SAME address, but die on a second address
if(++ruptcount > 20) {printf("rupt count %i\n", ruptcount); exit(0); }
 
 
 

1. POSIX signal handling versus traditional signal handling

2. Python 2.3.3 signals, threads & extensions: signal handling problem

Hi,
migrating from good old python 1.5.2 to python 2.3, I have a problem
running a program that features some threads which execute calls to
an extension module.
Problem is that all of a sudden, I cannot stop the program with a keyboard
interrupt any more; the installed signal handler does not seem to receive
the signal at all.
This happens both if I rebuild this extension using python 2.3
headers/library
and if I simply use the old extension (ignoring the API version warnings
:-)

Any hints?
Btw this is a sun sparc solaris 6 box, python 2.3.3.

G
Holger

Der Inhalt dieser E-Mail ist vertraulich. Falls Sie nicht der angegebene
Empfger sind oder falls diese E-Mail irrtlich an Sie adressiert wurde,
verstdigen Sie bitte den Absender sofort und lchen Sie die E-Mail
sodann. Das unerlaubte Kopieren sowie die unbefugte ermittlung sind nicht
gestattet. Die Sicherheit von ermittlungen per E-Mail kann nicht
garantiert werden. Falls Sie eine Bestigung wschen, fordern Sie bitte
den Inhalt der E-Mail als Hardcopy an.

The contents of this e-mail are confidential. If you are not the named
addressee or if this transmission has been addressed to you in error,
please notify the sender immediately and then delete this e-mail. Any
unauthorized copying and transmission is forbidden. E-Mail transmission
cannot be guaranteed to be secure. If verification is required, please
request a hard copy version.

3. Python 2.3.3 signals, threads & extensions: signal handling problem[Resolved]

4. threading and signals - main thread solely responsible for signal handling?

5. Signal handler doesn`t handle any signals while main thread is blocked

6. signal handling and (structured) exception handling

7. Signal handling problem in ruby

8. Signal Handling/Term::ReadLine problem in Perl

9. [tao-users] Problems regarding signal handling

10. exception handling error using aCC on HP-UX 11.23 Itanium

11. Itanium exception handling performance

12. Itanium Experts - Building Itanium 1 systems (parts)?

13. Itanium experts- Building Itanium 1 systems from old parts

14. Itanium vs Itanium 2