Current bfin-gdbproxy vs. bfin-rtems4.11 toolchain

Hi,

I'm trying to load and start an ELF built with bfin-rtems4.11 toolchain (built from source), using a bfin-gdbproxy from either old 2010R1-RC4 binary distribution or built from most current GIT HEAD (as of today, 2013-10-08). Host runs 64-bit Ubuntu 13.04, together with various gdb variants (bfin-elf-gdb 6.6 from 210R1-RC4 or bfin-rtems4.11-gdb 7.6).

The combination of "old" bfin-elf-gdb and matching gdbproxy can load and start the ELF, but is only of little use for me because it doesn't understand the DWARF 4 debug info that bfin-rtems4.11 toolchain has in all its libraries and by default in the compiled application.

The current  gdbproxy chokes on my custom board, which has a PHY (dp83849i) before BF537 DSP in its JTAG chain. A segmentation fault occurs in urjtag/src/bfin/bfin.c bfin_set_scan where PART_SCAN accesses part->params without checking for NULL beforehand.

After implementing a workaround (code from older revision) in that UrJTAG code, it can talk to the DSP, but cannot correctly communicate with bfin-rtems4.11-gdb 7.6: error messages like "Remote 'g' packet reply is too long" show that there's something wrong. Loading an ELF stops during first section.

Before I try further combinations and compilations of toolchains etc. I'd like to ask if maybe someone already has current RTEMS running and a suitable combination of gdb, gdbproxy etc.? Ideally, there's a bfin-gdbproxy variant that can be used with bfin-rtems4.11-gdb 7.6 somewhere?

Thanks for any hints in advance

Kolja

    •  Analog Employees 
    on Oct 10, 2013 11:55 PM over 7 years ago

    For what it's worth I haven't heard of any newer gdbproxy variants that might do the trick. Hopefully someone else might chime in with better news.

  • Hi,

    Better news: The gdbproxy from current blackfin.uclinux.org toolchain repository can be modified to work with current bfin-rtems4.11-gdb 7.6. However, I consider the following to be workarounds in gdbproxy:

    1. Fix the "'g' packet reply is too long" response: Remove the pseudo-registers from enum in gdbproxy/bfin_target_new.c ... CC is handled locally in gdb itself, the others are needed only for FDPIC. Maybe gdbproxy should get a commandline option to omit these. Or gdb 7.6 should be extended to understand bfin architecture with FDPIC.
    2. Fix a "load failed" error: Remove "memory-map" from list of supported queries (in response to qSupported command). Then gdb will not ask for it. In my test setup otherwise the map somehow would make the 'load' command fail.

    The UrJTAG workaround (mentioned in my initial post) is required probably only for JTAG chains with more than one part. I'll evaluate the patched gdbproxy in the next days and eventually work out a proper, lasting solution.

    Kolja

  • Filed at rtems.org Bugzilla as https://www.rtems.org/bugzilla/show_bug.cgi?id=2149  - however, it is yet unclear to me whether this can be best fixed in gdbproxy or gdb, and by whom...

  • it is yet unclear to me whether this can be best fixed in gdbproxy or gdb, and by whom...

    An extra command line option to disable support for the extra (pseudo) registers in ADI gdbproxy would be nice.

  • Hi Kolja,

    Thanks for all the investigation work you've put into this.

    Unfortunately, I don't think we're likely to have time to fully investigate the changes required to get gdbproxy working with more modern versions of GDB any time soon.

    Do the alterations you've made not allow you to proceed in the meantime? (other thread excluded)

    Stu