I just do not know the command to run multiple processes using GDB. The following does not work.
r -np 64 ./a.out -gdb
Sorry this may seem quite simple. But I did not find much useful document about debugging in MPI using gdb from the Internet.
As stated in the OpenMPI documentation, you can start xterm through mpirun/mpiexec which then starts your program:
mpirun -np 64 xterm -e gdb ./a.out
This will open 64 windows, each containing a gdb session. As it will be quite cumbersome to enter run in each terminal, you could try
mpirun -np 64 xterm -e gdb ./a.out -ex run
However, I strongly recommend to reduce the number of processes used to, say, four.
Related
C++ code compiled from a command line shell script runs much faster than when I use the same shell script from a Task:Run in VSCode. I successfully tried an echo command in the script to make sure VSCode was running the same script I use at the command line.
I know there are compiler settings in a .json file, but I don't see how to add a -O3 optimization switch, and since VSCode is running the same script I used at the command line I just don't get why it might be different.
I'm on a new M1 Mac and here's my script: clang++ -std=c++17 -O3 -o $1 $1.cpp && $1
The VSCode resulting speed is midway between the -O3 option and no optimization. Weird....
At first I thought it might be the terminal in VSCode but the code runs same slowness if I execute it at the external command line, so that's not it.
I found the answer. Turns out it's because VSC isn't Apple Silicon native yet and I'm on an M1 Mac. Anything I did from inside VSC, even the terminal window, forced the results to be x86_64 code, which runs 4x slower than the arm64 code I compile from outside VSC. Need to wait for the native version I guess.
I'm taking a course on Computer Organization and Assembly.
In class, we're learning MIPS. This is for the purpose of introducing basic concepts, like pipelining. We're writing a handful of simple MIPS programs for class.
I'm used to gdb for debugging and learning, and the debugger we use in class is SPIM. SPIM sucks. It allows me to step through a program, but it doesn't allow me to interactively execute MIPS instructions at an arbitrary point of execution. I am immediately tired of having to exit SPIM, edit the source, and run SPIM again, navigating to the desired point of execution, only to see I have to do it again because I made yet another mistake.
Or perhaps I am mistaken and SPIM does allow this. My instructor said that this feature is not supported, so I'm going off what he said. I googled around a bit and didn't find a workaround.
I have tried googling for interactive MIPS debuggers like gdb but I haven't found any. I'm aware that gdb can debug MIPS programs, but I don't have a MIPS machine to run MIPS programs on.
I run Ubuntu in VMware. How can I interactively debug MIPS programs, using gdb or otherwise?
Edit: found some reference material on Mips.com on their recommended Linux Toolchain.
You can use qemu as an emulator, gdb as a debugger and gcc as a compiler. It's universal tool-set to investigate different architectures.
For Ubuntu you can install dependencies with followed command (probably, list is not full for your system - it's up to you there):
sudo apt install gdb-multiarch qemu qemu-user gcc-multilib gcc-multilib-mips64-linux-gnuabi64
Now you can use gcc as a compiler.
$ cat code.c
#include<stdio.h>
int main()
{
printf("Hello world!\n");
return 0;
}
$ mips64-linux-gnuabi64-gcc code.c -static -g3
And start emulation in qemu with debug session:
$ qemu-mips64 -g 1234 ./a.out
In gdb-multiarch use the following routine:
symbol-file a.out
set arch mips:isa64
target remote :1234
b main
c
And here is your goal:
(gdb) x/5i main
0x120003850 <main>: daddiu sp,sp,-32
0x120003854 <main+4>: sd ra,24(sp)
0x120003858 <main+8>: sd s8,16(sp)
0x12000385c <main+12>: sd gp,8(sp)
0x120003860 <main+16>: move s8,sp
I believe, you can adapt it for your tasks. And MIPS arch is so various, as you can see in gdb set arch command.
I'm trying to debug a 32-bit executable on a 64-bit Ubuntu system. It runs just fine by itself from the command line, but when I try to use gdb, it hangs in ld-linux.so.2. Also, gdb works for the 64-bit version of the executable. Does anyone have a clue as to what I should try?
I just re-imaged a machine to Ubuntu 18.04.3, and I installed the multilib versions of gcc and g++.
Thanks in advance.
gdb <executable>
GNU gdb ...
This GDB was configured as "x86_64-linux-gnu"
...
Reading symbols from <executable>...done.
(gdb) show archi
The target architecture is set automatically (currently i386)
(gdb) break main
Breakpoint 1 at ...
(gdb) run
Starting program...
warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xfffffffff7fd9be0.
...
(7 of these)
[hangs...]
[In another terminal, ran 'kill -CONT <pid>']
Program received signal SIGCONT, Continued.
0xf7fd9be0 in ?? () from /lib/ld-linux.so.2
(gdb) cont
[hangs again...]
UPDATE: This problem has been fixed for Ubuntu in the gdb package version 8.1-0ubuntu3.2, so just upgrading your packages (sudo apt update && sudo apt upgrade) should help currently.
ORIGINAL ANSWER:
#EmployedRussian suggested in his edit to the question:
By downgrading from gdb=8.1-0ubuntu3.1 to gdb=8.1-0ubuntu3 the debugger started working again for me.
This also worked for me on Ubuntu 18.04.3. You should issue these commands:
sudo apt install gdb=8.1-0ubuntu3 # downgrade GDB to the working version
sudo apt-mark hold gdb # prevent upgrading (until the repository version is fixed)
I created a bug report for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200
You can click Does this bug affect you? if you have an Ubuntu account to get it fixed sooner.
Probably this gdb bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=23210
Try upgrading to the current GDB version (8.3.1). If Ubuntu doesn't offer a package for that, you can try compiling it yourself.
This is now fixed in 8.1-0ubuntu3.2 in bionic-updates: https://launchpad.net/ubuntu/+source/gdb/8.1-0ubuntu3.2
I understand from other SO threads that gdb can debug both 32bit and 64bit binaries on a 64bit architecture, but when I run it I have the following issue :
Starting program: /root/crackme-01
/bin/bash: /root/crackme-01: No such file or directory
During startup program exited with code 127.
Here is the result of file on the program :
crackme-01: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=9feb70a8647779984dc69b1e5c90bd757343fb29, stripped
Is there anything else I should do to debug it?
Thanks for your help.
GDB can only debug a program that can start by itself. In your case, the program couldn't start at all (not a single instruction was executed in user space for your process, the execve system call failed). This:
/bin/bash: /root/crackme-01: No such file or directory
is almost always caused by missing program interpreter. You can see the interpreter like so:
readelf -l /root/crackme-01 | grep interpreter
In your case, the interpreter is almost certainly /lib/ld-linux.so.2.
I was just missing the libraries
You were missing libc6:i386, which ld-linux.so.2 is part of.
I was just missing the libraries as explained here
I needed to install the 32bit libs with :
sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386
When trying to run gdb with a program, it seg faults while reading symbols.
When I run:
gdb /home/user/path/to/program.exe
I get:
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /home/user/path/to/program.exe...Segmentation fault (core dumped)
I suspect that the binary might be too large for gdb to load into memory. This error only occurs when I compile with -g (debug flag). Here's the difference in size of the binaries:
Compiled with
-release flag: 405 MB
-debug flag: 862 MB
Any ideas on other culprits of this segmentation fault? Or is there a way to increase the memory allowed for gdb? This turns out to be a very challenging problem to google.
I was having the same problem with gdb 7.9 on Ubuntu 15.04 x86_64, which I had installed simply using apt-get install gdb.
I solved the problem by compiling and installing a previous version: gdb 7.5.1.
I had to download a library (which I found out here) and I also had to run ./configure using some arguments (which I found out here). Everything else is straightforward.
Good luck.
Here are the commands:
$ cd
$ sudo apt-get install libncurses5-dev
$ wget ftp://sourceware.org/pub/gdb/releases/gdb-7.5.1.tar.gz
$ tar zxf gdb-7.5.1.tar.gz
$ cd gdb-7.5.1
$ sudo ./configure --disable-werror
$ sudo make
$ sudo make install
If you compile without the -g flag then you are not including debugging information in your executable, so when gdb loads there's much less information to load in.
If gdb segfaults during start up then this is a gdb bug, there's no executable that you should be able to pass to gdb that should cause a segfault, at worst you should get some error message.
You could try running gdb under gdb, (just do gdb --args gdb /home/user/path/to/program.exe) this will not help you much, but might give some insight into what is wrong with gdb, you could then file a gdb bug here: https://sourceware.org/bugzilla/enter_bug.cgi?product=gdb but this is only worth doing if you either have good steps to reproduce, or a backtrace from a crashed gdb.
Reinstalling gdb might help, but I wouldn't hold much hope of that solving the problem, unless you change the version of gdb you install, gdb itself is a pretty easy program to install, so pretty hard to get wrong.
You could also try building gdb from git, it's pretty easy, and the bug might have already been fixed, start from here: http://www.gnu.org/software/gdb/current/
If you extend your question with a backtrace from a crashed gdb then others might be able to offer you more of an insight into why this is crashing, but the blame is definitely with your version of gdb.