Hi Ivan, > "system in development" is the one which suits > Linux/E2k better. The port to E2K (MCST Elbrus general purpose hardware > architecture) is quite mature, but not yet released publicly.
Thanks for the info. Based on it, I found a couple of other pointers as well: [1][2]. > As for the SIGILL peculiarity, it has a reason in the Elbrus architecture. > ... > And it's not a segmentation fault. I believe you should make it signal a SIGSEGV or SIGBUS, not SIGILL, for the following reasons: * Look at the second table in http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/signal.h.html. It defines a couple of signal codes for SIGILL, SIGSEGV, and SIGBUS. It implies that SIGILL means an invalid instruction (and "illegal operand" means an invalid operand that is in the instruction stream). Whereas SIGSEGV and SIGBUS mean a problem with an instruction in combination with a memory address. * The main users of SIGSEGV and SIGBUS are catching stack overflow, garbage collection, and similar (e.g. by use of GNU libsigsegv). The fact that you observe an incompatibility between your Linux adaptation and application programs that work fine across Linux/BSD/AIX/Solaris is a sure indication that you will encounter similar incompatibilities along the lines, until you fix that port, to produce SIGSEGV or SIGBUS instead of SIGILL. > But wait, while writing this explanation, I seem to have come to see a way > how the code in test-c-stack.c: > > ++*argv[argc]; /* Intentionally dereference NULL. */ > > could be rewritten to cause the intended SIGSEGV and not SIGILL like now: If you get SIGSEGV in one case (write to the memory location), you should also get SIGSEGV in the other case (read from the memory location). > AFAIU, a different protection mechanism comes into play here. It is based > on tagging values/memory: if an attempt is made to use a value in a way > which contradicts its tag, then the "illegal operand" condition arises. This reminds the segmented architectures, such as the ones used by AIX and Linux/ia64. In these OSes, SIGSEGV is produced when a memory address is used that does not fit with the instruction. Bruno [1] https://linux.slashdot.org/story/99/03/31/2324218/linus-will-move-to-moscow-to-work-with-elbrus [2] http://elbrus2k.wikidot.com/elbrus-operating-system
