[Question]
  [
# Background
We already have a challenge [about throwing SIGSEGV](https://codegolf.stackexchange.com/questions/4399/shortest-code-that-return-sigsegv), so why not a challenge about throwing SIGILL?
# What is SIGILL?
SIGILL is the signal for an illegal instruction at the processor, which happens very rarely. The default action after receiving SIGILL is terminating the program and writing a core dump. The signal ID of SIGILL is 4. You encounter SIGILL very rarely, and I have absolutely no idea how to generate it in your code except via `sudo kill -s 4 <pid>`. 
# Rules
You will have root in your programs, but if you don't want to for any reasons, you may also use a normal user. I'm on a Linux computer with German locale and I do not know the English text which is displayed after catching SIGILL, but I think it's something like 'Illegal instruction'. The shortest program which throws SIGILL wins. 
  
[Answer]
# PDP-11 Assembler (UNIX Sixth Edition), 1 byte
```
9
```
Instruction 9 is not a valid instruction on the PDP-11 (in octal, it would be `000011`, which does not appear on [the list of instructions](http://www.cdf.toronto.edu/%7Eajr/258/pdp11.pdf) (PDF)). The PDP-11 assembler that ships with UNIX Sixth Edition apparently echoes everything it doesn't understand into the file directly; in this case, 9 is a number, so it generates a literal instruction 9. It also has the odd property (unusual in assembly languages nowadays) that files start running from the start, so we don't need any declarations to make the program work.
You can test out the program using [this emulator](http://pdp11.aiju.de/), although you'll have to fight with it somewhat to input the program.
Here's how things end up once you've figured out how to use the filesystem, the editor, the terminal, and similar things that you thought you already knew how to use:
```
% a.out
Illegal instruction -- Core dumped
```
I've confirmed with the documentation that this is a genuine `SIGILL` signal (and it even had the same signal number, 4, all the way back then!)
[Answer]
# C (x86\_64, [tcc](http://savannah.nongnu.org/projects/tinycc)), 7 bytes
```
main=6;
```
Inspired by [this answer](https://codegolf.stackexchange.com/a/100540/12012).
[Try it online!](https://tio.run/##S9YtSU7@/z83MTPP1sz6/38A "C (tcc) – Try It Online")
### How it works
The generated assembly looks like this.
```
    .globl  main
main:
    .long 6
```
Note that TCC doesn't place the defined "function" in a *data* segment.
After compilation, *\_start* will point to *main* as usual. When the resulting program is executed, it expects code in *main* and finds the little-endian(!) 32-bit integer **6**, which is encoded as **0x06 0x00 0x00 0x00**. The first byte – **0x06** – is an invalid opcode, so the program terminates with *SIGILL*.
---
# C (x86\_64, [gcc](https://gcc.gnu.org/)), 13 bytes
```
const main=6;
```
[Try it online!](https://tio.run/##S9ZNT07@/z85P6@4RCE3MTPP1sz6/38A "C (gcc) – Try It Online")
### How it works
Without the *const* modifier, the generated assembly looks like this.
```
    .globl  main
    .data
main:
    .long   6
    .section    .note.GNU-stack,"",@progbits
```
GCC's linker treats the last line as a hint that the generated object does not require an executable stack. Since *main* is explicitly placed in a *data* section, the opcode it contains isn't executable, so the program terminates will *SIGSEGV* (segmentation fault).
Removing either the second or the last line will make the generated executable work as intended. The last line could be ignored with the compiler flag `-zexecstack` ([Try it online!](https://tio.run/##S9ZNT07@/z83MTPP1sz6//9/yWk5ienF/3WrUitSk4tLEpOzAQ "C (gcc) – Try It Online")), but this costs **12 bytes**.
A shorter alternative is to declare *main* with the *const* modifier, resulting in the following assembly.
```
        .globl  main
        .section    .rodata
main:
        .long   6
        .section    .note.GNU-stack,"",@progbits
```
This works without any compiler flags. Note that `main=6;` would write the defined "function" in *data*, but the *const* modifier makes GCC write it in *rodata* instead, which (at least on my platform) is allowed to contain code.
[Answer]
# Swift, 5 bytes
```
[][0]
```
Access index 0 of an empty array. This calls `fatalError()`, which prints an error message and crashes with a SIGILL. [You can try it here](http://swiftlang.ng.bluemix.net/#/repl/5831ec1d892718588ddb0ddb).
[Answer]
# GNU C, 25 bytes
```
main(){__builtin_trap();}
```
GNU C (a specific dialect of C with extensions) contains an instruction to crash the program intentionally. The exact implementation varies from version to version, but often the developers make an attempt to implement the crash as cheaply as possible, which normally involves the use of an illegal instruction.
The specific version I used to test is `gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0`; however, this program causes a SIGILL on a fairly wide range of platfoms, and thus is fairly portable. Additionally, it does it via actually executing an illegal instruction. Here's the assembly code that the above compiles into with default optimization settings:
```
main:
    pushq %rbp
    movq %rsp, %rbp
    ud2
```
`ud2` is an instruction that Intel guarantees will always remain undefined.
[Answer]
# C (x86\_64), 11, 30, 34, or 34+15 = 49 bytes
```
main[]="/";
```
```
c=6;main(){((void(*)())&c)();}
```
```
main(){int c=6;((void(*)())&c)();}
```
I've submitted a couple of solutions that use library functions to throw `SIGILL` via various means, but arguably that's cheating, in that the library function solves the problem. Here's a range of solutions that use no library functions, and make varying assumptions about where the operating system is willing to let you execute non-executable code. (The constants here are chosen for x86\_64, but you could change them to get working solutions for most other processors that have illegal instructions.)
`06` is the lowest-numbered byte of machine code that does not correspond to a defined instruction on an x86\_64 processor. So all we have to do is execute it. (Alternatively, `2F` is also undefined, and corresponds to a single printable ASCII character.) Neither of these are guaranteed to always be undefined, but they aren't defined as of today.
The first program here executes `2F` from the read-only data segment. Most linkers aren't capable of producing a working jump from `.text` to `.rodata` (or their OS's equivalent) as it's not something that would ever be useful in a correctly segmented program; I haven't found an operating system on which this works yet. You'd also have to allow for the fact that many compilers want the string in question to be a wide string, which would require an additional `L`; I'm assuming that any operating system that this works on has a fairly outdated view of things, and thus is building for a pre-C94 standard by default. It's possible that there's nowhere this program works, but it's also possible that there's somewhere this program works, and thus I'm listing it in this collection of more-dubious-to-less-dubious potential answers. (After I posted this answer, Dennis also mentioned the possibility `main[]={6}` in chat, which is the same length, and which doesn't run into problems with character width, and even hinted at the potential for `main=6`; I can't reasonably claim these answers as mine, as I didn't think of them myself.)
The second program here executes `06` from the read-write data segment. On most operating systems this will cause a segmentation fault, because writable data segments are considered to be a bad design flaw that makes exploits likely. This hasn't always been the case, though, so it probably works on a sufficiently old version of Linux, but I can't easily test it.
The third program executes `06` from the stack. Again, this causes a segmentation fault nowadays, because the stack is normally classified as nonwritable for security reasons. The linker documentation I've seen heavily implies that it used to be legal to execute from the stack (unlike the preceding two cases, doing so is occasionally useful), so although I can't test it, I'm pretty sure there's some version of Linux (and probably other operating systems) on which this works.
Finally, if you give `-Wl,-z,execstack` (15 byte penalty) to `gcc` (if using GNU `ld` as part of the backend), it will explicitly turn off executable stack protection, allowing the third program to work and give an illegal operation signal as expected. I *have* tested and verified this 49-byte version to work. (Dennis mentions in chat that this option apparently works with `main=6`, which would give a score of 6+15. I'm pretty surprised that this works, given that the 6 blatantly isn't on the stack; the link option apparently does more than its name suggests.)
[Answer]
# GNU as (x86\_64), 3 bytes
```
ud2
```
---
$ xxd sigill.S
```
00000000: 7564 32                                  ud2
```
$ as --64 sigill.S -o sigill.o ; ld -S sigill.o -o sigill
```
sigill.S: Assembler messages:
sigill.S: Warning: end of file not at end of a line; newline inserted
ld: warning: cannot find entry symbol _start; defaulting to 0000000000400078
```
$ ./sigill
```
Illegal instruction
```
$ objdump -d sigill
```
sigill:     file format elf64-x86-64
Disassembly of section .text:
0000000000400078 <__bss_start-0x200002>:>
  400078:       0f 0b                   ud2
```
[Answer]
## Bash on Raspbian on QEMU, 4 (1?) bytes
Not my work. I merely report the work of another. I'm not even in a position to test the claim. Since a crucial part of this challenge seems to be finding an environment where this signal will be raised and caught, I'm not including the size of QEMU, Raspbian, or bash.
On Feb 27, 2013 8:49 pm, user [emlhalac](https://www.raspberrypi.org/forums/memberlist.php?mode=viewprofile&u=59462&sid=0e95d50056c1d75daa9a3183a3596b4e) reported "[Getting 'illegal instruction' when trying to chroot](https://www.raspberrypi.org/forums/viewtopic.php?p=298537)" on the Raspberry Pi fora.
```
ping
```
producing 
```
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
Illegal instruction (core dumped)
```
I imagine much shorter commands will produce this output, for instance, `tr`.
EDIT: Based on [@fluffy's comment](https://codegolf.stackexchange.com/questions/100532/shortest-code-to-throw-sigill/100628#comment244372_100628), reduced the conjectured lower bound on input length to "1?".
[Answer]
# x86 MS-DOS COM file, 2 bytes
**EDIT:** As pointed out in the comments, DOS itself will not trap the CPU exception and will simply hang (not just the app, the entire OS). Running on a 32-bit NT-based OS such as Windows XP will, indeed, trigger an illegal instruction signal.
```
0F 0B
```
From the [documentation](http://x86.renejeschke.de/html/file_module_x86_id_318.html):
> 
> Generates an invalid opcode. This instruction is provided for software testing to explicitly generate an invalid opcode.
> 
> 
> 
Which is pretty self-explanatory. Save as a .com file, and run in any DOS emulator DOS emulators will just crash. Run on Windows XP, Vista, or 7 32-bit.
[![SIGILL on Windows XP](https://i.stack.imgur.com/85VuO.png)](https://i.stack.imgur.com/85VuO.png)
[Answer]
# C (32-bit Windows), 34 bytes
```
f(i){(&i)[-1]-=9;}main(){f(2831);}
```
This only works if compiling without optimizations (else, the illegal code in the `f` function is "optimized out").
Disassembly of the `main` function looks like this:
```
68 0f 0b 00 00    push 0b0f
e8 a1 d3 ff ff    call _f
...
```
We can see that it uses a `push` instruction with a literal value `0b0f` (little-endian, so its bytes are swapped). The `call` instruction pushes a return address (of the `...` instruction), which is situated on the stack near the parameter of the function. By using a `[-1]` displacement, the function overrides the return address so it points 9 bytes earlier, where the bytes `0f 0b` are.
These bytes cause an "undefined instruction" exception, as designed.
[Answer]
# Java, ~~50~~ ~~43~~ 24 bytes
```
a->a.exec("kill -4 $$");
```
This is a `java.util.function.Consumer<Runtime>`1 whose command is stolen from [fluffy's answer](https://codegolf.stackexchange.com/a/100678). It works because you *must* call it as `whateverNameYouGiveIt.accept(Runtime.getRuntime())`!
Note that this will create a new process and make it throw a SIGILL rather than throwing a SIGILL itself.
1 - Technically, it can also be a `java.util.function.Function<Runtime, Process>` because `Runtime#exec(String)` returns a `java.lang.Process` which can be used to control the process you just created by executing a shell command.
---
For the sake of doing something more impressive in such a verbose language, here's a ~~72~~ ~~60~~ 48-byte bonus:
```
a->for(int b=0;;b++)a.exec("sudo kill -s 4 "+b);
```
This one is another `Consumer<Runtime>` that goes through ALL processes (including itself), making each of them throw a SIGILL. Better brace for a violent crash.
---
And another bonus (a `Consumer<ANYTHING_GOES>`), which at least *pretends* to throw a SIGILL in 20 bytes:
```
a->System.exit(132);
```
[Answer]
# Perl, 9 bytes
```
kill+4,$$
```
Simply calls the appropriate library function for signalling a process, and gets the program to signal itself with `SIGILL`. No actual illegal instructions are involved here, but it produces the appropriate result. (I think this makes the challenge fairly cheap, but if anything's allowed, this is the loophole you'd use…)
[Answer]
# ARM Unified Assembler Language (UAL), 3 bytes
```
nop
```
For example:
```
$ as ill.s -o ill.o
$ ld ill.o -o ill
ld: warning: cannot find entry symbol _start; defaulting to 00010054
$ ./ill 
Illegal instruction
```
After executing `nop`, the processor interprets the `.ARM.attributes` section as code and encounters an illegal instruction somewhere there:
```
$ objdump -D ill
ill:     file format elf32-littlearm
Disassembly of section .text:
00010054 <__bss_end__-0x10004>:
   10054:       e1a00000        nop                     ; (mov r0, r0)
Disassembly of section .ARM.attributes:
00000000 <.ARM.attributes>:
   0:   00001341        andeq   r1, r0, r1, asr #6
   4:   61656100        cmnvs   r5, r0, lsl #2
   8:   01006962        tsteq   r0, r2, ror #18
   c:   00000009        andeq   r0, r0, r9
  10:   01080106        tsteq   r8, r6, lsl #2
```
Tested on a Raspberry Pi 3.
[Answer]
# Microsoft C (Visual Studio 2005 onwards), 16 bytes
```
main(){__ud2();}
```
I can't easily test this, but according to [the documentation](https://msdn.microsoft.com/en-us/library/aa983360(v=vs.80).aspx) it should produce an illegal instruction by intentionally trying to execute a kernel-only instruction from a user-mode program. (Note that because the illegal instruction crashes the program, we don't have to try to return from `main`, meaning that this K&R-style `main` function is valid. Visual Studio never having moved on from C89 is normally a bad thing, but it came in useful here.)
[Answer]
# Ruby, 13 bytes
```
`kill -4 #$$`
```
I guess it's safe to assume that we are running this from a \*nix shell. The backtick literals runs the given shell command. `$$` is the running Ruby process, and the `#` is for string interpolation.
---
Without calling the shell directly:
# Ruby, 17 bytes
```
Process.kill 4,$$
```
[Answer]
# ELF + x86 machine code, 45 bytes
This should be the smallest executable program on an Unix machine that throws SIGILL (due to Linux not recognizing the executable if made any smaller).
Compile with `nasm -f bin -o a.out tiny_sigill.asm`, tested on an x64 virtual machine.
Actual 45 bytes binary:
```
0000000 457f 464c 0001 0000 0000 0000 0000 0001
0000020 0002 0003 0020 0001 0020 0001 0004 0000
0000040 0b0f c031 cd40 0080 0034 0020 0001
```
Assembly listing (see source below):
```
;tiny_sigill.asm      
BITS 32
            org     0x00010000
            db      0x7F, "ELF"             ; e_ident
            dd      1                                       ; p_type
            dd      0                                       ; p_offset
            dd      $$                                      ; p_vaddr 
            dw      2                       ; e_type        ; p_paddr
            dw      3                       ; e_machine
            dd      _start                  ; e_version     ; p_filesz
            dd      _start                  ; e_entry       ; p_memsz
            dd      4                       ; e_phoff       ; p_flags
_start:
                ud2                             ; e_shoff       ; p_align
                xor     eax, eax
                inc     eax                     ; e_flags
                int     0x80
                db      0
                dw      0x34                    ; e_ehsize
                dw      0x20                    ; e_phentsize
                db      1                       ; e_phnum
                                                ; e_shentsize
                                                ; e_shnum
                                                ; e_shstrndx
  filesize      equ     $ - $$
```
Disclaimer: code from the following tutorial on writing the smallest assembly program to return a number, but using opcode ud2 instead of mov:
<http://www.muppetlabs.com/~breadbox/software/tiny/teensy.html>
[Answer]
# [AutoIt](http://autoitscript.com), 93 bytes
Using flatassembler inline assembly:
```
#include<AssembleIt.au3>
Func W()
_("use32")
_("ud2")
_("ret")
EndFunc
_AssembleIt("int","W")
```
When run in SciTE interactive mode, it'll crash immediately. The Windows debugger should popup for a fraction of a second. The console output will be something like this:
```
--> Press Ctrl+Alt+Break to Restart or Ctrl+Break to Stop
0x0F0BC3
!>14:27:09 AutoIt3.exe ended.rc:-1073741795
```
Where `-1073741795` is the undefined error code thrown by the WinAPI. This can be any negative number.
Similar using my own assembler [LASM](https://www.autoitscript.com/forum/topic/173946-light-assembler-lasm-and-a-bunch-of-examples/):
```
#include<LASM.au3>
$_=LASM_ASMToMemory("ud2"&@CRLF&"ret 16")
LASM_CallMemory($_,0,0,0,0)
```
[Answer]
# Any shell (sh, bash, csh, etc.), any POSIX (10 bytes)
Trivial answer but I hadn't seen anyone post it.
```
kill -4 $$
```
Just sends SIGILL to the current process. Example output on OSX:
```
bash-3.2$ kill -4 $$
Illegal instruction: 4
```
[Answer]
# Python, 32 bytes
```
from os import*;kill(getpid(),4)
```
[Answer]
# NASM, 25 bytes
I don't know how this works, just that it does on my computer specifically (Linux x86\_64).
```
global start
start:
jmp 0
```
Compile & run like:
```
$ nasm -f elf64 ill.asm && ld ill.o && ./a.out
ld: warning: cannot find entry symbol _start; defaulting to 0000000000400080
Illegal instruction
```
[Answer]
# TI-83 Hex Assembly, 2 bytes
```
PROGRAM:I
:AsmPrgmED77
```
Run as `Asm(prgmI)`. Executes the illegal 0xed77 opcode. I count each pair of hex digits as one byte.
[Answer]
# Linux shell, 9 bytes
```
kill -4 0
```
Sends `SIGILL` to the process with PID 0. I don't know what process has PID 0, but it always exists.
[Try it online!](https://tio.run/##S0oszvj/PzszJ0dB10TB4P9/AA)
[Answer]
# x86 .COM, 1 byte
```
c
```
`ARPL` causes `#UD` in 16-bit mode
[Answer]
# Rust, 53 bytes
```
fn main(){unsafe{std::hint::unreachable_unchecked()}}
```
This piece of code generates no `main` function because main is marked as unreached, hence SIGILL being triggered when run. [Try it online!](https://tio.run/##BcHBDcAgCADAVfrUFVimoYjBtPIQeBlnp3crzDO7XhOHlrpDDTtv8wYgQx0gdDGS4PPxHUrC9HIr9ZzMHw "Rust – Try It Online")
[Answer]
# GNU C, ~~24~~ ~~19~~ 18 bytes
-4 thanks to Dennis  
-1 thanks to ceilingcat
```
main(){goto*&"'";}
```
[Try it online!](https://tio.run/##S9ZNT07@/z83MTNPQ7M6Pb8kX0tNSV3Juvb/fwA) This assumes ASCII and x86\_64. It attempts to run the machine code `27`, which ... is illegal.
---
# [shortC](//git.io/shortC), ~~10~~ ~~5~~ 4 bytes
```
AV"'
```
Equivalent to the GNU C code above. [Try it online!](https://tio.run/##K87ILypJ/v/fMUwpxuz/fwA)
[Answer]
# [MachineCode](//github.com/aaronryank/MachineCode) on x86\_64, ~~2~~ 1 bytes
```
7
```
[Try it online!](https://tio.run/##y01MzsjMS03OT0n9/9/I/P9/AA)
Simply calls the x86\_64 instruction `0x07` (ceilingcat suggested 0x07 instead of 0x27)
[Answer]
# MMIXAL, 13 bytes
`Main RESUME 2`
`RESUME` is legal in all code; `RESUME 1` throws a protection violation in user mode; any other argument throws an illegal instruction violation.
]