Determining the library which causes "Illegal instruction" on a Pi Zero W (armv6), and fixing the build

Question

I understand that a lot of compilation issues on the Pi Zeros are due to the fact that they use armv6, whereas the newer Raspberry Pi's like the 3 A+ and B+ use armv7. However, I do not understand how to find the offending library in an application that is causing the issue, and if there is perhaps a simple fix for the problem.

Background:

I am trying to port an application from a Linux Desktop environment to the Pi Zero (running armv6). I successfully ported it to the Pi 3 B and B+. That is, I compiled the code, and checked that it is producing the correct output.

However, the Pi Zero implementation compiles, but just spits out a single message when run:

Illegal instruction

This is most likely due to some command that is not compatible with armv6, but I cannot figure out which command that is. I would like to start by determining which library is the problem child. Please tell me how I would diagnose that.

Extra Info:

I have checked that the compiler is not the issue. How? I made a simple hello world program, and compiled it for the Pi Zero:

#include<iostream>

int main(int argc, char *argv[]){
   std::cout << "Hello World!" << std::endl;
   return 0;
}

So the compiler itself doesn't seem to be the issue.

More details:

If I run readelf -A myapp, my understanding is that the output is reporting that the app is indeed compiled for armv6:

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6"
  Tag_CPU_arch: v6
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv2
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_rounding: Needed
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6

Here is the readelf -A for one of the shared libraries:

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "6"
  Tag_CPU_arch: v6
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-1
  Tag_FP_arch: VFPv4
  Tag_Advanced_SIMD_arch: NEONv1 with Fused-MAC
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: Deprecated
  Tag_ABI_VFP_args: VFP registers
  Tag_CPU_unaligned_access: v6

Try if you can install valgrind, or compile with `gcc -fsanitize=undefined` - very probably it is your code and undefined behaviour. — Antti Haapala -- Слава Україні, Jan 05 '19 at 21:36
@AnttiHaapala - no, that is quite unlikely. The question is specific to the older of two related processors, where this issue is routinely seen in software the neglects the difference. — Chris Stratton, Jan 05 '19 at 21:39
The code works on a Raspberry Pi 3 B+. It does not work on a Pi Zero WH. My code itself does not use any NEON instructions or anything like that. So the issue must be one of the libraries. — bremen_matt, Jan 05 '19 at 21:39
@bremen_matt - install gdb (`sudo apt install gdb`) and run your program under it. That will catch the fault and show you where it is occurring. If for some reason you can't figure it out there, while it is sitting there paused you can also look in the /proc/[PID]/maps file and figure see what file's mapping includes the address of the instruction that triggered the fault. — Chris Stratton, Jan 05 '19 at 21:40
Ok. I will try that tomorrow. Probably this will take a long time because of how slow the Pi Zero is. — bremen_matt, Jan 05 '19 at 21:43
No, it shouldn't really take any longer than running the program normally takes to get to the fault and crash; the difference is that this time you'll be able to see why. — Chris Stratton, Jan 05 '19 at 21:44
I dont understand your opening statement. There are no compilation issues with respect to armv6 vs armv7 vs armv8. If you select the right command line options both gcc and llvm build proper binaries. The compilers dont have problems. users of the compilers sure, folks that use assembly language or worse inline assembly language...sure — old_timer, Jan 05 '19 at 22:16
"how slow the pi-zero is" seriously? it should hit an illegal instruction if that is really what is going on the first time through. now if there is a pointer running around trashing things or something like that then it can take a while but they are all pretty speedy machines. armv7 doest add that many instructions, but there still is a chance that the code being modified can look real on one processor and not on another. or it could be a timing thing that the modification happens at a different time between designs fast or slow doesnt matter, if that is what is really going on. — old_timer, Jan 05 '19 at 22:19
we cant tell from what you have provided. Also note that you should be able to run the same binary on the armv7 that you run on the armv6. Now if you are porting to armv8/aarch64 that is a completely different instruction set. — old_timer, Jan 05 '19 at 22:21
how you figure it out involves a debugger and or a dump when you hit the bad instruction. if you add or remove code to your program does it change the result, add a printf near the beginning does it change the result? If not then you can add printfs at various places and narrow in on the call/function in question. And/or remove chunks of code and see if the problem goes away. If this is a compiler bug then even one instruction change can affect it and have nothing to do with what you are thinking is the problem. (I know of a gcc bug they wont fix but it doesnt affect this core). — old_timer, Jan 05 '19 at 22:23
Please use a debugger, and/or reduce the program down to a minimal example, or add printfs or other debug output to narrow in on the problem. If adding a line of code or removing it causes the problem to go away doesnt imply that chunk of code was it, if adding causes it go to away is an indicator of a different type of problem a race condition or bad pointer. — old_timer, Jan 05 '19 at 22:25

Chris Stratton · Accepted Answer · 2019-01-05T22:43:38.720

To identify a fault such as Illegal instruction you can run the program under a debugger capable of interacting with the operating system's fault handler.

On a Linux system such as the pi, that would be gdb. You may need to install this, on a debian-derived distribution that would be sudo apt-get install gdb

Then run your program

gdb myprog

or if your program needs command line arguments

gdb myprog --args some_argument another_argument

Once gdb starts up type run, and the program will execute near normally until it reaches the illegal instruction, at which point you will be dumped back at the gdb prompt with a hopefully informative error message.

There you can explore with commands such as backtrace or if the programmer has associated source, list. If the fault is at an address gdb can see as being mapped as from a file it should show you that - you can also get at the mapping information via the gdb command info files or by looking in /proc/[PID]/maps

If for some reason you can't run the program live under gdb, you can research how to enable core dumps for your system, and then load the program and the core dump into gdb for post-mortem analysis.

Depending on system configuration, if running the program on its own without a debugger, you may also see information about the fault in the output of dmesg or another system log.

score 0 · Answer 2 · answered Nov 21 '22 at 11:31

0

i have simple answer just press up button and try

rpi0 can run all programs if you have armel

see here its a rpi0 os build script build a minimal os on based on armel architecture

https://gitlab.com/kalilinux/build-scripts/kali-arm

how i solved i tried to run java on raspbian os it did not worked i used kali for raspberry pi zero java was running

so use armel arch

answered Nov 21 '22 at 11:31

rehman azhar

11
2

Sorry, but your answer does not make any sense, and the grammatical errors is unfortunately so bad I cannot be sure what you're trying to convey. Please try to rephrase your answer. – not2qubit Nov 29 '22 at 21:10

Determining the library which causes "Illegal instruction" on a Pi Zero W (armv6), and fixing the build

2 Answers2