SIGILL on stepping through BLX instruction

[robbelcham]

I am debugging an application built using the gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux tools on my linux build (virtual) machine which is a guest in my windows host OS. I am encountering several problems, but the main one that is getting in the way is the fact that Visual GDB bombs out when my target executes a BLX instruction (typically as a result of a function call). If I “run to” somewhere inside the function being called it reaches the break-point ok, but attempting to step into or over a function results in  :-

Child terminated with signal = 0x4 (SIGILL)
GDBserver exiting

If I run gdb manually on my linux build machine, I can debug without this problem using the following commands on the target :-

DISPLAY=:0 gdbserver –multi :2345 ./squig –fullscreen –resources /opt/midas/resources/squig/squig-resources/

and host :-

/opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-gdb -q -nh -ex “target extended-remote 192.168.20.5:2345” -ex “file build-armhf/squig” -ex ‘tb main’ -ex ‘c’ -ex ‘set solib-search-path /home/robbelcham/WorkInProgress/ML/birchen/Source/Squig/build-armhf/src’ -ex ‘set sysroot /home/robbelcham/Development/TPL/sdk/sysroots/cortexa15hf-vfp-neon-poky-linux-gnueabi/’

 

Another problem I have, which may or may not be related, is that GDB crashes if I attempt to get it load symbols from a shared library at startup. If i launch the debug process, then halt and enter ..

set solib-search-path /home/robbelcham/WorkInProgress/ML/birchen/Source/Squig/build-armhf/src/

on the gdb command interface in VisGDB, then the symbols are loaded fine, however it takes about 18 seconds because the file libsquiglib.so which is loaded is 350Mb. If I add the same gdb command to the “Additional GDB commands” either before or after target selection, I get “Received a SIGSEGV” message very early on in the application launch & don’t get the expected “this command is taking a long time” message.

I do have the following set-sysroot command in the additional command section as well, but that doesn’t cause a crash.

set sysroot /home/robbelcham/Development/TPL/sdk/sysroots/cortexa15hf-vfp-neon-poky-linux-gnueabi/

I tried using “handle SIGILL nostop pass” as suggested elsewhere on this forum, but this just results in the same error (SIGILL exit) a couple of instructions later.

For example, the following function call can be stepped in the disassembly window…

m_DSPStorage->SetDSPParameter(
m_enPairPathType, // DSP Path type
m_nChannelPairPath, // DSP Path
nDspParam + m_nChannelPairOffset, // nDspParameter,
fValue // Value
);
0xb612436a ldr r3, [pc, #56] ; (0xb61243a4 <dspParams::CInputChannel::UpdateInputDynamicsRotary(int, float)+300>)
0xb612436c ldr r3, [r4, r3]
0xb612436e ldr r0, [r3, #0]
0xb6124370 ldr r3, [r7, #12]
0xb6124372 ldr.w r1, [r3, #1408] ; 0x580
0xb6124376 ldr r3, [r7, #12]
0xb6124378 ldr.w r2, [r3, #1424] ; 0x590
0xb612437c ldr r3, [r7, #12]
0xb612437e ldr.w r4, [r3, #1420] ; 0x58c
0xb6124382 ldr r3, [r7, #20]
0xb6124384 add r3, r4
0xb6124386 vldr s0, [r7, #4]
0xb612438a blx 0xb5a922bc

but when I step on the BLX line, when SIGILL is set to pass through, I get a little bit further, but then it bombs out on the next instruction…

0xb5a922c0 add r12, r12, #954368 ; 0xe9000   #### PC shows as being here, however the address doesn’t agree with the value used in the BLX instruction :- 0xb5a922<span style=”text-decoration: underline;”>bc</span>
0xb5a922c4 ldr pc, [r12, #2244]! ; 0x8c4

Can anyone offer any help or advise ?

I’m running on a Tegra which according to uname is “armv71” architecture.

 

 

[support]

Hi,

This could happen if your gdb and gdbserver were not 100% compatible. Please ensure that your gdbserver comes from the toolchain provided by your device vendor. If not, we would recommend either debugging directly on the device, or building a gdb binary using the same sources (including Debian patches) and the same settings as your target gdb has.

[robbelcham]

Thanks, but I’m not convinced this is the problem because I have used the same gdb & gdbserver binaries on the command line (with same linux VM and target) and I can step into the BLX functions without an issue which is why I suspect the problem is with VisualGDB, or it’s use of gdb.

 

Also, interestingly I can debug a different application built on the same VM build machine with the same tools and deployed to the same target without any issues. The only major difference that I am aware of is that the application that won’t debug properly uses a shared library (.so) whereas the app which debugs fine is statically linked.

 

[support]

Hi,

No problem. If the same gdb works with command line, we would recommend double-checking the following:

• The exact command lines when launching gdb and gdbserver
• Environment (e.g. LD_LIBRARY_PATH)

Please also try switching gdb start mode to ‘custom’ and explicitly specify the ‘target remote ….’ command. Then launch gdbserver manually and let VisualGDB launch gdb. If the problem persists, it is caused by gdb configuration, if not – it’s caused by gdbserver launch configuration.

You can use the View->Other Windows->VisualGDB Diagnostics Console command to see the internal VisualGDB output showing the commands it runs.

[Author]

Posts