I have been trying to debug and step into docker daemon code using gdb or cgdb on a Ubuntu 14.04 container running on host OS (ubuntu 14.04 OS). I have used -O0 -g flags while building the debug binaries within a container.
Version of go used in the container:
# go version
go version go1.4.3 linux/amd64
I am unable to step through the code using cgdb:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"... Reading symbols from bundles/1.9.0-dev/dynbinary/docker...done. (
gdb) b main.handleGlobalDaemonFlag
Breakpoint 1 at 0x497b30
(gdb) r daemon -D
Starting program: /go/src/github.com/docker/docker/bundles/1.9.0-dev/dynbinary/docker daemon -D
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff5a00700 (LWP 2775)]
[New Thread 0x7ffff51ff700 (LWP 2776)]
[New Thread 0x7ffff49fe700 (LWP 2777)]
Breakpoint 1, 0x0000000000497b30 in main.handleGlobalDaemonFlag ()
(gdb) n Single stepping until exit from function main.handleGlobalDaemonFlag, which has no line number information.
Breakpoint 1, 0x0000000000497b30 in main.handleGlobalDaemonFlag ()
(gdb) l 1 in /tmp/go-build212795923/github.com/docker/docker/pkg/term/_obj/_cgo_export.c
(gdb)
How to confirm that the built binaries are debug ? Can I use a tool readelf to read through the headers to confirm this ?
Should I be setting a GOPATH or GOROOT to a specific directory ?
root#6511af5b06c1:/go/src/github.com/docker/docker# echo $GOROOT
root#6511af5b06c1:/go/src/github.com/docker/docker# echo $GOPATH
/go:/go/src/github.com/docker/docker/vendor
Are there any other dependencies which could be missing on my environment ?
Related
Does gdb work in macOS Big Sur? I followed all installation instructions and got it codesigned. After I load a very simple code that's supposed to add two variables, it hangs forever after I set a breakpoint and type "run" (see output below). I have even tried to compile gdb from source.
Reading symbols from ./a.out...
Reading symbols from /Users/andya/Downloads/a.out.dSYM/Contents/Resources/DWARF/a.out...
(gdb) b 6
Breakpoint 1 at 0x100003e2f: file aa.f90, line 6.
(gdb) run
Starting program: /Users/andya/Downloads/a.out
[New Thread 0x5403 of process 45117]
I wrote a simple C program to print hello world. Then I ran it through
aarch64-linux-gnu-gcc -ohello hello.c -static -g3
gdb-multiarch hello
After this, I run and gdb encounters an internal error:
Reading symbols from hello...done.
(gdb) r
Starting program: /home/gt/hello
/build/gdb-GT4MLW/gdb-8.1/gdb/i387-tdep.c:592: internal-error: void i387_supply_fxsave(regcache*, int, const void*): Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
Here's the output of file hello:
hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.7.0, BuildID[sha1]=a...b, with debug_info, not stripped
This is my hello.c:
#include<stdio.h>
int main(){
printf("hello world");
return 0;
}
What am I doing wrong? What else do I need to do? I am running Ubuntu 18.04 on an x86_64 machine.
When I use gdb hello, I am unable to use breakpoints, I get this error:
Reading symbols from hello...done.
(gdb) break 4
Breakpoint 1 at 0x400404: file hello.c, line 4.
(gdb) r
Starting program: /home/gt/hello
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x400404
(gdb)
I am following the guide given on this page under the first section.
In order to run and debug your AArch64 executable, you (in general) need to run it on an AArch64 machine, or in an AArch64 emulator.
You might have some setup where qemu more or less transparently emulates aarch64 binaries for you - but that doesn't work quite as transparently for the debugger. In general you can run the debugger on one machine, connected over a network to a debugging server on a different machine, allowing you to debug a process running on the machine with the debugging server.
The guide you linked shows how to set up qemu to allow it to transparently emulate binaries as you execute them. That guide only shows executing, not debugging, but it has got a link "Debugging using GDB" that points to https://ubuntuforums.org/showthread.php?t=2010979&s=096fb05dbd59acbfc8542b71f4b590db&p=12061325#post12061325, where it is explained how to debug a process which executes within qemu emulation. This essentially amounts to the same remote debugging with a debugging server as I mentioned above.
The essential bits of this post is this:
# In a terminal
$ qemu-arm-static -g 10101 ./hello
# In a new terminal
$ gdb-multiarch
(gdb) target remote :10101
Remote debugging using :10101
[New Remote target]
[Switching to Remote target]
I am unable to launch Rust binaries with LLDB on Windows 10:
> cat test.rs
fn main() {
println!("hello");
}
> rustc --version --verbose
rustc 1.25.0 (84203cac6 2018-03-25)
binary: rustc
commit-hash: 84203cac67e65ca8640b8392348411098c856985
commit-date: 2018-03-25
host: x86_64-pc-windows-msvc
release: 1.25.0
LLVM version: 6.0
> rustc -g test.rs
> .\test.exe
hello
> lldb --version
lldb version 6.0.0 (https://github.com/llvm-mirror/lldb.git revision 38001b27c9f319a3112271ca44fa0e1912583570)
clang revision b3bac44cb354b63214b16fab24b5c0ffd392ec02
llvm revision bbbe81ad6ad6db7ccb332df1f1932a5589a7eeca
> lldb test.exe
(lldb) target create "test.exe"
Current executable set to 'test.exe' (x86_64).
(lldb) process launch
error: process launch failed: unknown error
LLDB works fine for other executables on my system, for example:
> lldb C:\Windows\system32\cmd.exe
(lldb) target create "C:\\Windows\\system32\\cmd.exe"
Current executable set to 'C:\Windows\system32\cmd.exe' (i686).
(lldb) process launch
Process 15944 launching
(lldb) Process 15944 launched: 'C:\Windows\system32\cmd.exe' (i686)
LLDB and Rust are both fresh installs.
Is there a way to get more information from LLDB about why it isn't working?
I do not believe you can use LLDB to debug a 64-bit Rust program on Windows.
The LLDB home page states:
Windows local user-space debugging for i386 (*)
(*) Support for Windows is under active development. Basic
functionality is expected to work, with functionality improving
rapidly.
And the LLDB extension for Visual Studio Code states (emphasis mine):
At the moment, Windows port of LLDB is known to work reliably only
with 32-bit binaries and DWARF debug info:
LLDB's support of MSVC .PDB debug info format is incomplete. Only DWARF debug info works reliably.
The 64-bit LLDB is very unstable, so I cannot recommend using it. Unfortunately, 32-bit debuggers are limited to debugging 32-bit
processes only.
In practice, the above means that for C++ programs, you'll need to
compile with i686 MinGW toolchain (not MSVC!). For Rust you'll need to
use i686-pc-windows-gnu.
Thus, at this point in time, I would not recommend attempting to use LLDB. Since you have installed the MSVC toolchain, I advise you to investigate installing something native, such as WinDbg:
Trying to debug an app running on freebsd using gdb - gdbserver. Somehow if I do a local debugging (using gdb on bsd) everything is going well however using the gdbserver (I run gdb and gdbserver on the same bsd machine) seems to fail in the initialization process before main.
my workflow is:
echo "int main(int argc, char** argv){return 0;}">main.cpp
clang++ -ggdb main.cpp
gdbserver localhost:2222 ./a.out
Same machine or different doesn't matter:
gdb
file a.out
target remote localhost:2222
break main
continue -> here everything is crashing (not gdbserver but app).
Thank you in advance :)
The output of my console is:
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd".
(gdb) file a.out
Reading symbols from a.out...done.
(gdb) target remote localhost:2222
Remote debugging using localhost:2222
0x0000000800602110 in ?? ()
(gdb) break main
Breakpoint 1 at 0x400770: file main.cpp, line 1.
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb)
Some additional information:
(gdb) backtrace
#0 0x0000000000000000 in ?? ()
#1 0x0000000200000000 in ?? ()
#2 0x0000000000400200 in ?? ()
#3 0x0000000000400510 in ?? ()
#4 0x00007fffffffeba0 in ?? ()
#5 0x00007fffffffeba8 in ?? ()
#6 0x00007fffffffebc0 in ?? ()
#7 0x000000000040023c in crt_noinit_tag ()
#8 0x000000080061e000 in ?? ()
#9 0x0000000000400248 in crt_noinit_tag ()
#10 0x00007fffffffedd8 in ?? ()
#11 0x00007fffffffebd0 in ?? ()
#12 0x0000000000000000 in ?? ()
(gdb) info sharedlibrary
From To Syms Read Shared Object Library
0x00000008008599c0 0x00000008008b2f58 Yes /usr/lib/libc++.so.1
0x0000000800ae4a20 0x0000000800af0a78 Yes /lib/libcxxrt.so.1
0x0000000800cfdcf0 0x0000000800d158a8 Yes /lib/libm.so.5
0x0000000800f5b780 0x00000008010673a8 Yes /lib/libc.so.7
0x00000008012cc150 0x00000008012d58e8 Yes /lib/libgcc_s.so.1
0x0000000800602110 0x0000000800615639 Yes /libexec/ld-elf.so.1
This issue is reproducible using FreeBSD 10.1 and the described steps.
For those who are looking to solve this problem:
Had a conversation with a maintainer of gdb in FreeBSD. The result is that in FreeBSD there is no gdbserver which can be used alone. Instead there is a remote debug server called ds2 which can be used instead. Unfortunately ds2 is not available in FreeBSD 10.1 but it is working well in the newer versions of FreeBSD. Tested it with gdb and it is working!!!.
I'm looking to debug the malloc and free routines used by libc. In order to do that I installed the following packages.
sudo apt-get install libc6-dbg
sudo apt-get install libc6:i386
sudo apt-get install libc6-dbg:i386
I'm on a 64-bit Ubuntu 15.04 machine and I'm debugging a i386 binary. I see the post here that seems to deal with a similar problem.
Inside gdb I check the location from which debug files are loaded and get this.
(gdb) show debug-file-directory
The directory where separate debug symbols are searched for is "/usr/lib/debug".
However, there is no indication that the debug symbols are being loaded. How could I fix this?
[EDIT]
I've tried this with both amd64 and i386 binaries and the results are the same. The binaries I'm debugging themselves do not have debugging symbols installed in them.
However, there is no indication ...
What indication are you looking for?
I am guessing that you did something like:
gdb ./a.out
(gdb) list malloc # complains about "no symbols loaded"
Do this instead:
gdb ./a.out
(gdb) start
# breakpoint 1 hit
(gdb) list __libc_malloc
Explanation: libc.so.6 and its debug symbols are not loaded (and therefore not visible) until the program actually starts.