GDB printing wrong disassembly after connecting to server

[rimio]

NOTICE: The issue may be closed without notice when not enough information is provided!

Thank you for giving feedback to the stlink project. Take some time to fill out check boxes with a X in the following items so developers and other people can try to to find out what is going on. And add/remove what is appropriate to your problem.

When submitting a feature request, try to reuse the list and add/remove what is appropriate. Place a X between the brackets [X] to mark the list item.

• [x] Programmer/board type: Stlink/v2-onboard
• [x] Programmer firmware version: unknown
• [x] Operating system: ArchLinux (up-to-date), GDB v8.1, GCC v7.3.0, GAS v2.30
• [x] Stlink tools version and/or git commit hash: v1.5.0
• [x] Stlink commandline tool name: st-util
• [x] Target chip (and optional board): STM32-L152RE

A as-detailed description possible of the problem with debug output when available.

Output:

$ arm-none-eabi-gdb image.elf 
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from image.elf...done.
(gdb) disass __int_reset
Dump of assembler code for function __int_reset:
   0x08000054 <+0>:	ldr	r0, [pc, #44]	; (0x8000084 <Lzero_bss_done+4>)
   0x08000056 <+2>:	ldr	r1, [pc, #48]	; (0x8000088 <Lzero_bss_done+8>)
   0x08000058 <+4>:	ldr	r2, [pc, #48]	; (0x800008c <Lzero_bss_done+12>)
End of assembler dump.
(gdb) tar ext :4242
Remote debugging using :4242
0x08000054 in __int_reset ()
(gdb) disass __int_reset
Dump of assembler code for function __int_reset:
=> 0x08000054 <+0>:	movs	r0, r0
   0x08000056 <+2>:	movs	r0, r0
   0x08000058 <+4>:	movs	r0, r0
End of assembler dump.
(gdb) 

Expected/description: The first disassembly is correct, and I believe the second should be identical. Please note that code seems to execute fine (by nexti-ing through the functions, the correct branches seem to be taken). Let me know if you need any extra information, or if I'm doing something horribly wrong.

Thank you, The stlink project maintainers

[rimio]

Can confirm disassembly works as intended with OpenOCD.

[xor-gate]

I'm not sure, your toolchain is fairly recent. Maybe there is something wrong with the GDB remote protocol on the st-util side.

[Nightwalker-87]

@Ant-ON Has this been fixed in your recent PR related to that topic? Can you have a :eyes: ?

[Ant-ON]

@Nightwalker-87 I do not know the reasons for this behavior. Most likely the problem is not solved

[Nightwalker-87]

@gszy Are you aware of any observed inconsistencies related to this topic? Is there any useful approach you can suggest?

[gszy]

I haven’t tried remote disassembly yet, the basic functionality—breakpoints, stepping through the code—seemed to just work last time I used it. I second @xor-gate:

Maybe there is something wrong with the GDB remote protocol on the st-util side.

I have zero experience with this protocol, so no suggestions for now. Was anyone able to reproduce this issue?

[Nightwalker-87]

I assume that if that was the case (GDB remote protocol) it would have been fixed there by now, but that's just an educated guess really...

[Nightwalker-87]

@rimio Are you still there despite of the time passed?

[rimio]

@rimio Are you still there despite of the time passed?

@Nightwalker-87 Still here, sorry I missed the mention.

I'll try to dig up the devboard I was using at that time from the 'tronics boxes. If I find it, I'll happily test it out.

Any branch in particular you'd like me to test?

[Nightwalker-87]

Hi @rimio, eh good question - We may probably want to go through release by release starting from v1.5.0 to investigate if the issue is somehow version-related. You may then try later versions of the gdb 7.x branch and 8.x or even 9.x to see if that makes any difference. The general task should be to try to allocate the cause either to gdb or to the stlink toolset before doing any further investigations.

[rimio]

@Nightwalker-87 Unfortunately I do not have any Lxxx devboards any more (although I only tried the L152RE at that time). I'll query some friends and see if they have any. If I find one I'll report back.

[Nightwalker-87]

This issue is now closed due to inactivity. Please also note that any version prior to v1.7.0 is unsupported according to our #Security Policy. Should the problem persist, please retry with the latest version in the develop branch. If this is the case, one should then open a new ticket.