* RE: Question about kernel module debug
@ 2007-10-18 5:34 Yuxin_Zhuang
0 siblings, 0 replies; 8+ messages in thread
From: Yuxin_Zhuang @ 2007-10-18 5:34 UTC (permalink / raw)
To: fche; +Cc: systemtap
I've also got a newer version of systemtap ( 0.6) with elfutils version
0.129. But it doesn't work either.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Question about kernel module debug
@ 2007-10-16 3:12 Yuxin_Zhuang
2007-10-16 3:24 ` Yuxin_Zhuang
2007-10-16 16:01 ` Frank Ch. Eigler
0 siblings, 2 replies; 8+ messages in thread
From: Yuxin_Zhuang @ 2007-10-16 3:12 UTC (permalink / raw)
To: systemtap; +Cc: Yuxin_Zhuang
Hi,Systemtap users:
I've installed systemtap 0.5.8 on RHEL4 with kernel 2.6.9-42. I wanna
use systemtap to debug a kernel module which is not built into the
kernel and I got some questions.
1. Is the 'debuginfo' of the module needed by systemtap is just the
stuff created by gcc with option '-g'? Will an additional '-O2' make a
lot of difference?
2. I've put the '.ko' file which is built with options '-g -O2' under
the proper search path and created a symbol link with the suffix
'.ko.debug' to it. Before the systemtap is run, the module has been
loaded and works well. But systemtap reported that it can not find the
module's debuginfo.
The output is:
Pass 1: parsed user script and 25 library script(s) in
80usr/10sys/136real ms.
semantic error: cannot find module my_module debuginfo: r_offset is
bogus
semantic error: no match for probe point
while: resolving probe point module("my_module").function("*")
Pass 2: analyzed script: 2 probe(s), 0 function(s), 0 global(s) in
0usr/30sys/43real ms.
Pass 2: analysis failed. Try again with more '-v' (verbose) options.
And I straced the stap, the output before printing the error is as
follows :
......
open("/usr/lib/systemtap/../lib/systemtap/libebl_i386.so", O_RDONLY) =
-1 ENOENT (No such file or directory)
open("/usr/lib/systemtap/libebl_i386.so", O_RDONLY) = 5
read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\6\0\000"...,
512) = 512
fstat64(5, {st_mode=S_IFREG|0755, st_size=7724, ...}) = 0
old_mmap(NULL, 10596, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5,
0) = 0xcf5000
old_mmap(0xcf7000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x1000) = 0xcf7000
close(5) = 0
open("/lib/modules/2.6.9-42.ELsmp/kernel/fs/my_module/my_module.ko.debug
", O_RDONLY|O_LARGEFILE) = 5
fcntl64(5, F_GETFL) = 0x8000 (flags
O_RDONLY|O_LARGEFILE)
fstat64(5, {st_mode=S_IFREG|0755, st_size=2734531, ...}) = 0
mmap2(NULL, 2734531, PROT_READ|PROT_WRITE, MAP_PRIVATE, 5, 0) =
0xb589f000
open("/sys/module/my_module/sections/.text", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb589e000
read(6, "0xd0e0c000\n", 4096) = 11
read(6, "", 4096) = 0
close(6) = 0
munmap(0xb589e000, 4096) = 0
open("/sys/module/my_module/sections/.rodata", O_RDONLY) = 6
fstat64(6, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb589e000
read(6, "0xd0e29c90\n", 4096) = 11
read(6, "", 4096) = 0
close(6) = 0
munmap(0xb589e000, 4096) = 0
write(2, "semantic error: ", 16semantic error: ) = 16
......
What can be the reason for the error??
Any suggestions will be appreciated, thanks a lot!
ZHUANG Yuxin
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Question about kernel module debug
2007-10-16 3:12 Yuxin_Zhuang
@ 2007-10-16 3:24 ` Yuxin_Zhuang
2007-10-16 16:01 ` Frank Ch. Eigler
1 sibling, 0 replies; 8+ messages in thread
From: Yuxin_Zhuang @ 2007-10-16 3:24 UTC (permalink / raw)
To: systemtap
Sorry, the module is compiled with just '-g', no '-O2'.
> _____________________________________________
> From: Yuxin, Zhuang
> Sent: 2007年10月16日 11:09
> To: systemtap@sources.redhat.com
> Cc: Yuxin, Zhuang
> Subject: Question about kernel module debug
>
> Hi,Systemtap users:
>
> I've installed systemtap 0.5.8 on RHEL4 with kernel 2.6.9-42. I wanna use systemtap to debug a kernel module which is not built into the kernel and I got some questions.
>
> 1. Is the 'debuginfo' of the module needed by systemtap is just the stuff created by gcc with option '-g'? Will an additional '-O2' make a lot of difference?
>
> 2. I've put the '.ko' file which is built with options '-g -O2' under the proper search path and created a symbol link with the suffix '.ko.debug' to it. Before the systemtap is run, the module has been loaded and works well. But systemtap reported that it can not find the module's debuginfo.
> The output is:
>
> Pass 1: parsed user script and 25 library script(s) in 80usr/10sys/136real ms.
> semantic error: cannot find module my_module debuginfo: r_offset is bogus
> semantic error: no match for probe point
> while: resolving probe point module("my_module").function("*")
> Pass 2: analyzed script: 2 probe(s), 0 function(s), 0 global(s) in 0usr/30sys/43real ms.
> Pass 2: analysis failed. Try again with more '-v' (verbose) options.
>
> And I straced the stap, the output before printing the error is as follows :
>
> …...
> open("/usr/lib/systemtap/../lib/systemtap/libebl_i386.so", O_RDONLY) = -1 ENOENT (No such file or directory)
> open("/usr/lib/systemtap/libebl_i386.so", O_RDONLY) = 5
> read(5, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\6\0\000"..., 512) = 512
> fstat64(5, {st_mode=S_IFREG|0755, st_size=7724, ...}) = 0
> old_mmap(NULL, 10596, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 5, 0) = 0xcf5000
> old_mmap(0xcf7000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 5, 0x1000) = 0xcf7000
> close(5) = 0
> open("/lib/modules/2.6.9-42.ELsmp/kernel/fs/my_module/my_module.ko.debug", O_RDONLY|O_LARGEFILE) = 5
> fcntl64(5, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
> fstat64(5, {st_mode=S_IFREG|0755, st_size=2734531, ...}) = 0
> mmap2(NULL, 2734531, PROT_READ|PROT_WRITE, MAP_PRIVATE, 5, 0) = 0xb589f000
> open("/sys/module/my_module/sections/.text", O_RDONLY) = 6
> fstat64(6, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb589e000
> read(6, "0xd0e0c000\n", 4096) = 11
> read(6, "", 4096) = 0
> close(6) = 0
> munmap(0xb589e000, 4096) = 0
> open("/sys/module/my_module/sections/.rodata", O_RDONLY) = 6
> fstat64(6, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb589e000
> read(6, "0xd0e29c90\n", 4096) = 11
> read(6, "", 4096) = 0
> close(6) = 0
> munmap(0xb589e000, 4096) = 0
> write(2, "semantic error: ", 16semantic error: ) = 16
> ……
>
> What can be the reason for the error??
> Any suggestions will be appreciated, thanks a lot!
>
>
> ZHUANG Yuxin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about kernel module debug
2007-10-16 3:12 Yuxin_Zhuang
2007-10-16 3:24 ` Yuxin_Zhuang
@ 2007-10-16 16:01 ` Frank Ch. Eigler
2007-10-18 2:18 ` Yuxin_Zhuang
2007-10-18 6:17 ` Yuxin_Zhuang
1 sibling, 2 replies; 8+ messages in thread
From: Frank Ch. Eigler @ 2007-10-16 16:01 UTC (permalink / raw)
To: Yuxin_Zhuang; +Cc: systemtap
Yuxin_Zhuang@emc.com writes:
> I've installed systemtap 0.5.8 on RHEL4 with kernel 2.6.9-42.
This is over a year old. If you can, please upgrade to a later
systemtap build. RHN should have 0.5.12 or even 0.5.14 by now.
> [...] 1. Is the 'debuginfo' of the module needed by systemtap is
> just the stuff created by gcc with option '-g'?
Yes.
> Will an additional '-O2' make a lot of difference?
It will make the debugging information somewhat less precise, giving
you fewer useful probe points.
> 2. I've put the '.ko' file which is built with options '-g -O2' under
> the proper search path and created a symbol link with the suffix
> '.ko.debug' to it. [...]
There should be no need for the .ko.debug file if the basic .ko file
was not stripped. What does "readelf -S module.ko" say about .debug_*
sections?
- FChE
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Question about kernel module debug
2007-10-16 16:01 ` Frank Ch. Eigler
@ 2007-10-18 2:18 ` Yuxin_Zhuang
2007-10-18 6:17 ` Yuxin_Zhuang
1 sibling, 0 replies; 8+ messages in thread
From: Yuxin_Zhuang @ 2007-10-18 2:18 UTC (permalink / raw)
To: fche; +Cc: systemtap
Thanks for your reply !
The result of 'readelf -S' is as follows and the .debug_* sections are already there:
****************************
There are 52 section headers, starting at offset 0x2084ec:
Section Headers:
[Nr] Name Type Addr Off Size ES Flg Lk Inf Al
[ 0] NULL 00000000 000000 000000 00 0 0 0
[ 1] .text PROGBITS 00000000 000040 01db74 00 AX 0 0 16
[ 2] .rel.text REL 00000000 208d0c 00b6d0 08 50 1 4
[ 3] .fixup PROGBITS 00000000 01dbb4 00004a 00 AX 0 0 1
[ 4] .rel.fixup REL 00000000 2143dc 000038 08 50 3 4
[ 5] .altinstr_replace PROGBITS 00000000 01dbfe 00007b 00 AX 0 0 1
[ 6] .exit.text PROGBITS 00000000 01dc7c 000053 00 AX 0 0 4
[ 7] .rel.exit.text REL 00000000 214414 000070 08 50 6 4
[ 8] .init.text PROGBITS 00000000 01dcd0 000250 00 AX 0 0 4
[ 9] .rel.init.text REL 00000000 214484 0001c8 08 50 8 4
[10] .rodata PROGBITS 00000000 01df20 001059 00 A 0 0 4
[11] .rel.rodata REL 00000000 21464c 0003c0 08 50 10 4
[12] .rodata.str1.1 PROGBITS 00000000 01ef79 00182f 01 AMS 0 0 1
[13] .rodata.str1.4 PROGBITS 00000000 0207a8 006015 01 AMS 0 0 4
[14] __ex_table PROGBITS 00000000 0267c0 000038 00 A 0 0 4
[15] .rel__ex_table REL 00000000 214a0c 000070 08 50 14 4
[16] .altinstructions PROGBITS 00000000 0267f8 0001eb 00 A 0 0 4
[17] .rel.altinstructi REL 00000000 214a7c 000290 08 50 16 4
[18] __param PROGBITS 00000000 0269e4 000154 00 A 0 0 4
[19] .rel__param REL 00000000 214d0c 000220 08 50 18 4
[20] .modinfo PROGBITS 00000000 026b40 000602 00 A 0 0 32
[21] __versions PROGBITS 00000000 027144 000000 00 A 0 0 4
[22] .data PROGBITS 00000000 027160 000af0 00 WA 0 0 32
[23] .rel.data REL 00000000 214f2c 000698 08 50 22 4
[24] .gnu.linkonce.thi PROGBITS 00000000 027c80 001180 00 WA 0 0 128
[25] .rel.gnu.linkonce REL 00000000 2155c4 000010 08 50 24 4
[26] .bss NOBITS 00000000 028e00 041ad0 00 WA 0 0 32
[27] .stab PROGBITS 00000000 028e00 001338 0c 29 0 4
[28] .rel.stab REL 00000000 2155d4 000028 08 50 27 4
[29] .stabstr STRTAB 00000000 02a138 00438c 00 0 0 1
[30] .comment PROGBITS 00000000 02e4c4 00057f 00 0 0 1
[31] .debug_aranges PROGBITS 00000000 02ea43 000370 00 0 0 1
[32] .rel.debug_arange REL 00000000 2155fc 0001c0 08 50 31 4
[33] .debug_pubnames PROGBITS 00000000 02edb3 001c3c 00 0 0 1
[34] .rel.debug_pubnam REL 00000000 2157bc 0000e8 08 50 33 4
[35] .debug_info PROGBITS 00000000 0309ef 105d1d 00 0 0 1
[36] .rel.debug_info REL 00000000 2158a4 07a810 08 50 35 4
[37] .debug_abbrev PROGBITS 00000000 13670c 0077fd 00 0 0 1
[38] .debug_line PROGBITS 00000000 13df09 011d32 00 0 0 1
[39] .rel.debug_line REL 00000000 2900b4 0000f0 08 50 38 4
[40] .debug_frame PROGBITS 00000000 14fc3c 00ae0c 00 0 0 4
[41] .rel.debug_frame REL 00000000 2901a4 002150 08 50 40 4
[42] .debug_str PROGBITS 00000000 15aa48 07a8d7 01 MS 0 0 1
[43] .debug_loc PROGBITS 00000000 1d531f 02f82d 00 0 0 1
[44] .rel.debug_loc REL 00000000 2922f4 000ca0 08 50 43 4
[45] .note NOTE 00000000 204b4c 000014 00 0 0 1
[46] .debug_ranges PROGBITS 00000000 204b60 0037c8 00 0 0 1
[47] .rel.debug_ranges REL 00000000 292f94 000200 08 50 46 4
[48] .note.GNU-stack PROGBITS 00000000 208328 000000 00 X 0 0 1
[49] .shstrtab STRTAB 00000000 208328 0001c3 00 0 0 1
[50] .symtab SYMTAB 00000000 293194 004ad0 10 51 710 4
[51] .strtab STRTAB 00000000 297c64 003d5f 00 0 0 1
Key to Flags:
W (write), A (alloc), X (execute), M (merge), S (strings)
I (info), L (link order), G (group), x (unknown)
O (extra OS processing required) o (OS specific), p (processor specific)
********************************
But the output of systemtap says:
*********************************
Pass 1: parsed user script and 25 library script(s) in
80usr/10sys/136real ms.
semantic error: cannot find module my_module debuginfo: r_offset is
bogus
semantic error: no match for probe point
while: resolving probe point module("my_module").function("*")
Pass 2: analyzed script: 2 probe(s), 0 function(s), 0 global(s) in
0usr/30sys/43real ms.
Pass 2: analysis failed. Try again with more '-v' (verbose) options.
*********************************
What can be the reason ?
-----Original Message-----
From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Frank Ch. Eigler
Sent: 2007年10月16日 23:58
To: Yuxin, Zhuang
Cc: systemtap@sources.redhat.com
Subject: Re: Question about kernel module debug
Yuxin_Zhuang@emc.com writes:
> I've installed systemtap 0.5.8 on RHEL4 with kernel 2.6.9-42.
This is over a year old. If you can, please upgrade to a later
systemtap build. RHN should have 0.5.12 or even 0.5.14 by now.
> [...] 1. Is the 'debuginfo' of the module needed by systemtap is
> just the stuff created by gcc with option '-g'?
Yes.
> Will an additional '-O2' make a lot of difference?
It will make the debugging information somewhat less precise, giving
you fewer useful probe points.
> 2. I've put the '.ko' file which is built with options '-g -O2' under
> the proper search path and created a symbol link with the suffix
> '.ko.debug' to it. [...]
There should be no need for the .ko.debug file if the basic .ko file
was not stripped. What does "readelf -S module.ko" say about .debug_*
sections?
- FChE
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Question about kernel module debug
2007-10-16 16:01 ` Frank Ch. Eigler
2007-10-18 2:18 ` Yuxin_Zhuang
@ 2007-10-18 6:17 ` Yuxin_Zhuang
2007-10-18 18:22 ` Frank Ch. Eigler
1 sibling, 1 reply; 8+ messages in thread
From: Yuxin_Zhuang @ 2007-10-18 6:17 UTC (permalink / raw)
To: fche; +Cc: systemtap
What do you mean by " There should be no need for the .ko.debug file if the basic .ko file was not stripped. "??
Does it means that systemtap will get the debug information from the .ko file and will not look for the .ko.debug file on the three search paths??
But when the .ko.debug symlink is removed, the result of strace shows that without finding the '.ko.debug' file on the three search paths systemtap just fails. Saying 'r_offset is bogus'.
-----Original Message-----
From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Frank Ch. Eigler
Sent: 2007年10月16日 23:58
To: Yuxin, Zhuang
Cc: systemtap@sources.redhat.com
Subject: Re: Question about kernel module debug
Yuxin_Zhuang@emc.com writes:
> I've installed systemtap 0.5.8 on RHEL4 with kernel 2.6.9-42.
This is over a year old. If you can, please upgrade to a later
systemtap build. RHN should have 0.5.12 or even 0.5.14 by now.
> [...] 1. Is the 'debuginfo' of the module needed by systemtap is
> just the stuff created by gcc with option '-g'?
Yes.
> Will an additional '-O2' make a lot of difference?
It will make the debugging information somewhat less precise, giving
you fewer useful probe points.
> 2. I've put the '.ko' file which is built with options '-g -O2' under
> the proper search path and created a symbol link with the suffix
> '.ko.debug' to it. [...]
There should be no need for the .ko.debug file if the basic .ko file
was not stripped. What does "readelf -S module.ko" say about .debug_*
sections?
- FChE
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: Question about kernel module debug
2007-10-18 6:17 ` Yuxin_Zhuang
@ 2007-10-18 18:22 ` Frank Ch. Eigler
2007-10-19 6:32 ` Yuxin_Zhuang
0 siblings, 1 reply; 8+ messages in thread
From: Frank Ch. Eigler @ 2007-10-18 18:22 UTC (permalink / raw)
To: Yuxin_Zhuang; +Cc: systemtap
Yuxin_Zhuang@emc.com writes:
> What do you mean by " There should be no need for the .ko.debug file
> if the basic .ko file was not stripped. "?? Does it means that
> systemtap will get the debug information from the .ko file and will
> not look for the .ko.debug file on the three search paths??
That's right.
> But when the .ko.debug symlink is removed, the result of strace
> shows that without finding the '.ko.debug' file on the three search
> paths systemtap just fails. Saying 'r_offset is bogus'.
That's not right (elfutils error DWFL_E_BADRELOFF). It's as if
something has corrupted the data. Please describe the toolchain
version, architecture, and anything else that may be unusual about the
build process.
- FChE
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: Question about kernel module debug
2007-10-18 18:22 ` Frank Ch. Eigler
@ 2007-10-19 6:32 ` Yuxin_Zhuang
0 siblings, 0 replies; 8+ messages in thread
From: Yuxin_Zhuang @ 2007-10-19 6:32 UTC (permalink / raw)
To: fche; +Cc: systemtap
Configuration of my environment:
Machine architecture: i686
OS: RHEL4 with kernel 2.6.9-42.Elsmp
Systemtap version: 0.6
Elfutils : 0.129
GCC: 3.4.6
The content of the script
**************************
probe module("my_module").function("*")
{
printf( "In the module\n");
}
**************************
The output is as follows:
**************************
Pass 1: parsed user script and 25 library script(s) in 80usr/10sys/136real ms.
semantic error: cannot find module my_module debuginfo: r_offset is bogus
semantic error: no match for probe point
while: resolving probe point module("my_module").function("*")
Pass 2: analyzed script: 2 probe(s), 0 function(s), 0 global(s) in 0usr/30sys/43real ms.
Pass 2: analysis failed. Try again with more '-v' (verbose) options.
**************************
And the functions in kernel and modules built with the kernel can be probed with no problem.
The module 'my_module' has been built with the debug information not stripped. But systemtap is still looking for a '.ko.debug' file.
Thanks !
ZHUANG Yuxin
-----Original Message-----
From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org] On Behalf Of Frank Ch. Eigler
Sent: 2007年10月19日 2:22
To: Yuxin, Zhuang
Cc: systemtap@sources.redhat.com
Subject: Re: Question about kernel module debug
Yuxin_Zhuang@emc.com writes:
> What do you mean by " There should be no need for the .ko.debug file
> if the basic .ko file was not stripped. "?? Does it means that
> systemtap will get the debug information from the .ko file and will
> not look for the .ko.debug file on the three search paths??
That's right.
> But when the .ko.debug symlink is removed, the result of strace
> shows that without finding the '.ko.debug' file on the three search
> paths systemtap just fails. Saying 'r_offset is bogus'.
That's not right (elfutils error DWFL_E_BADRELOFF). It's as if
something has corrupted the data. Please describe the toolchain
version, architecture, and anything else that may be unusual about the
build process.
- FChE
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2007-10-19 6:32 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-18 5:34 Question about kernel module debug Yuxin_Zhuang
-- strict thread matches above, loose matches on Subject: below --
2007-10-16 3:12 Yuxin_Zhuang
2007-10-16 3:24 ` Yuxin_Zhuang
2007-10-16 16:01 ` Frank Ch. Eigler
2007-10-18 2:18 ` Yuxin_Zhuang
2007-10-18 6:17 ` Yuxin_Zhuang
2007-10-18 18:22 ` Frank Ch. Eigler
2007-10-19 6:32 ` Yuxin_Zhuang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).