On 09.11.2016 21:44, Paul Smith wrote: > On Wed, 2016-11-09 at 21:31 +0200, Jaak Ristioja wrote: >> I'm attaching[*] the core and the binaries for 4.2.1, but I don't >> know how to debug it myself. > > It's unlikely anyone here will be able to help debug a random ARM core > file (for sure I can't). At the very least we would need a stacktrace > from the core to even begin to look at this. > > You, or someone who can reproduce the problem, need to install gdb on > your system, and run: > > gdb -c core make > > then run the "bt" command to get a backtrace. You can choose a frame > with "fr <N>" where <N> is the frame number, and print the value of > variables with "p <varname>", or "p *<varname>" if it's a pointer and > you want to see what it points to.
I have no ARM experience myself. I don't even know where to look for ABI documentation. This is the best I can currently get from the core: (gdb) thread apply all bt full Thread 1 (LWP 15210): #0 0x0d33b0bc in ?? () No symbol table info available. #1 <signal handler called> No symbol table info available. #2 0x64a2a8b0 in strlen () from /lib/libc.so.6 No symbol table info available. #3 0x0d340370 in concat () No symbol table info available. #4 0x0d680d34 in ?? () No symbol table info available. Backtrace stopped: previous frame identical to this frame (corrupt stack?) J _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
