Quote:
Originally Posted by geekmaster
As I mentioned, I executed those incorrectly just to SEE what they were looking for. On the K1 they run correctly. New stuff I compile does not even put out those error messages, so I do not know what they are looking for. Using ELF tools is something I am not (yet) familiar with. I have *other* hobbies besides this, and fighting with build tools is not (a desirable) part of this hobby. Now if somebody were to pay me to do this, it might be much less painful; my "free" time is too valuable for this...
|
What I'd try is an objdump -dS (using the right toolchain's objdump, obviously) and do some hex arithmetic from the faulting dmesg (if any) to see what instruction it's whining about. If you figure that out, I can have a look at GCC and see why it's generating that instruction, and how to stop it. (I enjoy toolchain stuff like little else, which means I'm one of those tiresome people whose hobby is also their job!)
If there is no faulting dmesg, then since there's no gdb binary on this platform (and we can't build a gdb stub for remote debugging until we can build a binary that works), then it gets much harder to figure out what's causing this. But if we can figure out what instruction is triggering this SIGILL, we're most of the way there.
The ARM is rather famous for having wild variation in the variety of instructions particular chips accept: I'd bet that at least one that is usually available on ARMv5 isn't available on the one used in the K1.