Afer adding a symbol index to some debug symbol file I get a CRC mismatch on gdb:
warning: the debug information found in "/xxx/yyy/lib/debug/libzzz.so" does not match "target:/lib/libzzz.so" (CRC mismatch)
Is there are a general settings in gdb to disable all sanity checks while loading files?
There's no setting to disable the CRC check when loading a separate debug file.
Related
I use Goland ssh to write code. I fail to use debug mode in my project, the breakpoints turn into gray crossed circles and report error "executable doesn't containt debug information".
The error information is here.
This is the Run/Debug Configuration of my project
However, I still could use debug mode and set normal breakpoints in Testing file.
I met exactly the same problem just now.
Finally I find the reason is the function which I set breakpoint doesn't been called in the repo.
It's called by another repo, so compile and debug the repo that call this function can solve this problem.
The error "error layer=debugger error loading binary "/lib/x86_64-linux-gnu/libpthread.so.0": could not parse .eh_frame section: pointer encoding not supported 0x9b at 0x12e8" still exists, but the breakpoints won't turn into gray crossed circles.
please see this https://youtrack.jetbrains.com/issue/GO-13005 .
Next 2022.2 nightly build bundles delve which doesn't produce an error.
I'm currently trying to debug my kernel. My goal is to put a breakpoint in a new syscall that I am implementing. The kernel runs on a remote Imx6q board. I've setup the JTAG debugger and I can connect GDB to it and pause the execution.
My issue is whith debug symbols.
I've added those properties to my defconfig :
CONFIG_GDB_SCRIPTS=y
CONFIG_DEBUG_KERNEL=y
CONFIG_RANDOMIZE_BASE=n
CONFIG_FRAME_POINTER=y
CONFIG_KGDB=y
CONFIG_DEBUG_INFO=y
When I start a session :
(gdb) tar ext :3333
Remote debugging using :3333
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0xa7780ef0 in ?? ()
(gdb) c
Continuing.
I can attach a symbol file by hand, but it is required to provide an address to attach it.
(gdb) add-symbol-file /home/tlavocat/development/android/out/target/product/wandboard_qca/kernel-imx/kernel/sys.o
The address where /home/tlavocat/development/android/out/target/product/wandboard_qca/kernel-imx/kernel/sys.o has been loaded is missing
The function I want to stop in is this one :
wandboard_qca:/ # cat /proc/kallsyms | grep sys_keeper_get_state
c003e0ac T sys_keeper_get_state
And it is implemented in kernel/sys.c.
My question is, how can I attach my symbols correctly to the right address ?
Thank's for your answers
I simply needed to load le kernel binary.
file .out/target/product/wandboard_qca/kernel-imx/vmlinux
And then connect to the remote target.
I have some Cgo code that I'm linking into my Go binary. I've got Cgo running and building my code and wrapper. After some recent changes, I started getting a double-free in my C++ that I'm linking in. I've tried running my binary under lldb and it does trap the malloc panic, but the symbols are not especially useful.
In vanilla C or C++ I've used -g3 to get rich debugging symbols that includes variable names and source. This makes using lldb much more productive. However, I'm having some issues getting these symbols to show up in my go binary. I've noticed that in the backtrace my function appears as main'foo, where foo is the name of my function. There is no other debug info present though, all I get is a trace of assembly and memory pointers/registers.
I've tried invoking go build with CGO_CFLAGS="-g3" CGO_CXXFLAGS="-g3" but the binary still doesn't have the symbols. I've also tried adding -g3 to the CFLAGS/CXXFLAGS in my .go file where I set other flags (before import "C") but this doesn't seem to work either. I can't think of any other way to get this debugging info added into my binary - is there some Go-specific flag or build sequence that enables this?
I don't know how the process of go & C++ linking works. But a brief description of how debug information is handled on OS X might help you figure out where the debug information is being lost.
On OS X as on most systems, the debug information for an individual source file compile goes into the .o file made from it. You can verify that your .o file got debug information in a variety of ways, here's one:
lldb -o "image dump sections" Target.o --batch | grep DWARF
0x00000300 container [0x0000000000061538-0x0000000000782c77) rwx 0x00061cb8 0x0072173f 0x00000000 Target.o.__DWARF
0x00000009 dwarf-str [0x0000000000061538-0x00000000004eeabc) rwx 0x00061cb8 0x0048d584 0x02000000 Target.o.__DWARF.__debug_str
0x0000000a dwarf-loc [0x00000000004eeabc-0x00000000004ef493) rwx 0x004ef23c 0x000009d7 0x02000000 Target.o.__DWARF.__debug_loc
0x0000000b dwarf-abbrev [0x00000000004ef493-0x00000000004f09a7) rwx 0x004efc13 0x00001514 0x02000000 Target.o.__DWARF.__debug_abbrev
0x0000000c dwarf-info [0x00000000004f09a7-0x00000000006ea7f1) rwx 0x004f1127 0x001f9e4a 0x02000000 Target.o.__DWARF.__debug_info
0x0000000d dwarf-ranges [0x00000000006ea7f1-0x00000000006ec481) rwx 0x006eaf71 0x00001c90 0x02000000 Target.o.__DWARF.__debug_ranges
0x0000000e dwarf-macinfo [0x00000000006ec481-0x00000000006ec482) rwx 0x006ecc01 0x00000001 0x02000000 Target.o.__DWARF.__debug_macinfo
0x0000000f apple-names [0x00000000006ec482-0x000000000071134e) rwx 0x006ecc02 0x00024ecc 0x02000000 Target.o.__DWARF.__apple_names
0x00000010 apple-objc [0x000000000071134e-0x0000000000711372) rwx 0x00711ace 0x00000024 0x02000000 Target.o.__DWARF.__apple_objc
0x00000011 apple-namespaces [0x0000000000711372-0x00000000007116d6) rwx 0x00711af2 0x00000364 0x02000000 Target.o.__DWARF.__apple_namespac
0x00000012 apple-types [0x00000000007116d6-0x0000000000748797) rwx 0x00711e56 0x000370c1 0x02000000 Target.o.__DWARF.__apple_types
0x00000015 dwarf-line [0x000000000075d348-0x0000000000782c77) rwx 0x0075dac8 0x0002592f 0x02000000 Target.o.__DWARF.__debug_line
If you don't see anything here, then the compiler isn't emitting debug information...
The next step is specific to Darwin, instead of putting the debug information into the output of the link stage, the debug info is left in the .o files, and a "debug map" is inserted into the output image. That's how the debugger finds its way back to the .o files. You can see that by doing:
$ nm -ap <YourBinary> | grep OSO
you should see a list of all your .o files here. If you don't then at some point in the build process your binary is getting stripped (using at least strip -S) You have to find out when that is happening and not do that. Also check that the .o files are still where the entries you see from the command above say they are. It may be some part of the build process is moving them around, and the debugger can't find them anymore.
On my fedora box I have installed a lot of separate debug infos.
sudo dnf debuginfo-install <list of packets>
Now, if I debug some simple code it needs very long until some symbol is displayed or some values are printed. It is quite clear that is absolutly needed to evaluate all the installed symbol files to get all information.
But if I have a problem, say on a lib like goocanvas I only want to have my local debug smbols generated with my own compiled code with -g option and the only the debug infos for goocanvas libs.
How can that kind of selection be achieved? Only by renaming the folder of debug info files and generate a copy of needed ones? Maybe as a symlink? Or is there a common selection option anywhere?
You can skip all debug info from shared libraries and only load goocanvas lib symbols. Here is a sample of how to do it in gdb session:
[ ~]$ gdb -q /your/binary
(gdb) set auto-solib-add off
(gdb) start
Temporary breakpoint 1, 0x000055555564edd0 in main ()
(gdb) sharedlibrary goocanvas
From gdb doc:
If your program uses lots of shared libraries with debug info that
takes large amounts of memory, you can decrease the gdb memory
footprint by preventing it from automatically loading the symbols from
shared libraries. To that end, type set auto-solib-add off before
running the inferior, then load each library whose debug symbols you
do need with sharedlibrary regexp, where regexp is a regular
expression that matches the libraries whose symbols you want to be
loaded.
See also this related question: How to prevent GDB from loading debugging symbol for a (large) library?
My problem is the following: An application (namely eclipse) crashes on my machine, and shows the following error message:
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 16911 error_code 3 request_code 3 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Now what I want to do is to actually run gdb as suggested by the error message. However, I didn't succeed and no backtrace is displayed.
I haven't much experiences with debugging. Here is what I tried anyway:
1) Activate -dbgsym repositories
2) Install eclipse dbg symbols (command sudo apt-get install ^eclipse-.*dbgsym)
3) Install libgtk-3-0-dbg, libgtk2.0-0-dbg and all packages matched by ^libgdk.*dbg
4) Run gdb:
(gdb) file /usr/lib/eclipse/eclipse
Reading symbols from /usr/lib/eclipse/eclipse...
Reading symbols from /usr/lib/debug/.build-
id/c2/8e5f4ebdd67159093d8ee6e6daf58ab6fab94c.debug...done.
done.
(gdb) break gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
(gdb) run --sync
[Update] I also tried the following (without success):
1) - 3) same as above
4) Run gdb:
(gdb) file /usr/lib/eclipse/eclipse
Reading symbols from /usr/lib/eclipse/eclipse...
Reading symbols from /usr/lib/debug/.build-
id/c2/8e5f4ebdd67159093d8ee6e6daf58ab6fab94c.debug...done.
done.
(gdb) break main
Breakpoint 1 at 0x4010a0: file ../eclipseMain.c, line 101.
(gdb) run --sync
Starting program: /usr/lib/eclipse/eclipse --sync
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=2, argv=0x7fffffffdf18) at ../eclipseMain.c:101
101 ../eclipseMain.c: file or directory not found.
(gdb) break gdk_x_error
Function "gdk_x_error" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
(gdb) cont
[/Update]
Result:
When the application crashes, the output is the same as above, no additional info is displayed. I assume that my approach is wrong, or I've loaded the wrong debug symbols. (Because it says "gdk_x_error" not defined.)
[Update2]
When I type bt after the crash, it shows me No Stack.
[/Update2]
What can I do to get a meaningful backtrace? Any ideas?