I am working a project on zephyr OS and I want to debug my code. Does anyone know how to use GDB debugging tool with west flash or build? Generally to combine it with zephyr west in order to start debugging.
west debug
is probably what you are looking for. If it was executed successfully the gdb command prompt is active.
For arm64, please run: west build -t debugserver
and, in another terminal: gdb-multiarch zephyr.elf
zephyr.elf is the result of the compilation and it is located in ./build/zephyr/ folder.
Related
I am using Ubuntu 16.04 on x86_64 workstation, and I'm cross-compiling a small demo program in C++, and deploying it to an embedded linux target running ARM architecture (environment-setup-cortexa9hf-neon-poky-linux-gnueabi, arm-poky-linux-gnueabi-g++).
I am able to successfully do this which gives me a debug session on commandline:
Target:
rpm -ivh gdbserver-7.10.1-r0.cortexa9hf_neon.rpm
gdbserver :9091 ${APPNAME}
Host:
sudo apt-get install gdb-multiarch
gdb-multiarch $APPNAME
target remote 192.168.0.212:9091
...
I can now use gdb-multiarch on commandline!
However from here... I really want to be able to use one of the many gdb frontend tools to provide a GUI to set breakpoints and step through the code (akin to gdbgui, or using vscode and configuring for a debugger). Are there any gdb frontend tools that specifically support gdb-multiarch?
Any tool I try, I believe no matter what it uses base gdb executable and gives this error because of mismatched architecture:
target remote 192.168.0.212:9091
Remote debugging using 192.168.0.212:9091
warning: Architecture rejected target-supplied description
Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000070fdff7e00000000c0fafc76100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
UPDATE 1 --
I can kinda sorta get this to work using ddd tool:
ddd --eval-command="target remote $MY_TARGET_IP:9091" --debugger gdb-multiarch
However! This is ancient and buggy, and I can't set breakpoints in loaded .so's right now with this.
I tried gdbgui with its options to specify debugger, but that's not currently working either. I filed a feature request report here:
https://github.com/cs01/gdbgui/issues/237
I found a way using gdbgui, but it required me to rebuild gdb from source code against my specific remote target architecture. Details of how I got it to work are here:
https://github.com/cs01/gdbgui/issues/237
Important bits in case the above link breaks:
TLDR Solution:
I was trying to rely on a prebuild gdb-multiarch from ubuntu apt repos, which didn't work. When I decided to download gdb and rebuild from source while configuring for arm-linux-gnuabi target arch.
Build method:
downloaded latest gdb source code
unzip it, go into folder, and build it like this:
./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --target=arm-linux-gnuabi && make -j8 && sudo make install
Important to note that for my particular remote gdb server it's running on ARM so i had to say target=arm-linux-gnuabi in configure. GDB is building for my PC x86 arch, but it knows when debugging to recognize the target as ARM!
Now, arm-linux-gnuabi-gdb is installed by default to /usr/local/bin ... but you can instead provide prefix=<path> to where you want it to install in ./configure script above.
Using this, I was able to build a secondary copy of gdb called arm-linux-gnuabi-gdb which i could feed to gdbgui like this:
gdbgui -g arm-linux-gnuabi-gdb
From there, I can give gdb commands to connect to my remote gdbserver. I'm having to set breakpoints beforehand. My gdb commands are like this to set a few breakpoints:
set breakpoint pending on
break my_object.cpp:<line number for breakpoint>
b example_function_name
target remote <remote arm machine IP>:<gdbserver port>
c
Works great! This is leaps and bounds better than running gdb on commandline on my remote target.
the problem is already known, that gdb doesn't work with OS X Sierra anymore.
This is really annoying, since I researched already about the solution, and there were some solutions, but they apparently don't work anymore. I tried to use the .gdbinit file solution and the disable csrutil solution, both doesn't work.
Sooo my question is: Does anyone know how to fix it in 10.12.3 ?
Thank you very much!
Looks like there still isn't a solution to this. I don't think "use LLDB instead of GDB" is the ultimate solution. So I went ahead and built a fairly basic docker container which contains the very basics (g++ and gdb).
Here is the Docker Hub container, and the the Dockerfile is on this Github repo.
This solution at least allows you to use GDB on your Mac via a couple simple commands. And since the folder you're coding on is mounted, as soon as you hit save, all your changes appear automatically.
Hope this helps someone else out there.
So thanks to Basile Starynkevitch, who just gave me the idea to update gdb
SOLUTION:
You simply have to update gdb for the latest version (which is 7.12.1 currently). Assuming you have installed Homebrew:
That's what I did:
brew update
brew remove gdb
brew install gdb
It has now updated to the latest version.
Now codesign gdb again with the cert that you used before.
sudo killall taskgated
codesign -fs gdb-certi /usr/local/bin/gdb
launchctl load /System/Library/LaunchDaemons/com.apple.taskgated.plist
Last step is still to use the workaround to create the .gdbinit file:
nano ~/.gdbinit
-> set startup-with-shell off
Debugging works for me now :) (OS X Sierra 10.12.3 - gdb 7.12.1).
UPDATE:
Apparently it will fix certain problems, but not the whole problematic itself. It will still cause errors. Honestly, my solution: When you can: Switch to LLDB and another IDE (Netbeans does not support LLDB). Or use Linux. I currently use Ubuntu with a stick on my MacBook Pro.
None GDB 7.11 or 7.12.1 will not work on Sierra 10.12.4 In short it's because of Apple security upgrade. We need to wait for re-enabling when some new version will shows up.
Easy WA is to use LLDB as a debugger for now. Sample instructions here
Another LLDB instruction here
I found that gdb 7.12.1 did not work for me either. I do not think it includes the crucial commit 82b19a4d2f9c9e8d56f to gdb made on the 9th Nov 2016.
I was able to get the gdb 8.0 development branch to work, however.
Download with, e.g.
git clone --depth 1 --branch gdb-8.0-branch git://sourceware.org/git/binutils-gdb.git
Then go into the checked-out directory
cd binutils-gdb
I have macports so (a) wanted to link to macports libraries and (b) wanted to avoid putting stuff in /usr/local so configured with
./configure prefix=$HOME LDFLAGS="-L/opt/local/lib" CPPFLAGS="-I/opt/local/include"
make -j8
make install
=> puts gdb executable into ~/bin; (static) libraries into ~/lib; documentation into ~/share
Then follow André's tip above to do the code signing; though it will now be
codesign -fs gdb-certi ~/bin/gdb
Whenever I try to debug any program (i.e. a welcome message), I get this prompt. Any ideas how to run the debugger for C++ program?
I am using Macbook Pro OS X El Capitan (10.11.3)
For Mac OSX 10.5 and above,
Install Homebrew (if you don't have it already)
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Install GDB
brew install gdb
Go to https://sourceware.org/gdb/wiki/BuildingOnDarwin and follow the instructions to code sign the gdb binary.
If you're on Sierra, run the following command in your terminal
echo "set startup-with-shell off" >> ~/.gdbinit
Finally, run the following comamnd in your terminal
which gdb
Copy the output path from that command, (mine was /usr/local/bin/gdb) into the Debugger Command box in Netbeans and start debugging!
On Linux systems derived from debian, you have to install gdb
sudo apt-get install gdb
Then in debbuger command type
/usr/bin/gdb
More information of gdb can be found in GDB: The GNU Project Debugger
Make sure gdb is installed in your machine. you can do this by following
C:\cygwin64>setup-x86_64.exe -q -P gdb
after this, select gdb as a debugger in netbeans
gdb location
Use Synaptic to install gdb. This debugger is required for Netbeans.
On a Mac, I installed HomeBrew first, then followed this exactly on the Sierra OS. Worked perfectly. After Homebrew is installed, you have to create then sign your gdb certificate. Then select it in your IDE debugger section.
The instructions show how to select gdb in Eclipse, but I got it working in NetBeans by pushing the debugger button and typing in the file path in the popup (as mentioned in this document).
https://www.ics.uci.edu/~pattis/common/handouts/macmingweclipse/allexperimental/mac-gdb-install.html
The reason I need to set up a custom debugger is that the debugger simply doesn't work in eclipse: Error while launching command: gdb --version. I have installed the command line tool (late Oct version), and the solution here Set up g++ on OS X
doesn't work either.
I am trying trojanfoe's solution here:
debugger for c++ using eclipse on mac
but I am stuck:
(1) The gcc, gdb install finishes with an instruction to:
You will need to make sure /System/Library/LaunchDaemons/com.apple.taskgated.plist has the '-p' option ...
(for the ProgramArguments key)
But I can't edit this file, can't change its mode, how do I make sure it has -p option? (it only has -s in my mac)
(2) How do I set up the gdb debugger in eclipse c++ IDE? I know trojanfoe's solution has pointed to some websites, but it looks very confusing to me, so would appreciate some more details. Thank you.
I am using c++/eclipse kepler on mac, and I cannot debug any project. The error is "Error while launching command: gdb --version" Besides that, I can build and run my code using other libraries.
I searched a site that is similar to my problem: Debugger for C++ eclipse gives the following error. 'Launching program name' has encountered a ... Error while launching command: gdb --version
But what should I change if I am using a mac?
You can fix this by specifying the full path to gdb. You can do this separately for each debug configuration, and you can also set the default gdb location in the preferences under C/C++ > GDB. For example, if you installed gdb via Homebrew, then it's probably located under /usr/local/bin:
And here's a screenshot of the Preferences:
I still don't know why Eclipse can't find GDB even though it is on my path. I guess it doesn't use my .bash_profile or my .bashrc? You could try symlinking gdb into /usr/bin. Maybe Eclipse will look there.
Edit: I tried the symbolic link idea and now Eclipse can debug, but it crashes inexplicably while doing so! So, I guess... don't do that?
This guide from a UC Irvine Computer Science professor's page is a very well-written, detailed, and Mac-specfic description of all the steps involved in installing GDB, creating a certificate, signing GDB using that certificate, and finally configuring Eclipse. I was found this very helpful as someone unfamiliar with each of these steps.
GDB Installation on Mac OS X
I had the same problem. I solved it by:
Install a gdb - ( I used 7.8.1) - compile and install it. It got installed in usr/local/bin
Codesigning certificate
Open eclipse executable using sudo. Otherwise I still get the error.
I am on OS X.
Hope this helps.
I had this error too now, and spent more than an hour looking for it.
In my case, the path was correct, and eclipse seemed to fail to start "any" executable as debugger. (I tested with gksudo cat, but it clearly never got to effectively running it).
The final reason was that I had put in my eclipse.ini -Xms1G and -Xmx1G. It seemed to already use the full memory for the indexer, and trying to allocate some more memory to start the debugger failed with an "unkown" error. Removing the memory limitations fixed the issue.
Hope this helps someone
I had many difficulties making GDB to work on Eclipse. I tried LLDB instead and it worked like a charm:
https://wiki.eclipse.org/CDT/User/FAQ#How_do_I_get_the_LLDB_debugger.3F
This can be a more convenient alternative for Mac users.
Mac OS Sierra 10.13.6 gdb 8.0.1
had the same error as topic-starter.
first, I set the path as Neil Traft (here in the answers) explains to usr/local/bin/gdb;
But it didn't work.
I found these instructions:
https://gist.github.com/gravitylow/fb595186ce6068537a6e9da6d8b5b96d
and I discovered that I already had gdbcert1 in my System. So I followed everything from 7. Works!