How to use kgdb on ARM??

Question

Im using ARMv7 as a target machine. I have compiled the Linux source 2.6.34.13 for target.

Target is connected with Host(Linux Development machine) through serial port using minicom.

Target is loaded with new kernel and KGDB is enabled in command prompt.

$ echo ttyAMA0 > /sys/module/kgdboc/parameters/kgdboc 
$ echo g > /proc/sysrq-trigger

Entering KGDB... message is displayed and waits for commands.

In Host side,

$arm-none-linux-gnueabi-gdb vmlinux

    gdb > set remotebaud 115200
    gdb > set debug remote 1
    gdb > target remote /dev/ttyS0

After this, some command communication takes place by default.

1. qSupported is sent from Host to Target. But qSuppoted is not supported by target so $#00 is returned. similarly ?, HC-1 commands were sent but receives proper response.

2. But qOffsets command not receiving any response from target.

I suspect vmlinux. Because if I give list in gdb, its not showing 10 lines of code instead it says

arch/arm/kernel/head.S : No such file or directory.

Note :: Kernel compilation done in server. so no source is available in development machine. But arm-gdb looks for head.S it seems.

I am not sure what mistake im doing. I need symbols to be loaded for entire kernel. Guide me in this regards.

Bergwall

I am not sure, but do you have the kernel compiled on "host" being used for debugging? & you have NOT moved the code anywhere else? – Middleton

That's why it is unable to find source? – Middleton

Does kgdb require the source code to be available? Maybe there is a command line option to tell kgdb to not look for the code. – Cinder

From the KGDB FAQ at kgdb.linsyssoft.com/FAQ.htm : "gdb needs to refer to source code files and vmlinux or a module object file. Since gdb runs on the developement machine, these files are required to be present on the developement machine." Unfortunately, you need the sources. – Norword

Minimal Buildroot QEMU setup that also gives trouble: #22005116 – Furfuran

Answer 1

Finally Host to Target communication established just bcos of line delay. There is no relationship between kernel source in development machine and time-out issues.

For the time-out kind of issue for some of the commands say qOffset and qSupported is solved by using GtkTerm instead of minicom as the serial port communication tool. Difference is "line delay" option in GtkTerm. so when this is configured to ~250, there is no timeout message thereafter. simply connection established and waits at default break point. If anyone knows how to give this "line delay" in minicom will be more helpful to everyone.

yes ofcourse, we need source code for list command to execute. but without those source also, we can debug i.e si, bt can be executed with the help of vmlinux and system.map.

Note:: set debug remote 1 is not necessary. This gives detailed display of host to command communications. For more detailed view, set debug serial 1.

Bergwall

Answer 2

That kgdb is looking for head.S is not an error. If you look here you will see that there is a head.S file in the source tree. It's an assembler file that's all. There are several source files written in assembler for this platform.

It is normal, because some instructions especially boot sequences and other "low-level" functionalities are written in assembler because it is easier.

As written in the comments already, gdb needs the sources to browse them while debugging. In the debug-sections, which contain the debug-symbols and are generated when running gcc with -g, there are "only" references to the source-file and line and column, amongst others. See here for more information and further links about debug-symbols with gcc.

That kgdb is looking for head.S is a good sign that you're doing things right. If you have the sources available (and it can be as simple as untarring the tarball of the right version) just run kgdb inside this source-tree or use the -d argument to add source-search-path, being on your development machine of course.

Blackcock