Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Issues when use stlink with recent gdb #90

Open
TerryGuo opened this Issue · 1 comment

2 participants

@TerryGuo

Hi,

Based on the recent gdb trunk, I cross built a gdb for target arm-none-eabi. When use this gdb with stlink for STM32F4 discovery board, I ran into some problems when check the target registers in gdb. The first one is there is no xpsr register and the second one is there are legacy FPA registers displayed even my board is based on M4 processor.

After some investigations, I found the issues are because there are some mismatches between gdb and stlink. One is that the stlink can't reply host gdb a target.xml file to introduce the target registers layout. Another is that the g packet reply of stlink only contains registers r0~r15, the xpsr isn't included.

In my opinion, the stlink is a pretty helpful tool when work with ST boards. So can the stlink maintainers please address those mismatches? The possible solutions are:
1) Enhance the stlink to return standard xml file to host gdb.
2) Extend the g packet reply to include xpsr registers.

Best regards,
Terry

PS. Investigation on gdb trunk:
When the gdb server doesn't reply target.xml, the host gdb will guess target register information form the length of g packet reply. Currently the three kinds of length are supported: the size of (r0~r15 + xpsr), the size of (r0~r15 + f0~f7 + fps + xpsr) and the size of (r0~r15 + xpsr + d0~d15 + fpscr). If none of them are matched, the default arm architecture register layout will be used, which is r0~r15 + cpsr + f0~f7 + fps.

@prattmic

This has all been fixed in pull request #101, except for g packets returning the xpsr. I could add that if that is what GDB expects. I was unsure which registers were considered "general".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.