[RTEMS Project] #2149: Blackfin bfin-rtems-4.11-gdb compatibility with gdbproxy from Analog Devices

[RTEMS trac]

#2149: Blackfin bfin-rtems-4.11-gdb compatibility with gdbproxy from Analog
Devices
----------------------+--------------------------
 Reporter:  rtemsdev  |       Owner:  gedare
     Type:  defect    |      Status:  accepted
 Priority:  normal    |   Milestone:  4.11.1
Component:  GDB       |     Version:  unspecified
 Severity:  normal    |  Resolution:
 Keywords:            |
----------------------+--------------------------
Changes (by gedare):

 * owner:  ralf.corsepius => gedare
 * status:  new => accepted
 * milestone:   => 4.11.1


Old description:

> 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"

New description:

 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"

--

Comment:

 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.

--
Ticket URL: <http://devel.rtems.org/ticket/2149#comment:2>
RTEMS Project <http://www.rtems.org/>
RTEMS Project