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?
Related
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.
How can I build and install a C program with debugging symbols on OS X?
I'm trying to build something (mutt) with debugging symbols on OS X, to help me track down a crash. I'm basically following the Homebrew formula for mutt in my build process. But no matter what I try, the resulting binary has no debugging symbols. I build it with CFLAGS='-g -O0' (after having also tried the default '-g -O2' in the Makefile). I can see when I see the make output go by that it is using these flags as it should be, and I don't see any strip or install -s invocations; but the resulting binary has no debugging symbols, as seen by trying to run it in gdb or lldb, or running dsymutil on it.
I'm trying to understand the Valgrind instructions on the matter; basically, they say that the linker on OS X doesn't actually put debug symbols that exist in the object files into the linked result -- I read that as saying you have to run dsymutil on the linked result, but I'm a little unsure as to whether that automatically pulls in the symbols from the object files, or if there's some way I need to specify them.
And even if I knew exactly how to use dsymutil here, I don't see that there are any debug symbols in any of the .o files.
Finally, I'm wondering if a "proper" installation, once I got the debugging symbols into the binary, would copy that .dSYM directory into /usr/local/bin along with mutt; or if it would go somewhere else. I know in Debian-based systems you can install specifically debuggable versions of libraries using the package manager, but I don't know if it's a best practice (or even a practice that's common) to actually install things with debug symbols in OS X. If nothing else, I can probably just run the debuggable binary from its build directory, so this doesn't seem like a big deal.
I've tried building with gcc and clang, with the same disappointing results.
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
I am using OSX 10.8.2 and gdb 6.3. I have to use both xcode 4.6.1 and xcode 3.
I have a simple c executable for which i am trying to attach gdb through command line. But i am not able to give break points. As soon as the gdb is attached i am getting the below lines.
unable to read unknown load command 0x2b
unable to read unknown load command 0x80000022
unable to read unknown load command 0x24
unable to read unknown load command 0x2a
I goggled it out and found that gdb 6.3 has few bugs for which above thing might be happening. so i thought of updating the gdb to 7.6. Even this is not happening.
Steps i did to install gdb 7.6
./congigure
make
make install
make is ending with below lines
make[8]: Nothing to be done for `all-am'.
make[1]: Nothing to be done for `all-target'.
make install with below lines
make[11]: Nothing to be done for `install-data-am'.
make[1]: Nothing to be done for `install-target'.
I want gdb which is supported by xcode 3,4.6 as well as in command line. Please help to resolve this.
They're just warnings, you're fine to ignore them. The gdb binary you're using didn't include the definitions of these load commands (LC_DYLD_INFO_ONLY, LC_VERSION_MIN_MACOSX, etc see /usr/include/mach-o/loader.h) and it's complaining about them when it parses the Mach-O binaries with them included. The gdb included in Xcode 4.6 will handle these without warning, fwiw.
As I can figure out with make command output your program is compiled and not changed. So you have to make clean your code and try again. Make sure that you are compiling the code with -g parameter of gcc to link the symbol table of C to the executable, in order to give to gdb the necessary parameters for debugging. So, you must to have a look at makefile.
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