We were able to move forward by using "docker exec -i <container_id> gdb", where a symbolic link to the actual toolchain's gdb was put into the container's /usr/bin. (Using the toolchain actual path to <arch_prefix>-gdb failed because eclipse seems to be using OSString to coerce the path to use windows delimiters and the container baulks at that).
gdb version check now works. Yay!
The next problem is with the final launch sequence, as the path to the executable/application/binary is checked and validated to be a Windows path. The container path will differ (it is using a bind mount to access the host workspace).
Error in final launch sequence
Failed to execute MI command:
-environment-cd C:/Users/<username>/<workspace_loc>/<project>
Error message from debugger back end:
C:/Users/<username>/<workspace_loc>/<project>: No such file or directory.
C:/Users/<username>/<workspace_loc>/<project>: No such file or directory.
Ideas for next steps? We have been using "Local", when we might need to use "Remote" debugging, but then we get to questions of protocol for communicating to the container (SSH/TCP assumptions in Remote debugging don't apply here).
We also tried putting a .gdbinit in ~/ inside the container to override -environment-cd but the above error happens before .gdbinit is resolved. Somewhere in MI Session initialization. In our case "gdbserver" is OpenOCD running native on (Win/Mac/Linux) host and "gdb" is running inside the container...for the reasons Brian already mentioned.
Regards,
Tim (Intel)