I'm used to running gdb like so:
$ gdb --args exe --lots --of --flags -a -b -c d e
...
(gdb) r
Is there an equivalent for lldb?
Yes, it's just -- instead of --args. From the help:
lldb -v [[--] <PROGRAM-ARG-1> [<PROGRAM_ARG-2> ...]]
Thus:
$ lldb -- exe --lots --of --flags -a -b -c d e
You can also start lldb first and use:
(lldb) settings set target.run-args 1 2 3
(lldb) run
or:
(lldb) process launch -- <args>
Related
I need to launch 2 executables (program1 and program2) with the same mpirun (mpich) command, and I'm trying to debug program1 with gdb. I use this command:
mpirun -n 1 gdb program1 : -n 1 program2
The command correctly opens the gdb console, but if I set a breakpoint somewhere after mpi_init, the screen gets flooded with the standard output of program2. Is there a simple way to redirect the standard output of program2 (only program2) to a file?
My fast solution was to hard-code a cut of stdout in program2, but I'm sure there must be a more elegant one ...
You could try this:
create a wrapper.sh that redirect the stdout and stderr to the file output :
cat > wrapper.sh << EOF
#!/bin/bash
\$* 1>>output 2>&1
EOF
make it executable
chmod +x wrapper.sh
mpirun with the wrapper
mpirun -n 1 gdb program1 : -n 1 ./wrapper.sh program2
The context
Consider the following file
$ cat main.cpp
int main() {return 0;}
I can list all the available functions by executing
$ g++ -g main.cpp && gdb -q -batch -ex 'info functions -n' a.out
All defined functions:
File main.cpp:
1: int main();
When executing start before executing info functions more than 1000 functions are listed (see below)
g++ -g main.cpp && \
gdb -q -batch -ex 'start' -ex 'info functions -n' a.out | \
head -n 10
Temporary breakpoint 1 at 0x111d: file main.cpp, line 1.
Temporary breakpoint 1, main () at main.cpp:1
1 int main() {return 0;}
All defined functions:
File /build/gcc/src/gcc-build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/allocated_ptr.h:
70: void std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<std::filesystem::__cxx11::filesystem_error::_Impl, std::allocator<std::filesystem::__cxx11::filesystem_error::_Impl>, (__gnu_cxx::_Lock_policy)2> > >::~__allocated_ptr();
70: void std::__allocated_ptr<std::allocator<std::_Sp_counted_ptr_inplace<std::filesystem::filesystem_error::_Impl, std::allocator<std::filesystem::filesystem_error::_Impl>, (__gnu_cxx::_Lock_policy)2> > >::~__allocated_ptr();
As seen below, the total number of lines printed is so, apparently, more than 1000 functions are being listed
g++ -g main.cpp && gdb -q -batch -ex 'start' -ex 'info functions -n' a.out | wc -l
4436
The question
As we can see above, the main.cpp file does not contain any function, so why is gdb listing those functions when the start command has been executed before but not when start hasn't been executed?
Additional context
As suggested in one of the comments of this question, here's the output of executing info shared after start has been executed
g++ -g main.cpp && gdb -q -batch -ex 'start' -ex 'info shared' a.out
Temporary breakpoint 1 at 0x111d: file main.cpp, line 1.
Temporary breakpoint 1, main () at main.cpp:1
1 int main() {return 0;}
From To Syms Read Shared Object Library
0x00007ffff7fd2090 0x00007ffff7ff2746 Yes (*) /lib64/ld-linux-x86-64.so.2
0x00007ffff7e4c040 0x00007ffff7f37b52 Yes /usr/lib/libstdc++.so.6
0x00007ffff7c7f3b0 0x00007ffff7d1a658 Yes (*) /usr/lib/libm.so.6
0x00007ffff7c59020 0x00007ffff7c69ca5 Yes /usr/lib/libgcc_s.so.1
0x00007ffff7ab3650 0x00007ffff7bfe6bd Yes (*) /usr/lib/libc.so.6
(*): Shared library is missing debugging information.
main.cpp file does not contain any function, so why is gdb listing those functions when the start command has been executed before but not when start hasn't been executed?
Before start, GDB reads symbols (and debug info) only for the main executable.
After start, a dynamically linked executable loads shared libraries (seen in info shared), and GDB (by default) reads symbol tables and debug info for each of them. And since these libraries contain hundreds of functions, GDB knows about all of them.
You can prevent this with set auto-solib-add off, but usually you don't want to do that. If you do, and your program crashes in e.g. abort, GDB will not know where you crashed unless you manually add the symbols back using sharedlibrary or add-symbol-file command.
I have a issue with gdb printf in version 9.1
echo -e '#include<stdio.h> \n int main(){ \n printf("Hello"); \n }' > test.c
gcc -g test.c -o test
echo 'break test.c:4' > test.gdb
echo 'run' >> test.gdb
echo 'set $aux = (char*)malloc(256)' >> test.gdb
echo 'set $e = strcpy($aux, "abc")' >> test.gdb
echo 'printf "%s", $aux' >> test.gdb
gdb --batch --command=test.gdb test
Output with gdb 9.1:
Breakpoint 1 at 0x1167: file test.c, line 4.
Breakpoint 1, main () at test.c:4
4 }
�e���
Expected output (same as gdb v8):
Breakpoint 1 at 0x1167: file test.c, line 4.
Breakpoint 1, main () at test.c:4
4 }
abc
I've checked charset, but it seems ok.
Any idea about that?
This is Bug 25650 - GDB can't 'printf' a convenience variable holding an inferior address, fixed in gdb 9.2.
If you can't upgrade to gdb 9.2 but can recompile your existing distro's gdb 9.1, there is a two-line patch.
On Ubuntu 20.04, which comes with gdb 9.1-0ubuntu1:
run apt build-dep gdb to haul in the packages needed to build gdb from source
run apt install dpkg-dev (to get /usr/bin/dpkg-source)
uncomment the deb-src lines in /etc/apt/sources.list
run apt update
cd to an empty directory and run apt source gdb . Doing this in a fresh new directory will make it easier to clean things up after the compilation.
cd to gdb-9.1 and apply the patch to gdb/printcmd.c
build and install gdb. For example, to put it in /usr/local/bin, the default, you'd run
mkdir build
cd build
../configure
make
make install
Can I get gdb to automatically load the binary that's specified in the core file?
Given a core file I now usually do:
gdb -c corefile
GNU gdb 6.8
...
Core was generated by `/path/to/binary'
Then i copy-paste that and run:
gdb -c corefile /path/to/binary
It seems like an unnecessary two-step process and yet I don't seen an obvious way of doing it based on the man page. Am I missing something?
You could just script it?
#!/bin/bash
gdb "`file "$1" | awk -F \' '{print $2}'`" "$1"
This is what I usually endup doing:
var=$(file corefile)
echo ${var##*from}
gdc() {
gdb -c "$1" "$(file "$1" | sed -r -e "s#.*execfn: '([^\']+)'.*#\1#")"
}
$ gdc corefile
Suppose I'm in gdb memcached,but want to run it as memcached -d -u root -m 50 -c 1024 -p 11051.
How to do this?
On the gdb prompt, juste type
run -d -u root -m 50 -c 1024 -p 11051
Alternativerly, you can also use the args parameter:
(gdb) help set args
Set argument list to give program being debugged when it is started.
Follow this command with any number of args, to be passed to the program.
so in your case:
set args -d -u root -m 50 -c 1024 -p 11051
run (or) start