[Bug 2149] New: Blackfin bfin-rtems-4.11-gdb compatibility with gdbproxy from Analog Devices
bugzilla-daemon at rtems.org
bugzilla-daemon at rtems.org
Tue Oct 15 17:25:50 UTC 2013
https://www.rtems.org/bugzilla/show_bug.cgi?id=2149
Bug #: 2149
Summary: Blackfin bfin-rtems-4.11-gdb compatibility with
gdbproxy from Analog Devices
Classification: Unclassified
Product: Tools
Version: unspecified
Platform: All
OS/Version: RTEMS
Status: NEW
Severity: normal
Priority: P3
Component: GDB
AssignedTo: ralf.corsepius at rtems.org
ReportedBy: rtemsdev at ixo.de
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"
--
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
More information about the bugs
mailing list