如何为ARM交叉编译并在NetBeans的另一台计算机上调试？

Question

I am trying to set up a NetBeans x86_64 environment where I can write code and add breakpoints in the IDE, cross-compile for ARM, then run the binary on a raspberry pi (for now) running gdbserver.

A common option is to use a remote build host to build, run, and debug the binary, but I will eventually be working on an embedded device that will not have room for a development toolchain. I am using a pi right now to learn how I will compile and debug once the embedded machines arrive. Please do not suggest using a remote build host.

Right now, my best guess has been to replace the run command with ./run.sh "${OUTPUT_PATH}" , where run.sh is a small bash script that transfers the newly compiled binary to the pi, then runs gdbserver --debug localhost:6000 ~/app . There is a gdbserver plugin for NetBeans that I have been able to attach to, after NetBeans has transferred the binary and run gdbserver, but all that gives me is the stdout of gdb (which makes sense). What I want is setting and stepping through breakpoints using the IDE and watching variables change, but I can't seem to get that to work using this setup.

What is the right way to do this?

Answer 1

gdbserver --debug localhost:6000 ~/app

This doesn't match the invocation syntax documented for versions of gdbserver I'm familiar with, but even without knowing the form, the argument seems mistaken.

"localhost" always refers to the same computer, never another. So specifying "localhost" would imply you were going to run gdbserver and gdb on the same machine, which negates the whole point of using gdbserver .

It's unclear what your command causes gdbserver to do, but neither possibility is good.

• if it causes gdbserver to listen on the loopback interface rather than INADDR_ANY, then only programs running on the target itself will be able to contact the gdbserver process, which rules out the remote gdb.

• if it causes gdbserver to attempt to connect to an already running remote gdb , then that won't work either, as it will be attempting to connect to a non-existent local one.

Likely what you want to do is something like

target> gdbserver :6000 ~/app

devmachine>gdb build/app
gdb> target remote target_machine_ip:6000