I am working on a cirrus machine, having my C code profiled. I have Valgrind installed on it. But the output I get from --tool=callgrind is barely understandable, hence I want to use kcachegrind tool. But I am not able to find a link to install it on linux terminal/cirrus.
Cirrus is not the name of a machine is the name of the cluster you are trying to work on.
So once being there,
first you need to load the Valgrind module otherwise commands are not recognized by the compiler.
$ module load valgrind
Have a check here:
https://hpc-uit.readthedocs.io/en/latest/development/debugging.html
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.
I've got an error ".gdbinit: No such file or directory." when trying to debugging in Omnet++ 4.2.2 in Ubuntu 12.4. It seems that the debugger cannot find ".gdbinit", or the find the one not compatible. So where can I find ".gdbinit" in my PC, or where should I find the right version of it to replace? Any idea would be appreciated!
Danh
Hi all, I have alternative solution for my problem and would like to write here for those who need to refer later. Instead of using gdb we can use valgrind. As my understanding, it is pretty good tool to detect bug related to memory allocation. To use valgrind in Omnet, you must make sure to have it installed in your OS (e.g., in Ubuntu, just type sudo apt-get install valgrind). Then in Omnet IDE, simply choose Profile As.. instead of Debug As.. then choose Omnet++Simulation, then trace bugs in valgrind windows. I did find where my bug is by this way.
Thanks.
Danh
I am trying to view the contents of C++ STL Containers. I read here that the recent versions of gcc and gdb support pretty printing by default but when I tried to display a map I got the following:
Then, I tried to set up pretty printing according to this answer but still it shows the same output. Can someone please help me out? Thanks.
I am using Ubuntu 16.04, g++ 5.4.1, GDB 7.11.1 and python 2.7.12 (installed from their official sources).
It was stated in the other thread you mentioned that some versions of GDB work with Python 3 only.
That can be ruled out as possible reasons since you don't receive any errors as far as your description says.
Over at sourceware.org it is suggested that
You can extend gdb using the Python programming language. This feature is available only if gdb was configured using --with-python.
Not sure if you did because the guides you used don't mention it directly.
Mark was correct. I built my own version of gdb 8.0 with --with-python option but still I was not able to see container contents. gdb was showing all complex structure. So I followed Mark's suggestion.
You need to create a soft link (auto-load) in your gdb install directory.
If your gdb install directory is $HOME/gdb_install then
cd $HOME/gdb_install/share/gdb
ln -s /usr/share/gdb/auto-load auto-load
/usr/share/gdb/auto-load already exists on my Ubuntu installation. It's the gdb version 7.11.1.
After that gdb is showing container contents. Thanks Mark.
The gdb native to Ubuntu 16.04 should be able to pretty print a std::map; the python code which handles that is class StdMapPrinter in the following file from the libstdc++6 package:
/usr/share/gcc-5/python/libstdcxx/v6/printers.py
If your goal is to accomplish this with binaries you build from source, it might still be useful to get this working with the native Ubuntu packages first, as a basis for comparison. The likely reason pretty printers are not working in a gdb you built yourself is that libstdcxx/v6/printers.py (libstdcxx.v6.printers in the python namespace) is not where gdb expects to find it.
Also, the gdb native to Ubuntu 16.04 is linked against python3, not python2; one way to see that is in the output of
ldd /usr/bin/gdb
It appears that the libstdcxx.v6.printers native to Ubuntu 16.04 is intended to work with either python2 or python3.
If your native gdb binary is not already installed, you can use this:
apt install gdb
Is is possible to compile c++ code on linux using g++ and run the code on Mac OSX? I have a few c++ programs that use one .cpp file, a few .h files, and a MakeFile altogether that produces a .o file that I typically run through the terminal. However, I'd like to find a way to send only the executable to my partner's home mac so he may review my program locally. (I've also use a few of these programs for automated math calculations, so it would be very convenient to run locally). I understand OSX typically uses .app bundles, but I'm not extremely familiar with how this works. Will the .o file (or ./a.out that's more common around here) simply run on OSX? I'd rather not install xCode on this machine if I don't have to.
Thanks a ton
It is possible to compile C++ on Linux and produce an executable on OS X. However you have to compile the code in a special way, called 'cross compilation'. It's not particularly simple to set up cross compilation and you need certain files from the platform you're targeting.
It's much simpler to just compile directly on the target platform.
If the Mac has a recent version of OS X installed you can easily install the necessary command line tools: Just try to run one of them or run the command xcode-select --install and OS X will ask to install the command line tools. (This will install just the necessary tools for compilation on the command line, and not the entire Xcode applicaiton.)
I understand OSX typically uses .app bundles, but I'm not extremely familiar with how this works.
You don't need to worry about .app bundles for simple C++ programs. OS X can run regular executable files just like linux. (Though the executable file format is different: OS X uses the Mach-O format instead of Linux's ELF format.)
Will the .o file (or ./a.out that's more common around here) simply run on OSX?
.o files, called 'object' files, don't run on their own anyway; They have to be 'linked' into an executable file. The default name for executable files created by the gcc toolchain is 'a.out' (as specified in the POSIX standard).
If you set up cross compilation to OS X then, yes, you could produce a.out files that would just run on OS X. The a.out files you produce normally for Linux , i.e. without cross compilation, won't run on OS X.
I'd rather not install xCode on this machine if I don't have to.
Xcode doesn't run on Linux anyway, so you couldn't run it. Instead you'd get a version of gcc that cross-compiles to OS X, or you'd install a different compiler, clang (and linker, lld instead of ld or gold).
A simple answer to your question is no. You cannot compile a program under linux and expect it to run on MacOSX.
However, MacOSX is just another UNIX OS under the hood and you can build your project with Make and GCC. If your partner doesn't know how to do this, I would suggest asking him to let you SSH into his machine.
However, if you're building executable on a mac you will want to install XCode. Even if you're using GCC from brew.
Another alternative is have your partner install a linux VM. He can use oracles virtual box to install linux and run your code w/in macosx.
I would suggest you sign up at Amazon for a free EC2 (Elastic Compute Cloud) account and take the free Basic Linux box. Install and build your software on Linux on there and then let your partner log into it and run it using just ssh which is already on OSX anyway. So no need to install anything on his Mac.
That way there is no need to transfer files between yourselves and update stuff when you make changes - just one environment to manage and keep up to date that you can both access from anywhere, any time.
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!