0

We've got this legacy Fortran code running on a board with an A9 processor, and I've noticed some funny behavior when using gdb. Threads continue to run when it is in all-stop mode, and it seems gdb crashes when you switch it to non-stop mode. It also can't do watchpoints on symbols in the Fortran code, not sure if that's due to the port or the binaries not belonging to the same toolchain. You can set a watchpoint on the address cast as a C type, however.

We've got toolchain binaries from CodeSourcery installed to the stage directory during the rootfs build, then as part of our application build Linaro binaries overwrite some of the libraries in the targetroot. The libraries that are overwritten are (some of?) the only ones needed by the application and the ones it is linked against (libstdc++, libgfortran, and libpthread).

Using either gdb from CodeSourcery or Linaro seems to function equivalently, though I didn't try setting hardware assisted watchpoints with the Linaro compiler. Neither seem to be configured to work outside the documented behavior, which unless I'm mistaken what I've observed runs counter to it.

So is this fine? I mean, it runs, but if gdb is at least slightly broken I don't know what other utilities would be. I'd like to see about making use of Eclipse+Photran and TCF Agent, and I was looking into where the CodeSourcery toolchain came from, which led me to Yocto. I've been trying some builds with Yocto at home, and I'm wondering if it's worth my time to bring in a VM with all of this set up to try run our application with the toolchain built into the rootfs from the ground up.

Probably too late to switch anything over but if I can just have a smoother environment under which to work then I can just toss the source back into our current solution when it's time to turn in a fix.

CANTPRO
  • 79
  • 9
  • Are you starting the app using `gdb` or is it already running and then you attach to it? What `gdb` options are used? – wallyk Jan 02 '15 at 02:47
  • Running the app with gdbserver, host options in .gdbinit are to add the paths to the shared objects for the above mentioned toolchain binaries and app libs, connect to the remote, and set a breakpoint. The sysroot path is left as it came out of the box, to the binaries that came with the BSP. That config gave me the most complete stack traces I could work out. I tried using symlinks in a directory as the sysroot to give the picture of the mix of binaries that actually wind up in the targetroot but I couldn't work that out. – CANTPRO Jan 02 '15 at 03:30
  • I was wondering if there was a selected option which kept other threads running. You might look at the output of `gdb --configuration` to see if there is anything amiss. – wallyk Jan 02 '15 at 03:42
  • 1
    Well, I tried the gdb that came with the hardware vendor's toolchain and the one that was built from Linaro. From what I can tell they were about the same. Linaro gdb didn't have a 'show config' and the one from the hardware vendor was configured to look for the CodeSourcery toolchain that was used to generate the one they shipped, which we don't have. Either way nothing that says it's configured to be non-stop by default. It turns out the Borland lib is just there for libpthread when running the software under MSVC, the Linaro libpthread is what is copied to the target. – CANTPRO Jan 03 '15 at 01:21

0 Answers0