Duane, > Earlier I was asking about cortex support. > > Spen pointed me here: > > spen> openocd contains a few hacks (define ARMV7_GDB_HACKS in > spen> armv7m.h) that makes mainlinegdb behave better with the > spen> v7 arch. >
Sorry i have not had time to reply properly. > In other mail - > > SimonQian> I am using IAR EWARM 5.11 with STM32, it support > OpenOCD. But > SimonQian> ARMV7_GDB_HACKS in armv7m.h must be disabled. I > was told that > SimonQian> GDB doesn't support Cortex chips. > > I see no real reason why this should be a #DEFINE. > > I propose: > > (a) a configuration command that lets one enable or disable this. > > (b) The default value should T.B.D. > > Suggestions? > The problem is a bit of a pain really. on one side we have mainline gdb that requires ARMV7_GDB_HACKS defining. codesoucery will behave fine after the correct target.xml is sent - see below iar works fine as long as ARMV7_GDB_HACKS is not defined. currently in openocd we do not send any target.xml files. when gdb connects it asks what do you support via the 'qSupported' packet. at the moment we only reply with the target memory map. I have attached a small patch that will send the correct armv7 target.xml file to codesoucery gdb. mainline will reject it as an unknown type - org.gnu.gdb.arm.core-v7m. Other target xml files can be found in the gdb/features directory. The grand plan is to always send the target.xml file for all targets, arm7, arm9 etc. The bonus is we can send other things such as peripheral registers. For all this to work you will need an xml enabled gdb - configure with --with-libexpat Just not had time lately to finish the support, you are welcome to have a look. You will notice that i also send the older fp registers to gdb - this would not normally be required. It is because openocd hardcodes the arm registers - this will have to become dynamic to fully support the target.xml stuff. do not attempt to send a target.xml file to insight - its a good way of locking it up. A option to replace the ARMV7_GDB_HACKS define may be the best solution. If only gdb gave a result back from the qXfer:features:read: packet this could be automatic. as for your debugging problems. I have attached a stm32 config that i use. one thing i would recommend on the cortex - make sure you set the entry point in the linker script, eg. ENTRY(ResetISR) gdb will otherwise assume 0, which happens to be the initial stack pointer - causes a bit of confusion. Cheers Spen
cortex_gdb.patch
Description: Binary data
openocd.cfg
Description: Binary data
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
