UPDATE: unfortunately the "fix" I suggest below doesn't work :-( It seemed to work yesterday because the half-dozen times or so that I used it, the connection, coincidentally, was robust. But running it many many dozens of times today, I do see it failing. As does the cross-gdb binary supplied by ADI. So there's something wrong with the connection between openocd and gdb. Sometimes they connect just fine, other times something goes wrong. Probably an issue with the closed-source openocd binary, or an issue with the openocd configuration files for the JTAG or the target.
I'm working with a board from Analog Devices. Unfortunately it's not possible to use upstream openocd. You have to use the openocd binary that comes with their Developer's Kit.
Although I'm forced to use their openocd binary, I wanted to be able to use my own cross-gdb; one that I could build as part of my Yocto/OE-generated SDK. But whenever I tried connecting my cross-gdb (arm-oe-linux-gnueabi-gdb) to their openocd I would get errors, and further debugging wasn't possible.
I start their openocd and get the regular openocd information:
I then startup the arm-oe-linux-gnueabi-gdb that was built as part of the Yocto/OE SDK that I generated:
So far, so good. However, the moment I connect the two… In gdb I get:
and in openocd I get:
Searching the Internet for solutions I was excited to find that the gdb "set sysroot <path>" was supposed to solve my problems, but it didn't. However the "set solib-absolute-prefix <path>" did! Simply set this option to the absolute path of the Yocto/OE-generated rootfs and everything works again.
NOTE: both the init-sc589-ezkit.elf and the u-boot-sc589-ezkit binaries are the ones I have built via Yocto/OE. So it's possible to build and use your own cross-gdb, initializer (init-sc589-ezkit-elf), and u-boot that are built with Yocto/OE.
Notice, as well, that I still get those warnings about not being able to find dynamic linker breakpoints, but at least I'm able to proceed.