I can speak from experience here. I have been an embedded developer for several years now and when I have had to debug software, I have been using a "drop-in" replacement as the debug binary instead of the release binary. That means, we built the release with -O2, and the debug with -g(gdb) -O0. I have been trying to get a bug fixed in my software since yesterday, but up to now, all I found was a broken binary due to my expectation. gdbserver said format/exec error for /usr/bin/.debug/foo. It took me a day to figure out using objdump and reading on material in this area that Yocto seems to generate the debug binary as _additional_ content to the release binary as opposed to be a drop-in replacement. While, I can see the point of it - at least now-, this has not been obvious to me losing relatively long time on it. Thereby, what I would advice is to extend the documentation here: http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html#platdev-gdb-remotedebug-launch-gdbserver With a concrete one-liner example how to use debug package (foo-dbg) with Yocto for debugging purposes, either when one uses gdbserver or gdb directly on the target. It is bonus point in my eyes to get 2 x one-liner examples for each of them. Currently, I am yet to figure out what exactly to do to achieve this, so I may be able to provide concrete examples in a follow-up comment, but it is yet to be seen. If someone can suggest an example, that would be great. Also, the aforementioned documentation section unfortunately misses mentioning anything about generated -dbg packages which are vital in this scenario in my opinion.
This is my commands that I ended up using, but I expect it to be pretty similar for any developers: Target: gdbserver 192.168.0.32:2345 auth -c testuser <password> user Host: ./tmp/sysroots/x86_64-linux/usr/bin/armv5te-foo-linux-gnueabi/cgdb -d ./tmp/sysroots/x86_64-linux/usr/bin/armv5te-foo-linux-gnueabi/arm-foo-linux-gnueabi-gdb -s ./tmp/work/armv5te-foo-linux-gnueabi/foo/$myver/packages-split/foo-dbg/usr/bin/.debug/foo -e ./tmp/work/armv5te-foo-linux-gnueabi/foo/$myver/packages-split/foo/usr/bin/foo -ex "tar rem 192.168.0.1:2345" The latter is quite ugly, but could be essentially made scriptable or alias, so it is not a big deal. The concept is however. Here is my recap: 1) foo-dbg is additional info (symbol table and source code), not replacement. 2) Options (-s symbol-file and -e executable) have to be used on the host since the debug package is not installed there into the sysroot for obvious reasons. 3) gdbserver remains as is without changes. It can be run on the target binary which is stripped, but the optimization level has to be the same as the debug binary. 4) If both are installed on the target, then there is no need to use the aforementioned options, since they will be recognized in their default locations. 5) If one tries to run gdb or gdbserver on the debug binary, that will end up in format/exec error since it is just meant to be the symbol file. This is known and expected, although not quite obvious for a newcomer.
Assigning to security due to accidental content being entered. At least, it will be less visible for the world (hopefully).
I spoke with Paul on this bug and there is more to it than I can get to for the upcoming 1.7 release. I am bumping the target out to 1.8. I am also setting the status to ACCEPTED. Scott
Setting this to 1.8 M2. I need some information from Paul Eggleton to proceed on this one. Adding self and Paul to CC list. Set milestone to 1.8 M2. Scott
I'm just marking this as NEW rather than NEEDINFO; it's just another task I need to look into.
Marking as resolved as the Dev manual has a comprehensive section on remote debugging here: https://www.yoctoproject.org/docs/3.1/dev-manual/dev-manual.html#platdev-gdb-remotedebug If something is still missing, please create a new bug with specific information.