I have used GDB in linux to debug C programs effortlessly in user space. Now, I am working on kernel space modules and I thought GDB would work the same way. However, the run command does not work for the .ko file, and I don't think it should. That being said, how does one use GDB for kernel modules? I tried several examples I found on other sites:
(gdb) set solib-search-path my_module.ko
Supposedly, this was supposed to load the symbols from the module code, but nothing happened. Can anyone provide some insight?
I don't think you can easily use GDB to debug kernel modules
Use KGDB instead:
http://kgdb.linsyssoft.com/intro.htm
Related
I would like to see how Bash implements command line argument parsing and stepping through the code as it parses some trivial command should be a good way to do that. How do I set this up? Bash is normally run with
./configure
make
which creates a bash executable in the top level directory of the source code. I wanted to run that executable though GDB but it doesn't support M1 Macs so I was thinking to do it through VS Code but I don't know where to start.
To set up C/C++ debugging on VS Code, create a .vscode/launch.json file and fill in the arguments with whatever you need. See the docs here: https://code.visualstudio.com/docs/cpp/launch-json-reference.
That being said, VS Code's C/C++ debugger just hooks into an existing debugger like GDB or LLDB. If GDB can't debug your program, try LLDB (might require building Bash with LLVM instead of GCC- not 100% sure). If that's not an option, you might be out of luck with this exact question.
For setup with LLDB, see How to debug in VS Code using lldb?.
Let me preface this, I am very new to linux and to working on a non-IDE based setup.
I am trying to debug a very simple C program using vs code version 1.55
I unloaded all modules beforehand, so vs code can load appropriate default gcc & gdb versions (which it did, GCC 8.2)
I am following the VS code getting started documentation for setting up and everything seems very straight forward until I try to debug.
I use the default settings as instructed, the file builds successfully but then I get the below
/usr/bin/gdb: symbol lookup error: /usr/bin/gdb: undefined symbol: PyUnicodeUCS4_FromEncodedObject
please note that I cannot rebuild python with ucs4 enabled as suggested in another thread as I have no root access. however I can change VS code version to an earlier one if this will help.
Thanks.
I think this issue is specific to my environment but I will post the answer anyway as it may face someone else.
So this for me was 2 separate issues:
First gdb doesn't start and second vs code can't start gdb.
To check if this is the case try to launch gdb from terminal (not vs code) by typing gdb in the terminal (after loading gdb if needed), I was receiving the error above
Solution to this part is this as T0maas thankfully suggested above
Steps for linux newbies:
ldd gdb (or /usr/bin/gdb) (with vs_code loaded)
from step one get the python library path
unload all modules
load gdb
LD_PRELOAD=<python path from 1>
bash -c "export LD_PRELOAD"
load vs_code
load gdb
After the above steps writing gdb in the terminal should start gdb
Part 2:
The rest of the problem was when I tried to launch debugging session through the GUI of vs_code (still produced the same error)
In the terminal (after loading gdb) type whereis gdb
For me this produced multiple directories the first of which was /usr/bin/gdb (this is the default used in vs_code launch.json)
Changing that directory in the launch.json file to a different one of the other directories solved the second part of the problem for me.
So, I am working with QEMU, and I have a system of plugins for it, that are using bunch of symbols from the main executable. Everything is working fine in Linux, but porting plugins to windows caused many inconveniences (expectedly).
At first, i struggled with linking against executable. In Linux all you need is an option -rdynamic, that is not presented in windows. Eventually, I found a solution to this problem here. So, I used --export-all-symbols linking option, and I was linking my plugins against an import library generated with -Wl,--out-implib. The result is a working qemu executable, and working plugins at the same time, all working as intended, except for gdb.
I am running gdb from MinGW64 shell like this: $ gdb --args ./qemu-system-i386w testdisk.qcow2 -monitor stdio
(gdb) break tcg-plugin.c:164
Breakpoint 1 at 0x410f1c: file C:/fromgit/plugins_test/qemu-work/tcg/tcg-plugin.c, line 164.
(gdb) run
But then i either get the following error: Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x410f1c
Command aborted.
Or it will start working, but none of breakpoints will be triggered, despite they definetely should.
I thought, that this may be caused by exporting all the symbols from qemu executable, so instead of using --export-all-symbols I qualified needed export symbols with __declspec(dllexport) attribute, but that didn't change anything. Furthermore, I discovered, that adding any export symbols at all to the executable will cause gdb to act faulty, the same way as described earlier.
It should be mentioned, that if I'm building just qemu, without any export symbols, I get an executable that works fine, and gdb is working fine with it.
So the question is - am I missing something? What can possibly cause gdb to not work?
For some reason, I'm trying to make a minimal Linux system which only has essential components to run. I succeeded in installing BusyBox on my system, but I am having trouble installing glibc on top of it.
I just followed the instructions on this site:
http://wiki.beyondlogic.org/index.php?title=Cross_Compiling_BusyBox_for_ARM
As per the instructions, all the libraries produced by glibc were put in the '/lib' directory. But when I tried to execute a dummy C program as follows
#include <stdio.h>
int main { printf ("hello\n"); }
the system printed a "not found" message. Presumably this message means the system cannot find the glibc libraries.
How can I make the system find the libraries in the '/lib' directory by default? If the Linux kernel already finds libraries from there by default, what could have been wrong?
The above program was put in the '/scratch' directory with the name 'a.out'. I tried to execute it inside the directory by typing './a.out'. Here is the result of 'ls' in the root directory
bin dev etc include lib linuxrc proc root sbin scratch sys usr
As I mentioned, all the glibc libraries are in the '/lib' directory.
The not found message is certainly not due to lack of libc (what exact commands did you type to get that?). Perhaps you have some PATH issue, and your shell (probably BusyBox) gave you that? Try typing the entire path of your executable....
If ldd(1) or strace(1) are available, you might want to use them.
You apparently want to undertake something very similar to Linux From Scratch.
You might be interested in musl-libc (it is an alternative to GNU glibc, perhaps slightly easier to build)
Stricto sensu, you cannot have a running system with just a bare Linux kernel, it needs at least some initial program (e.g. /sbin/init, or /bin/sh, or whatever you give thru init= thru GRUB or some other loader to your kernel)
BTW, your issue is certainly not a kernel issue, it could be some dynamic linking one (e.g. related to ld.so(8) or whatever "interpreter" is mentioned in your ELF executable, see elf(5)). When the kernel fails to execve(2) some file, it won't output on stderr, is is giving error notice thru errno(3) (as specified by the ABI)
Use objdump(1) & readelf(1) (perhaps the cross-build variants of them) on your executable to understand what is inside it.
I recommend to read more about Linux programming before undertaking such a route.
I want to know what libraries, external code were actually used during a program's execution. I am working with Inkscape's source code and interested in its command line function that converts svg to png. I want to strip out all its dependencies that's not needed in this execution path.
I am currently using gcov, but so far that only tells me about the Inkscape's code.
My development environment is Windows 2008, mingw gcc package.
Thanks.
Process Explorer will show you all the libraries loaded at runtime, both static and dynamic. It will also show you any handles actively touched during runtime.
You can also spawn and monitor processes from the UI, provided you have your path setup correctly.
Granted, if you have the source code, you can just search for link options during compile time, check the makefiles. For runtime, break point the LoadLibrary method in gdb. In addition, gdb also has an 'info sharedlibrary' command you can use.
If you have ldd under MinGW just use it:
ldd executable or you may use
objdump -p | grep DLL or even
gprof