linux-kernel - why can't i use gdb to dump module variables anymore?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1007080744180.7016@lynx>
Date:	Thu, 8 Jul 2010 07:51:55 -0400 (EDT)
From:	"Robert P. J. Day" <rpjday@...shcourse.ca>
To:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: why can't i use gdb to dump module variables anymore?

  trying very hard to make a long story short, documenting how to use
gdb to poke around in a loaded module.  the important part of the
module (to demonstrate the visibility of different types of
variables):

static int rpjday_1;
int rpjday_2 = 20;
int rpjday_3 = 30;

EXPORT_SYMBOL(rpjday_3);

  once i load that module, i can see the good stuff in /proc/kallsyms:

$ grep rpjday /proc/kallsyms
ffffffffa007c090 r __ksymtab_rpjday_3	[crash_gdb]
ffffffffa007c0a8 r __kstrtab_rpjday_3	[crash_gdb]
ffffffffa007c0a0 r __kcrctab_rpjday_3	[crash_gdb]
ffffffffa007c0b4 d rpjday_2	[crash_gdb]
ffffffffa007c0b8 D rpjday_3	[crash_gdb]
$

  i can examine the salient files under
/sys/module/crash_gdb/sections/, like .data

0xffffffffa007c0b4

so here's a couple questions.

  if i want to add that module's symbol table info to my running gdb
session, i would use "add-symbol-file" but the first arg *must* be the
address of the text section and this module has *no* .text section.
so what do i use for that value?  the address of the .exit.text
section?

  and if i try to load:

(gdb) add-symbol-file /tmp/crash_gdb.ko 0xffffffffa007c000 \
-s .data 0xffffffffa007c0b4
add symbol table from file "/tmp/crash_gdb.ko" at
	.text_addr = 0xffffffffa007c000
	.data_addr = 0xffffffffa007c0b4
(y or n) y
Reading symbols from /tmp/crash_gdb.ko...done.
(gdb)

  it certainly *looks* like that worked, and:

(gdb) whatis rpjday_2
type = int
(gdb) whatis rpjday_3
type = int

  looks good, but here's where things go wrong:

(gdb) p rpjday_2
Cannot access memory at address 0xffffffffa007c0b4
(gdb) p rpjday_3
Cannot access memory at address 0xffffffffa007c0b8

  that sort of thing used to work when i was testing this on a 32-bit
fedora system, but i'm now on 64-but ubuntu and i don't see why those
last couple commands no longer work.  the addresses certainly match
what's in /proc/kallsyms, and i don't recall having to do anything
special last time.  have i omitted a critical compile-time option for
this?  thanks.

rday

-- 

========================================================================
Robert P. J. Day                               Waterloo, Ontario, CANADA

        Top-notch, inexpensive online Linux/OSS/kernel courses
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/