I am trying to debug a cross-compiled application with gdbserver. Unfortunately I get the following error on my host:
Reply contains invalid hex digit 59
Here's what I did:
compiled my application "line-generator" (which is just a test program) with gcc -ggdb3 -std=gnu89 flags (using -g instead of -ggdb3 didn't make any difference)
copy the executable to my embedded system. The exec can be executed there
started gdbserver 192.168.10.20:54320 line-generator on the embedded system
On the host I start gdb: gdb line-generator.gdb
(gdb) target remote 192.168.10.102:54320
Got this response on host:
Remote debugging using 192.168.10.102:54320
Reply contains invalid hex digit 59
On the server I got this:
Remote debugging from host 192.168.10.20
readchar: Got EOF
Remote side has terminated connection. GDBserver will reopen the connection.
Listening on port 54320
I have never used gdb remotely so maybe I am running into a beginner's issue so every response might help.
edit: My gdbserver was provided by the manufacturer of the embedded hardware.
I found out that remote-debugging a cross-compiled executable needs gdb on the host computer to be compiled for this purpuse. In my case it means that I have to use this command
/opt/microblaze-uclinux-tools/bin/microblaze-uclinux-gdb line-g
enerator.gdb
instead of simple gdb line-generator.gdb
Luckily the correct file was provided by the embedded board manufacturer!
To be honest I don't fully understand the context so if someone has an explanation on this I'd be glad to hear this!
cheers, Stefan
Related
I want to test DTLS libraries on two K64F board with ARM Mbed OS. I have just created a new project:
mbed new .
I have created a folder called source and copied there dtls_client.c obtained from the mbeddtls project page. I have changed the value of the SERVER_ADDR constant.
I have repeated this process with dtls_server.c file.
Both project compiled without errors.
mbed compile -m K64F -t GCC_ARM -c
I copied each bin file to a different board but when I connect to them through the putty terminal I cannot see anything. I have been using this connection with the rest of my programs and it works. I think It may have something related to connection (now it is 115200).
I see that the code uses a mbedtls_printf function to print messages. I have tried inserting some printf traces but I don't see them either. How should I set the terminal to be able to see something?
#jordi,
Baudrate of 115200 should be OK for K64F.
You should verify that you have DEBUG_LEVEL set to a value higher than 0, and that Mbed TLS is compiled in debug mode.
Please compile your application with the following command:
mbed compile -m K64F -t GCC_ARM -c --profile=mbed-os/tools/profiles/debug.json
In addition, you should verify that your configuration file has MBEDTLS_DEBUG_C configured
When sending the step command from my host machine running gdb to my remote target (connected over TCP/IP) running the gdbserver, I receive the following error on the target
ptrace: Input/output error.
input_interrupt, count = 1 c = 36 ('$')
Nothing happens on the target after this - just hangs. On the host's gdb, the following is displayed
(gdb) step
warning: Remote failure reply: E01
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
This will continue indefinitely. Ends up with me having to reboot the target. continue works just fine and is able to trigger on my designated breakpoints. Could this fault be entirely on the gdbserver side or could it have something to do with my gdb configuration?
gdbserver version on the target
GNU gdbserver (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro GCC
4.9-2014.09) 7.6.1-2013.10
gdb (built from source) version on the host
GNU gdb (GDB) 7.7.1
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
Looks like the issue I was having was due to an incorrect target when compiling the host GDB. For the target processor I'm using, I needed to set the target flag to
--target=arm-linux-gnueabihf
So far, I'm able to step through my code as well as trigger on segfaults.
I have a Linux script written in C Language deployed at a remote server, to which multiple clients can connect. Due to some reason the script crashed and when I am trying to restart it I am getting segmentation fault.Is there any way by which I can Check at server side that what is stopping my script from starting, and is throwing segmentation fault error.
Start out by enabling core dumps:
$ ulimit -c unlimited
Now run the script until it segfaults. This will create a core dump file in your working directory.
Next, use GDB (or any frontend of it) to debug it (note that you can copy the file to your local machine if you can't debug on the server):
$ gdb -c <core_file>
Don't forget to add the symbol file:
GDB> file my-prog
If it's easy to reproduce the problem, and provided you can debug directly on the server (with SSH or such), you can simply dive in and start the process with a debugger attached:
$ gdb my-prog
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.