I am trying to debug the linux kernel right from the function start_kernel() in the linux kernel.
This is basically what I ve done
Downloaded the kernel source for 4.10 from kernel.org
After extracting the source:
make menuconfig : Changed the settings for kernel debugging
make -j4: compiled the kernel
Simply issued the command without any FS
qemu-system-x86_64 -kernel linux-4.10/arch/x86/boot/bzImage -append root=/dev/zero -s -S
The qemu stoped as it should:
Next in another terminal, i started gdb
gdb vmlinux : and the output is as follows
...
...
Reading symbols from vmlinux...done.
(gdb) target remote :1234
Remote debugging using :1234
0x0000fff0 in ??()
(gdb) list
1 /*
2 *
3 * Copyright (C) 1991, 1992 Linus Torvalds
4 *
5 * Enhanced CPU detection and feature setting code by Mike Jagdis
6 * and Martin Mares, November 1997.
7 */
8
9 .text
10 #include <linux/threads.h>
That means debug symbols are there.
Now when i use the command
(gdb) b start_kernel
Breakpoint 1 at 0xc1ba986e: file init/main.c, line 483.
And I hit c (continue), it doesn't hit the breakpoint.
What wrong am I doing?
Thanks
You should use hardware breakpoints instead of software breakpoints.
You can use hbreak to insert hardware breakpoints. hbreak and break have similar usages. Moreover, you can use help hbreak to show more information.
I guess that the reason why software breakpoints are not effective is that the INT3 instruction inserted by software breakpoints is covered when the kernel image is loaded after you continue the QEMU.
But some troubles will occur because the processor mode changes. This gives some useful answers.
Try to disable CONFIG_DEBUG_RODATA and CONFIG_RANDOMIZE_BASE.
Related
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]
OS version: macOs Mojave 10.14.2
gdb: 8.2.1 (install with brew install gdb)
I have codesign successfully with
codesign --entitlements gdb-entitlement.xml -fs gdb-cert $(which gdb)
I have simple code like this:
int main(int argc, char *argv[])
{
std::cout << "hello, world" << std::endl;
return 0;
}
gdb hang then
zhifandeMacBook-Pro:cpp-quick-start zhifan$ g++ -g main.cpp
zhifandeMacBook-Pro:cpp-quick-start zhifan$ gdb ./a.out
GNU gdb (GDB) 8.2.1
Copyright (C) 2018 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-apple-darwin18.2.0".
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 ./a.out...Reading symbols from /Users/zhifan/github/cpp-quick-start/a.out.dSYM/Contents/Resources/DWARF/a.out...done.
done.
(gdb) start
Temporary breakpoint 1 at 0x100000f54: file main.cpp, line 5.
Starting program: /Users/zhifan/github/cpp-quick-start/a.out
[New Thread 0x1903 of process 11780]
[New Thread 0x1a03 of process 11780]
During startup program terminated with signal ?, Unknown signal.
(gdb) set startup-with-shell off
(gdb) start
Temporary breakpoint 2 at 0x100000f54: file main.cpp, line 5.
Starting program: /Users/zhifan/github/cpp-quick-start/a.out
[New Thread 0x2707 of process 11806]
My gdb hang here( [New Thread 0x2707 of process 11806]) all the time..
I can't use 8.0.1 since the issue unknown load command 0x32
what else can I do?
Ok, from my experience within the past two years of coding with a MacBook Pro. I have never been successful with getting gdb to work correctly. macOS uses the Xcode Developer tools for compiling. These tools include lldb which is very similar to gdb.
Here is a website that can help a bit to do this.
https://lldb.llvm.org/lldb-gdb.html
This is a map that directly shows gdb tools and lldb tools.
Hope this helps.
I got gdb working on Mojave today by:
a) getting the latest gdb source archive (at time of writing, ftp://sourceware.org/pub/gdb/snapshots/current/gdb-weekly-8.2.50.20190212.tar.xz) - amongst other things, it adds handling for recognizing executables on Mac.
b) build gdb. I got errors for variable shadowing in darwin-nat.c so I edited the file and rebuilt.
c) follow steps in https://forward-in-code.blogspot.com/2018/11/mojave-vs-gdb.html
Voila!
(source: GDB on Mac/Mojave: During startup program terminated with signal ?, Unknown signal)
I couldn't agree more with #Tanner Breckenridge. gdb just doesn't work on my mac, no matter what I tried. Just use something else.
lldb seems good, and for anyone who prefers a debugger with gui like me, I suggest using Visual Studio Code or Xcode to debug your C program instead.
I have gdb installed on my machine. Today I have compiled another version of gdb that is running fine. Now I want to debug this new gdb using my older gdb. Please guide me in this regard. How can I know that how gdb reads symbols from the provided executable, how it inserts break points, handles function calls and other things.
Thanks.
Think easily; when you want to debug some program, you probably compile it with -g or -ggdb and run gdb, don't you?
Download gdb source.
Compile it with -ggdb
./configure --prefix=<where-to-install>
make CFLAGS="-ggdb" CXXFLAGS="-ggdb"
make install
Debug it!
gdb <where-to-install>/bin/gdb
I've never tried it (and never thought it), but it may work. (And it looks very interesting; I'm about to try it!)
Um, I've just tested it in cygwin, and figure out the problem that the debugger gdb's output and the debuggee gdb's output are mixed; I solved it by using gdbserver to debug.
# On terminal 1..
$ gdbserver localhost:1234 gdb-gdb/prefix/bin/gdb
Process gdb-gdb/prefix/bin/gdb created; pid = 972
Listening on port 1234
Remote debugging from host 127.0.0.1
GNU gdb (GDB) 7.7.1
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 "i686-pc-mingw32".
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".
(gdb) q
Child exited with status 0
GDBserver exiting
and
# On terminal 2..
$ gdb gdb-gdb/prefix/bin/gdb
GNU gdb (GDB) 7.8
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 "i686-pc-cygwin".
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 gdb-gdb/prefix/bin/gdb...done.
(gdb) target remote localhost:1234
Remote debugging using localhost:1234
0x7c93120f in ntdll!DbgBreakPoint ()
from /cygdrive/c/WINDOWS/system32/ntdll.dll
(gdb) c
Continuing.
[Inferior 1 (Remote target) exited normally]
(gdb)
Once the first gdb starts running after taking the new gdb as an input file it will become paused after showing the info message. At this point you can put a break point on the function of new gdb which you want to execute.
e.g break insert_breakpoints // the function used to insert break points.
Now execute: run
This will start the execution of the new loaded gdb. Use file command to provide any executable HelloWorld.c comiled with -g option (for building debugging symbols) to the new gdb.
Now insert break point any where in the HelloWorld executable i.e
break main
This break command will call the insert_breakpoints function of gdb used for the insertion of breakpoints at which we have previously placed a break point.
Now you can use backtrace or other commands for examining the function calls and other stuff like that.
Hope that will solve your problem.
#ikh I think that gdb by default is compiled with debugging symbols because issuing :
file /path/to/compiled/gdb gives:
ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0xd1c553318661f8b557f4c3640b02cee1ef512ac0, not stripped
Which means that it has debug info available in it.
Please correct me if I am wrong.
I'm using gdb on OSX, which seems to have neither the gcore nor generate-core-file commands:
$ gdb
GNU gdb 6.3.50-20050815 (Apple version gdb-1705) (Fri Jul 1 10:50:06 UTC 2011)
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 "x86_64-apple-darwin".
(gdb) gcore
Undefined command: "gcore". Try "help".
(gdb) generate-core-file
Undefined command: "generate-core-file". Try "help".
(gdb)
Given this, how might I go about generating a core dump, or something approximating one, via GDB?
(I suspect I can use dump memory, but that requires an address range, and I'm struggling to find the right info invocation to get the right memory range...)
Run lldb --attach-pid, then use the process save-core command to save the core. Note that the process will be paused right from when you attach to it, so be careful if it’s an important process.
$ lldb --attach-pid <pid>
(lldb) process attach --pid 76669
Process 76669 stopped
Executable module set to "/bin/bash".
Architecture set to: x86_64h-apple-macosx.
(lldb) process save-core "core"
mach_header: 0xfeedfacf 0x01000007 0x00000008 0x00000004 0x00000030 0x00000e08 0x00000000 0x00000000
...
Saving data for segment at 0x7fd455200000
...
See How to generate a core file for a crashed app in XCode + gdb?
Also, maybe a newer gdb has a gcore that works on MacOS. I don't know, but you could search around and find out.
I am attempting to use GDB to debug a Stellaris LM3S8962 Evaluation board using OpenOCD and the GNU ARM toolchain (installed with MacPorts), whenever I set the remote target in GDB it always returns "Malfomred response to offset query, qOffsets". Any ideas on what could be going wrong? Is there anything that I am missing?
[bcochran#narada arm]$ arm-none-eabi-gdb
GNU gdb (GDB) 7.3
Copyright (C) 2011 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 "--host=x86_64-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set remotebaud 115200
(gdb) set debug remote 1
(gdb) file ~/dev/eclipse_workspace/hello_world_arm/bin/main.axf
Reading symbols from /Users/bcochran/dev/eclipse_workspace/hello_world_arm/bin/main.axf...(no debugging symbols found)...done.
(gdb) target remote localhost:4444
Remote debugging using localhost:4444
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: {{}~Open On
Nak
Sending packet: $qSupported:qRelocInsn+#9a...putpkt: Junk: Chip Debugger
>
Ack
Packet received: qSupported:qRelocInsn+
Packet qSupported (supported-packets) is supported
...
Packet qAttached (query-attached) is supported
Sending packet: $qOffsets#4b...Ack
Packet received: qOffsets
Malformed response to offset query, qOffsets
Here is the openocd output... as soon as the malformed response comes across openocd drops the telnet connection...
[bcochran#narada bin]$ openocd -f ../openocd/luminary.cfg -f ../openocd/stellaris.cfg
Open On-Chip Debugger 0.6.0-dev-00014-g827057f (2011-08-09-22:02)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.berlios.de/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
500 kHz
Info : clock speed 500 kHz
Info : JTAG tap: lm3s.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : lm3s.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'telnet' connection from 4444
Error: error during read: Connection reset by peer
Info : dropped 'telnet' connection
Here are the version outputs of my arm-none-eabi-* toolchain...
[bcochran#narada tcl]$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/arm-none-eabi/4.6.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../gcc-4.6.1/configure --prefix=/opt/local --target=arm-none-eabi --enable-languages=c,objc,c++,obj-c++ --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/arm-none-eabi-gcc --with-system-zlib --disable-nls --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --enable-stage1-checking --enable-multilib --with-newlib --enable-interwork
Thread model: single
gcc version 4.6.1 (GCC)
[bcochran#narada tcl]$ arm-none-eabi-gdb -v
GNU gdb (GDB) 7.3
Copyright (C) 2011 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 "--host=x86_64-apple-darwin10.7.0 --target=arm-none-eabi".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
I am able to compile using the toolchain, and flash the resultant .bin file using OpenOCD. I have been unable to find a solution to the "malformed response" issue just by searching the web.
Thanks in advance for any advice or assistance!
UPDATES
Thanks to answers from #turbo-j and #guy-sirton, I was able to progress a bit further... The most helpful thus far was that I was indeed using the wrong port (4444 instead of 3333) but now I am getting the following whether I add -c "init" -c "halt" -c "reset halt" to my openocd command string or not:
(gdb) target remote localhost:3333
Remote debugging using localhost:3333
Remote 'g' packet reply is too long: 0080004000000000040000220f0000002833405451332abc009600a4d2b86092c0c118c03040d6f0284dbb93204b40c2000000000c010020ffffffff550400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000020000001
(this is right after the qOffsets req/resp, which now passes)
On the OpenOCD side:
Info : accepting 'gdb' connection from 3333
Warn : acknowledgment received, but no packet pending
Info : dropped 'gdb' connection
With sometimes a undefined debug reason 6 - target needs reset on the OpenOCD console...not sure what is going on now but it seems closer to functioning
UPDATES 2
It seems if I do not load the file 'main.axf' or 'main.o' I do not run into the Remote 'g' packet reply is too long but I get no symbols... I've noticed other websites deal primarily with the .elf extension. What is the difference? I'm using the "Hello World" example from StellarisWare which it generates main.axf, main.bin (flash writes and runs fine), main.d, main.o from the make command. Something odd about my Makefile?
Here is a patch like what #athquad mentioned. See his answer for more information. Thanks to him for efficiently pointing me at the right spot, and great shame indeed for offering a patch without providing it. :-P
http://pastebin.com/rdFF2eZd
Patch was made against openocd commit 631b80fd0835055bb385314f569f589b99d7441d
To use: (./configure options depend on jtag hardware)
git clone git://git.code.sf.net/p/openocd/code openocd
cd openocd
patch -p1 < /path/to/patch/file
./bootstrap
./configure --enable-maintainer-mode --enable-ft2232_libftdi
nice make && sudo make install
You used the wrong port. Use target remote localhost 3333 for the GDB-to-OpenOCD connection. The port 4444 is intended for human interaction via a terminal and can be used in addition to a GDB connection.
If you don't want to compile OpenOCD, as tacos' & atquad's answer, you can use an older release of the GNU ARM tool chain (7.2.5 is fine for example).
(0.4.0 and 0.5.0 windows precompiled are both giving this problem).
I have just encountered the same "'g' packet reply is too long" bug and traced it to its cause.
It seems that for a very long time GNU ARM tools have used an ARM model with 9 obsolete floating point registers. OpenOCD is wise to this and in response to GDB's register request supplies dummy values. However, recent eabi toolchains including GDB have come up to date and so your GDB no longer expects these registers - hence the message.
In the OpenOCD source I have patched armv7m_get_gdb_reg_list() in armv7m.c to make this work, but my patch isn't smart enough to know which GDB version is being used - it simply uses an #ifdef switch - so it would need a bit more work to integrate with the OpenOCD source code.
A patch could be available to anyone who wants.
I do a lot of remote debugging on ARM but with a different processor, OS, and toolchain :-) Nevertheless, here are some thoughts.
This suggestion:
openocd -f openocd.cfg -c "init" -c "halt" -c "reset halt"
Comes from here:
http://michaldemin.wordpress.com/2010/02/22/part-2-debugging-with-gdb-and-openocd/
Otherwise:
A mismatch in the remote gdb protocol between the remote and your gdb. You can try going to a different version of the toolchain. Google and find what works for others.
A communication issue. Try lower baud rate? Make sure the serial port parameters are sound.