#2149 assigned defect

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

Reported by: Kolja Waschk Owned by: Needs Funding
Priority: normal Milestone: Indefinite
Component: tool/gdb Version: 4.11
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description (last modified by Gedare)

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?
  1. 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"

Change History (6)

comment:1 Changed on Oct 15, 2013 at 4:45:00 PM by Kolja Waschk

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

comment:2 Changed on Nov 22, 2014 at 1:19:21 PM by Gedare

Description: modified (diff)
Milestone: 4.11.1
Owner: changed from Ralf Corsepius to Gedare
Status: newaccepted

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.

comment:3 Changed on Nov 23, 2014 at 3:15:45 PM by Joel Sherrill

Version: unknown4.11

comment:4 Changed on Jan 26, 2017 at 7:16:00 AM by Sebastian Huber

Milestone: 4.11.14.11.2

comment:5 Changed on Feb 15, 2017 at 4:03:01 PM by Gedare

Description: modified (diff)
Milestone: 4.11.2Indefinite
Owner: changed from Gedare to Needs Funding
Status: acceptedassigned

comment:6 Changed on Feb 16, 2017 at 1:21:41 AM by 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.

Note: See TracTickets for help on using tickets.