VS2017 debugging disassembled Thumb2 code problems

[jturnsek]

Hi,

I am having problems with debugging (Remote Linux Project) disassembly Thumb2 code (architecture ARMV7-A), where I can step through code step-by-step normally, but when I hit the IT instruction, debugging session stops or SEGFAULT exception is thrown. If I am not stepping through code, the code works. Also the code itself is not disassembled as Thumb but as ARM code, although I have a directive .thumb inside the .S file. Bellow is example of the code, which is then compiled with other C code.

.file “buildvm_armv7m.dasc”
.syntax unified
.thumb
.text
.p2align 2

.globl <some_function_name>
.thumb_func
.hidden <some_function_name>
.type <some_function_name>, %function
.size<some_function_name>, 84
<some_function_name>:
.long 0x0b0bea6f,0x000aeb09,0x0003e890,0xc002f8b6
.long 0x202bf855,0x0604f106,0x0c8ceb06,0x0f05f111
.long 0x8012f040,0x0f02ebb0,0xbf08bf00,0x3600f5ac
.long 0xc000f896,0xeb04f856,0xc02cf857,0x4a5eea04
.long 0x4b1eea4f,0x4760bf00,0x0f0bf111,0xaff0f47f
.long 0xbb18f002

 

When I call <some_function_name> from stepping through C code which is build with -mthumb -march=armv7-a and is shown correctly in disassembly window as Thumb code, disassembly window shows only ARM code and when I hit the IT instruction (preceded with NOP) I get exception or debugging session stops. What should I do to correctly show the code in disassembly and to be capable of fully debugging the code?

Thank you,

Jernej

[jturnsek]

I have found out that setting:

set disassembler-options force-thumb

forces disassembler to show Thumb encoding. Good. But still when hitting IT instruction, SIGSEGV is thrown. Why?

Jernej

[support]

The IT instruction might not be supported by your device. Please double-check its documentation to be 100% sure.

[jturnsek]

Hi,

I have tested on ARM Cortex A15 and A8. Both are ARMv7-A architecture which also supports Thumb2 instructions. In the reference manual for the ARMv7-A it is clearly stated that IT is needed for conditional opcodes.

Maybe GDB is not supporting IT?

Regards,

Jernej

[support]

GDB should not normally interfere with it, however you can quickly check whether your device supports it by inserting some code with this instruction into a basic LEDBlink program using some inline assembly and then using Debug->Program and start without debugging. If this stops the LED from blinking, your device may not support this instruction.

[jturnsek]

I have already tested the execution of my program without debugging it and it works as it should. The problem is only when I am debugging my assembly code step by step. Also executing the program directly on the target (BTW it is Ubuntu 18.04 operating system and Beagleboard X15), it works without problems. I have find out some old patch for the old GDB where something similar was mentioned about debugging Thumb2 code step by step within IT block. but that was before GDB version 7. I have GDB 8.1.0 installed on Ubutnu 18.04.

[jturnsek]

Actually is not an IT instruction which is segfaulting, it is an instruction inside an IT block and which is executed if condition is met. If I manually change the condition to false, thus instruction in IT block would not be executed, program runs through without SIGSEGV.

[support]

Good to know you found the root cause. If you encounter further problems, please don’t hesitate to create another thread.

[jturnsek]

Actually what I found out is the problem with GNU/Linux GDB session, but currently I can not confirm it. Investigating and searching on the web, the problem is most probably with setting software breakpoints during the debugging session, when I should have hardware breakpoints. Because I am not using any JTAG for debugging I can not confirm this. As I have mentioned before, running the program without setting any breakpoint in my injected assembly thus not produce the SIGSEGV exception and the program runs ok. Also I have tried to go around of IT instruction with using plain conditional branch instruction and the debugging works. Only debugging IT blocks is problematic.

[support]

Thanks for the update. In this scenario, the difference might indeed come from software/hardware breakpoints. You can double-check this by running the “hbreak” command from the GDB Session window to set a hardware breakpoint manually.

VisualGDB would manage the hardware breakpoints automatically for JTAG-based debugging sessions, but it does rely on the GDB itself to handle it when debugging Linux processes. We could also add a toggle button to the GDB session window that will switch to using hardware breakpoints each time you create a new breakpoint via the Visual Studio interface to facilitate your scenario, although that would require purchasing a VisualGDB license (if you already have one associated with a different email address, please let us know).

[jturnsek]

Thanks for the information. I wasn’t aware that I could use hardware breakpoints with GNU/Linux session.

[jturnsek]

When I call hbreak in my gdb session I get this:

No hardware breakpoint support in the target.

[support]

Thanks for confirming your license status – we have linked it to your forum account in our system.

The hardware breakpoints in user-mode code might be supported (the kernel implement them via register_user_hw_breakpoint()), however we did not research whether gdb/gdbserver is capable of using that interface. You should be able to find it our by looking through the gdbserver source code – there might be a configuration switch enabling them.

If you can find a combination of tools that does support hardware breakpoints, we can easily add the button for toggling them to VisualGDB. However, if no underlying tool supports this scenario, unfortunately VisualGDB won’t be able to work around that.

[Author]

Posts