bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH] test-c-stack2.sh: skip if the platform sent SIGILL on an


From: Bruno Haible
Subject: Re: [RFC PATCH] test-c-stack2.sh: skip if the platform sent SIGILL on an invalid address.
Date: Sat, 29 Dec 2018 12:17:32 +0100
User-agent: KMail/5.1.3 (Linux/4.4.0-141-generic; KDE/5.18.0; x86_64; ; )

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]