Blackfin bfin-rtems-4.11-gdb compatibility with gdbproxy from Analog Devices

[Kolja Waschk]

I'm not sure if this belongs here, but anyway, since RTEMS tools don't come with their own bfin-gdbproxy, one probably wants to use the one from Analog Devices/blackfin.uclinux.org... and that doesn't work out of the box.

There are at least two inconsistencies:

1. The 'g' response from bfin-gdbproxy (from git, as of 2013-10-15) is rejected by bfin-rtems4.11-gdb because: "Remote 'g' packet reply is too long". It turns out that bfin-gdbproxy sends values for pseudo register CC and several more, which seem to be used for bfin-FDPIC architecture variant. Commenting out these from the gdb_regnum enum in gdbproxy:target_bfin_new.c fixes that. There should be either an option in gdbproxy to omit these extra registers or bfin-rtems4.11-gdb should learn about the FDPIC registers?

2. The bfin-rtems4.11-gdb emits "load failed" on every attempt to load an ELF via JTAG into the target. It does this after asking for memory-map XML and getting it. Commenting out the support for memory-map output in gdbproxy can be used as a workaround (in response to qSupported inquery). I'm not sure which of both tools does something inconsistent here.

Also see discussion at ADI: ​http://ez.analog.com/message/119679 "Current bfin-gdbproxy vs. bfin-rtems4.11 toolchain"

[Kolja Waschk]

An older, related discussion about gdbproxy/gdb on rtems-users:
​http://www.rtems.com/ml/rtems-users/2011/june/msg00029.html

[Gedare Bloom]

I've seen a similar problem on sparc64, but I don't think it is worth holding up a release to wait on a fix. Bumping milestone to post 4.11 releases, e.g. a dot release might address this.

[Chris Johns]

The 'g' failure is an issue in the gdb server. It needs to provide gdb with the XML to describe the registers. GDB patching to handle special registers is discouraged.