Please clarify ..
I have a multithreaded 64 bit C process running on sun10 server. It is occupying 2.2 GB of RAM.
When I take the gcore and debug it, it is showing me "no symbol table" on GDB prompt. Hence i am not able to debug anything.
The binary is not stripped and compiled with -g gcc option .The gcore if of 32 bits.
Why the procress image is not showing any symbols ??
Thanks-
viva
Did you try to start gdb with both executable file and core dump file?
gdb executable core
This will load symbols from executable and memory dump from core.
As said in gdb manual,
Traditionally, core files contain only some parts of the address space of the process that generated them.
Related
I'm debugging the u-boot-spl linux boot-up process. To analyze the process I use qemu.
I want to follow both qemu and linux source with gdb (of course using two gdbs).
The FPGA board I'm modeling has only 8MB ram in place of DDR now.
I load linux kernel image and fdt on the ram. (the kernel image contains initramfs).
To debug(analyze) qemeu, I do (note the gdb is for debugging programs running on intel machine)
$ gdb qemu-5.1.0/build/aarch64-softmmu/qemu-system-aarch64
and then inside gdb, I do
(gdb) set args -machine
ab21q,gic-version=max,secure=true,virtualization=true -cpu cortex-a72
-smp 1 -kernel u-boot/spl/u-boot-spl -m 2048M -nographic -device loader,file=linux-5.4.21/arch/arm64/boot/Image,addr=0x80080000 -device
loader,file=linux-5.4.21/arch/arm64/boot/dts/arm/ab21m.dtb,addr=0x807fd000
-s -S
(gdb) layout src
(gdb) run
Then qemu runs inside gdb, and the gdbserver inside the virtual machine waits for another gdb to connect to its program (because of the -s and -S option). Now, I connect to the u-boot-spl program by this.(note the gdb is for debugging programs running on arm64 machine)
aarch64-none-elf-gdb u-boot/spl/u-boot-spl -x gdbsetup
The gdbsetup contains some breakpoints.
When I do 'run' inside the second gdb, with the breakpoints and step commands, I can follow the u-boot-spl and the following linux kernel and can do normal debug for the codes.(u-boot-spl and kernel).
Here is my problem. When the program is at a break point, for example when the linux kernel is at the start of setup_arch function, I want to examine the memory using physical address. But by this time, the mmu has been already setup and the PC value contains kernel virtual address. Of course I can know the __KIMAGE_VADDR so can calculate the corresponding physical address for a virtual address. But there is no way I can check memory using physical address in the second gdb window (the x command seems to go through mmu too). If I could access the physical address, it will be very helpful for writing some debug code. (In real FPGA board I cannot use the debugger yet, though I'll try to set it up soon).
When the second gdb is stopped at a break point, I cannot stop the first gdb and examine the variables in qemu code, the fist gdb seems to be just running. So my question is, how can stop the second gdb at a breakpoint and then stop the first gdb and examine the values in qemu?
I wrote a short boot code and tried to run it with Qemu with:
qemu-system-arm.exe -M versatilepb -cpu cortex-a9 -kernel boot.bin
I expected the code to be loaded to address 0x8400000 but qemu returned me the error
Trying to execute code outside RAM or ROM at 0x84000000
This usually means one of the following happened:
(1) You told QEMU to execute a kernel for the wrong machine type, and it crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere
This is almost always one of the first two, so check your command line and that you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with the -d debug options; in particular -d guest_errors will cause the log to include a dump of the guest register state at this point.
Execution cannot continue; stopping here.
So I guess my code has not yet started running because it is not loaded into the right place
What am I wrong about?
Thanks
You say "I expected the code to be loaded to address 0x8400000" but QEMU's error message says "0x84000000" which is not the same number (it has an extra 0). This suggests that you have a typo in your linker script or whatever is creating your boot.bin file. (I am assuming that boot.bin is an ELF file, which QEMU loads at the addresses the ELF file specifies, because otherwise it will be loaded into RAM anyhow on the assumption that it's a Linux kernel image capable of self-relocation.)
I am working with openvswitch on ubuntu 14.04 server. I can easily attach gdb with any of its binary files for debugging its various features but when it comes to its kernel module, I am not able to debug it as per my requirement.
I am using following steps to attach linux kernel with gdb:
1. gdb /tmp/vmlinux /proc/kcore
2. Adding a symbol File to GDB:
cd /sys/module/openvswitch/sections/
ls -A1
.cat .text .data .bss
3. in gdb - add-symbol-file datapath/linux/openvswitch.ko 0xf87a2000 -s .data 0xf87b4000 -s .bss 0xf87b4560
4. b vxlan_udp_encap_recv
but when I generate packets for testing ovs kernel module and step over it says "The program is not being run."
Note: I have confirmed all module symbols by running this command: nm root/ovs/_build-gcc/datapath/linux/openvswitch.ko = which prints all symbols. and lsmod also confirms the existence of ovs kernel module.
I want to make ovs module stop at specified break point after it receives a message from its user-space application on netlink socket for its detailed debugging as conveniently as it allows me to debug a user-space process. Please suggest me how do I resolve this problem or if there is any alternative. I'll be really grateful for any help or suggestion. Thank you!
To debug the kernel you need to use KGDB / KDB.
one possibility:
run the gdb server on the target machine. run gdb on another machine. recompile the target machine kernel with the -ggdb parameter on gcc. start both machines with the target machine running the kernel with all the -ggdb info. have all the source available on both machines. connect from the testing machine to the target machine. have the gdb server connect to the kernel ....
I try to debug some native code on Android with GBD. The code wasn't created by me and is not in an Android project, so I can't use the ndk-gdb tool. I use gdbserver on the android machine and connect to it from my mac with the normal GDB program. I try to load all the libraries (which should have symbols according to objdump tool), but gdb tells me that it does not load the symbols (according to the gdb command “info sharedLibrary”). These are the steps I took:
start gdbserver on Android machine
start GDB with the debug version of the binary
gdb symbols/system/bin/mediaserver
the following commands are executed in gdb itself
tell gdb where to look for the libraries with symbols
(gdb) set solib-search-path symbols/system/lib
tell gdb where to find the source files
(gdb) directory /sources
connect to remote target (Android machine)
(gdb) target remote 192.168.1.10:5039
GDB connects successfully to the running binary and I can pause and continue the execution. But it does not show me any debug information like function names or line numbers. It only shows adresses. When I check the status of the used libraries, I see that gdb thinks, they don’t have any symbols:
command in gdb:
(gdb) info sharedLibrary
From To Syms Read Shared Object Library
0x00003700 0x0000ff0c Yes /symbols/system/bin/linker
No libc.so
No libstdc++.so
No libm.so
No liblog.so
No libcutils.so
No libspeexresampler.so
No libaudioutils.so
No libgccdemangle.so
No libamplayer.so
Now for example the last library. When I check with the file command (not in gdb), it tells me that it is a not stripped library (the library is located in the "symbols/system/lib" folder).
file libamplayer.so
Output:
libamplayer.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked, not stripped
objdump command shows a lot of symbols in it (I don’t show the output because it’s very long). So why does gdb not recognise the symbols in this libraries? I thought, at least line numbers and function names are present in not stripped versions of libraries. Or am I wrong? It would be very nice if someone could give me more insight.
Thanks!
System info:
GDB Version: 7.3.1-gg2 on Mac OS X Mavericks
The code wasn't created by me and is not in an Android project, so I can't use the ndk-gdb tool.
Your conclusion does not at all follow. ndk-gdb should be able to debug any Android program, whether created as a "project" or via other means.
I use gdbserver on the android machine and connect to it from my mac with the normal GDB program.
The normal GDB is likely not configured for cross-debugging, and thus doesn't understand ARM binaries at all. I am surprised you get as far using it as you do.
I'm trying to use GDB to debug (to find an annoying segfault). When I run:
gdb ./filename
from the command line, I get the following error:
This GDB was configured as "i686-pc-linux-
gnu"..."/path/exec": not in executable
format: File format not recognized
When I execute:
file /path/executable/
I get the following info:
ELF 64-bit LSB executable, AMD x86-64,
version 1 (SYSV), for GNU/Linux 2.4.0,
dynamically linked (uses shared libs), not stripped
I am using GDB 6.1, and the executable is compiled with gcc version 3.4.6.
I'm a little out of my water in terms of using gdb, but as far as I can tell it should be working in this instance. Any ideas what's going wrong?
The executable is 64-bit (x86-64) and the debugger is a 32 bit (i686-pc-linux) build. You may need to install a 64-bit (x86-64) version of the debugger.
I'm not sure if this is your problem, but I faced this situation very often. The executable in the build tree, build by make/automake is not a binary, but a script, so you cannot use gdb with it. Try to install the application and change the directory, because else gdb tries to debug the script.
The question refers to "./filename" and to "/path/executable". Are these the same file?
If you are doing a post-mortem analysis, you would run:
gdb executable-file core-file
If you are going to ignore the core file, you would run:
gdb executable-file
In both cases, 'executable-file' means a pathname to the binary you want to debug. Most usually, that is actually a simple filename in the current directory, since you have the source code from your debug build there.
On Solaris, a 64-bit build of GDB is supposed to be able to debug both 32-bit and 64-bit executables (though I've had some issues with recent versions of GDB). I'm not sure of the converse - that a 32-bit GDB can necessarily debug 64-bit executables.
What you need to be checking, is really the bfd library. The binary file descriptor library is what binutils / gdb uses to actually parse and handle binaries (ELF/a.out etc..).
You can see the current supported platforms via objdump;
# objdump -H
objdump: supported targets: elf32-powerpc aixcoff-rs6000 elf32-powerpcle ppcboot elf64-powerpc elf64-powerpcle elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex
objdump: supported architectures: rs6000:6000 rs6000:rs1 rs6000:rsc rs6000:rs2 powerpc:common powerpc:common64 powerpc:603 powerpc:EC603e powerpc:604 powerpc:403 powerpc:601 powerpc:620 powerpc:630 powerpc:a35 powerpc:rs64ii powerpc:rs64iii powerpc:7400 powerpc:e500 powerpc:MPC8XX powerpc:750
The following PPC specific disassembler options are supported for use with
the -M switch:
booke|booke32|booke64 Disassemble the BookE instructions
e300 Disassemble the e300 instructions
e500|e500x2 Disassemble the e500 instructions
efs Disassemble the EFS instructions
power4 Disassemble the Power4 instructions
power5 Disassemble the Power5 instructions
power6 Disassemble the Power6 instructions
32 Do not disassemble 64-bit instructions
64 Allow disassembly of 64-bit instructions
It seems your GNU Debugger (gdb) doesn't support x86_64 architecture.
So try LLDB Debugger (lldb) which aims to replace it. It supports i386, x86-64 and ARM instruction sets.
It's available by default on BSD/OS X, on Linux install via: sudo apt-get install lldb (or use yum).
See: gdb to lldb command map page for more info.