Messages in this thread | | | Date | Wed, 31 Mar 1999 09:06:58 +0100 (BST) | From | Tigran Aivazian <> | Subject | dilemma: /proc/kcore vs (x)kdebug. |
| |
Hi Brethren,
The dilema is this:
I want to be able to browse (live) kernel data structures in the manner like "od -fstruct_name address" command of crash(1M) under SVR5. There are many ways of doing this under Linux now (in brackets the reasons why I am not happy with it):
1. Use remote x86 debugging patch with gdb. (way overkill and requires patching the kernel - I want a kernel-independent way, i.e. at most -g compile the kernel and that is it).
2. Use IKD patch which has xkdebug facility (again overkill, and because it lets you single-step/breakpoint it requires patching the kernel. I said the price I am willing to pay is to CFLAGS += -g, not a byte more!)
3. Use what all good Linux books recommend: compile with -g and then do gdb vmlinux /proc/kcore. (does not work, try it and see).
Now of all the above, (3.) would be the easiest and thus preferred. But it does not work. Try "p task[0]->comm" (works) and then "p task[1]->comm" or any task[] and see for yourself.
Therefore, I have two ways out of this:
1. Take xkdebug out of IKD, remove support for single-step/breakpoint and thus anti-evolve xkdebug into its original state of old good kdebug package, able to browse live kernel memory.
2. Investigate fs/proc/array.c:read_core() function and establish whether /proc/kcore is built correctly or not. Is it gdb's fault or read_core()'s? Or perhaps I can give some obscure command to gdb (like disable core caching or something) and everything will magically start working?
Now I am all ears and awaiting your opinions.
Regards, ------ Tigran A. Aivazian | http://www.sco.com Escalations Research Group | tel: +44-(0)1923-813796 Santa Cruz Operation Ltd | http://www.aivazian.demon.co.uk
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |