#173 "ThreadSetCurrentIp" sometime fails.
OCD 0.10.0. Reproduce stable, with chinese ST-LinkV2 dongle and STMF4Discovery build-in ST-LinkV2.
Debugee is STM32F1 and STM32F4 respectivelly. Gdb client is IDA Pro.
When i try to change IP debug session drops:
Debug: 7908 326686 gdb_server.c:2812 gdb_input_inner(): received packet: 'Pf=6c0d0008'
Debug: 7909 326690 gdb_server.c:1298 gdb_set_register_packet(): -
Debug: 7910 326694 gdb_server.c:2812 gdb_input_inner(): received packet: 'P19=20000041'
Debug: 7911 326703 gdb_server.c:1298 gdb_set_register_packet(): -
Error: 7912 326706 gdb_server.c:1320 gdb_set_register_packet(): gdb sent a packet with wrong register size
Debug: 7913 326715 gdb_server.c:1022 gdb_connection_closed(): GDB Close, Target: stm32f4x.cpu, state: halted, gdb_actual_connections=0
Debug: 7914 326725 target.c:1517 target_call_event_callbacks(): target event 6 (gdb-end)
Debug: 7915 326729 target.c:1517 target_call_event_callbacks(): target event 24 (gdb-detach)
Info : 7916 326737 server.c:503 server_loop(): dropped 'gdb' connection
In IDA:
Debugger: failed to update register value
Command "ThreadSetCurrentIp" failed
To reproduce need debug session some length. I.e. changing IP at first instructions works well, but some time later it fails.
Hello Dmitry,
Thank you for the report. To investigate it properly, more info is
needed, please see below.
On Wed, Jan 24, 2018 at 05:01:12PM -0000, Artamonov Dmitry wrote:
This command sets register "f" (that is, PC) to value 6c0d0008. This
looks odd to me, as stm32 use 0x08000000 region for flash and
0x20000000 for RAM. So what is 6c0d0008 supposed to mean?
Ok, and this is where it gets odd as 0x19 is one of the double "FPU"
registers and so its size is 64 bits, no 32 bits.
So it looks like for whatever reason IDA uses wrong register numbers
and odd values. Do you understand why it happens? It doesn't look like
OpenOCD is doing anything wrong here.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
If we reverse address bytes - they will be a correct value: 0x08000d6c.
IDA version is 7.0.170914
Last edit: Artamonov Dmitry 2018-01-24
One more reproduce. At startup point i set debug_level 3. Check PC changing and it works. Then i set debug_level 0, to reduce output noise. Then i do some step-in's, And Run program to reach breakpoint. Then Run it again. Then Suspend and set debug_level to 3. And tried to change PC.
Full log:
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v28 API v2 SWIM v0 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 2.907665
Info : stm32f4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
adapter speed: 1800 kHz
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800019c msp: 0x20000440
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
Info : Unable to match requested speed 8000 kHz, using 4000 kHz
adapter speed: 4000 kHz
Info : accepting 'telnet' connection on tcp/4444
Info : accepting 'gdb' connection on tcp/4242
Info : device id = 0x10016413
Info : flash size = 1024kbytes
User : 77 112712 command.c:544 command_print(): debug_level: 3
Debug: 78 116104 gdb_server.c:2812 gdb_input_inner(): received packet: 'm80001b8,4'
Debug: 79 116108 gdb_server.c:1386 gdb_read_memory_packet(): addr: 0x080001b8, len: 0x00000004
Debug: 80 116112 target.c:2091 target_read_buffer(): reading buffer of 4 byte at 0x080001b8
Debug: 81 116116 hla_target.c:750 adapter_read_memory(): adapter_read_memory 0x080001b8 4 1
Debug: 82 119358 gdb_server.c:2812 gdb_input_inner(): received packet: 'Pf=9c010008'
Debug: 83 119362 gdb_server.c:1298 gdb_set_register_packet(): -
Debug: 84 162407 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_debug_level 0
Debug: 85 162412 command.c:143 script_debug(): command - debug_level ocd_debug_level 0
debug_level: 0
Error: can't add breakpoint: resource not available
Error: can't add breakpoint: resource not available
Error: can't add breakpoint: resource not available
User : 95 201300 command.c:544 command_print(): debug_level: 3
Debug: 96 206759 gdb_server.c:2812 gdb_input_inner(): received packet: 'Pf=ca0d0008'
Debug: 97 206763 gdb_server.c:1298 gdb_set_register_packet(): -
Debug: 98 206767 gdb_server.c:2812 gdb_input_inner(): received packet: 'P19=20000021'
Debug: 99 206771 gdb_server.c:1298 gdb_set_register_packet(): -
Error: 100 206774 gdb_server.c:1320 gdb_set_register_packet(): gdb sent a packet with wrong register size
Debug: 101 206779 gdb_server.c:1022 gdb_connection_closed(): GDB Close, Target: stm32f4x.cpu, state: halted, gdb_actual_connections=0
Debug: 102 206784 target.c:1517 target_call_event_callbacks(): target event 6 (gdb-end)
Debug: 103 206788 target.c:1517 target_call_event_callbacks(): target event 24 (gdb-detach)
Info : 104 206792 server.c:503 server_loop(): dropped 'gdb' connection</transport>
Last edit: Artamonov Dmitry 2018-01-24
One more reproduce and i captured all PC-changing command gdb packets.
Gdb console:
Debug: 851 1921840 gdb_server.c:2812 gdb_input_inner(): received packet: 'Pf=e20d0008'
Debug: 852 1921845 gdb_server.c:1298 gdb_set_register_packet(): -
Debug: 853 1921850 gdb_server.c:2812 gdb_input_inner(): received packet: 'P19=20000021'
Debug: 854 1921855 gdb_server.c:1298 gdb_set_register_packet(): -
Error: 855 1921858 gdb_server.c:1320 gdb_set_register_packet(): gdb sent a packet with wrong register size
Debug: 856 1921865 gdb_server.c:1022 gdb_connection_closed(): GDB Close, Target: stm32f4x.cpu, state: halted, gdb_actual_connections=0
Debug: 857 1921874 target.c:1517 target_call_event_callbacks(): target event 6 (gdb-end)
Debug: 858 1921879 target.c:1517 target_call_event_callbacks(): target event 24 (gdb-detach)
Info : 859 1921886 server.c:503 server_loop(): dropped 'gdb' connection
">" means packet TO gdbserver
"<" means packet FROM gdbserver
I tried to change PC from 08000DF0 to 08000DE2
Packet #0>
0000 02 00 00 00 45 02 00 37 20 74 40 00 80 06 00 00 ....E..7 t@.....
0010 7f 00 00 01 7f 00 00 01 cb d5 10 92 46 80 20 5f ............F. _
0020 7b 8a 51 95 50 18 08 03 bf 5f 00 00 24 50 66 3d {.Q.P...._..$Pf=
0030 65 32 30 64 30 30 30 38 23 65 36 e20d0008#e6
Packet #1<
0000 02 00 00 00 45 00 00 28 20 75 40 00 80 06 00 00 ....E..( u@.....
0010 7f 00 00 01 7f 00 00 01 10 92 cb d5 7b 8a 51 95 ............{.Q.
0020 46 80 20 6e 50 10 7f 1d 22 3f 00 00 F. nP..."?..
Packet #2<
0000 02 00 00 00 45 02 00 2e 20 76 40 00 80 06 00 00 ....E... v@.....
0010 7f 00 00 01 7f 00 00 01 10 92 cb d5 7b 8a 51 95 ............{.Q.
0020 46 80 20 6e 50 18 7f 1d 79 5d 00 00 24 4f 4b 23 F. nP...y]..$OK#
0030 39 61 9a
Packet #3>
0000 02 00 00 00 45 00 00 28 20 77 40 00 80 06 00 00 ....E..( w@.....
0010 7f 00 00 01 7f 00 00 01 cb d5 10 92 46 80 20 6e ............F. n
0020 7b 8a 51 9b 50 10 08 03 99 53 00 00 {.Q.P....S..
Packet #4>
0000 02 00 00 00 45 02 00 38 20 78 40 00 80 06 00 00 ....E..8 x@.....
0010 7f 00 00 01 7f 00 00 01 cb d5 10 92 46 80 20 6e ............F. n
0020 7b 8a 51 9b 50 18 08 03 0d 67 00 00 24 50 31 39 {.Q.P....g..$P19
0030 3d 32 30 30 30 30 30 32 31 23 37 63 =20000021#7c
Packet #5<
0000 02 00 00 00 45 00 00 28 20 79 40 00 80 06 00 00 ....E..( y@.....
0010 7f 00 00 01 7f 00 00 01 10 92 cb d5 7b 8a 51 9b ............{.Q.
0020 46 80 20 7e 50 10 7f 19 22 2d 00 00 F. ~P..."-..
Packet #6<
0000 02 00 00 00 45 00 00 28 20 86 40 00 80 06 00 00 ....E..( .@.....
0010 7f 00 00 01 7f 00 00 01 10 92 cb d5 7b 8a 51 9b ............{.Q.
0020 46 80 20 7e 50 11 7f 19 22 2c 00 00 F. ~P...",..
Packet #7>
0000 02 00 00 00 45 00 00 28 20 87 40 00 80 06 00 00 ....E..( .@.....
0010 7f 00 00 01 7f 00 00 01 cb d5 10 92 46 80 20 7e ............F. ~
0020 7b 8a 51 9c 50 10 08 03 99 42 00 00 {.Q.P....B..
Packet #8>
0000 02 00 00 00 45 02 00 2d 20 88 40 00 80 06 00 00 ....E..- .@.....
0010 7f 00 00 01 7f 00 00 01 cb d5 10 92 46 80 20 7e ............F. ~
0020 7b 8a 51 9c 50 18 08 03 1a 98 00 00 24 67 23 36 {.Q.P.......$g#6
0030 37 7
Packet #9< (RST)
0000 02 00 00 00 45 00 00 28 20 89 40 00 80 06 00 00 ....E..( .@.....
0010 7f 00 00 01 7f 00 00 01 10 92 cb d5 7b 8a 51 9c ............{.Q.
0020 46 80 20 83 50 14 00 00 a1 3c 00 00 F. .P....<..
Last edit: Artamonov Dmitry 2018-01-24
On Wed, Jan 24, 2018 at 07:22:42PM -0000, Artamonov Dmitry wrote:
IDA asks to change PC to 0x08000de2, ok, fine.
...
WTF does IDA want here from OpenOCD?
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@gmail.com
I don't known.
Hypothesis: i'm create manual memory region in IDA debugger, covers the SRAM area. W/o this action stack contains only question marks. May be IDA want to refresh stacks entry(-es) ?
And some one hypothesis: can IDA try to switch endianless format on gdbserver with gdb protocol ? May be with optional command or something. (I dont know this protocol specification). And this command is simply not handled with OpenOCD gdbserver.
This specific command P19=20000041 can mean only one thing: set
register 0x19 to 0x20000041 value.
The question is why IDA decided to change that register? Is it
supposed to touch floating point registers (which are not present on
stm32f1) at all at that point?
The address looks like some SRAM address. Probably it's trying to
adjust stack pointer register? But then it's using wrong number, SP is
0xd. Probably it wants to adjust PSP (Process Stack Pointer) but then
it's number 19, not 0x19.
So far it very much looks like a bug in IDA.