RE: Stap is translating to functions in __exit sections...and later module load fails

["Keshavamurthy, Anil S" <anil.s.keshavamurthy@intel.com>]

After commenting (i.e not discarding) *(.exit.text)
from arch/ia64/kernel/vmlinux.lds.S file and booting with this new kernel, 
stap ignores functions in __exit sections and elaborates and
translates functions properly.

Can someone tell me why this section is not discarded on Ia32?

Thanks,
-Anil Keshavamurthy

-----Original Message-----
From: Mao, Bibo 
Sent: Monday, October 16, 2006 4:27 AM
To: Eugeniy Meshcheryakov
Cc: Stone, Joshua I; Keshavamurthy, Anil S; Systemtap
Subject: Re: Stap is translating to functions in __exit sections...and later module load fails

I do not think it is gcc bug, I think it depends on ld script, this
is part of IA64 linux 2.6.19-rc2 vmlinux.lds.S,
   SECTIONS
   {
     /* Sections to be discarded */
     /DISCARD/ : {
         *(.exit.text)
         *(.exit.data)
         *(.exitcall.exit)
         *(.IA_64.unwind.exit.text)
         *(.IA_64.unwind_info.exit.text)
         }
    .......
it seems that .exit.text is discarded when vmlinux image is linked, and
on IA32 .exit.text segment is not discarded, the script
stap -e  'probe kernel.function("*") { print(".") }' can run on IA32
platform.

it is strange that when exit_pfm_fs is probe there is one such line
	probe exit_pfm_fs@arch/ia64/kernel/perfmon.c:1507 pc=0x0
I do not how function probe-point is parsed, I am not familiar with
Elfutils package :(

And powerpc has the same ld link script, it should has the same problem.

thanks
bibo,mao

Eugeniy Meshcheryakov wrote:
> 13 жовÑ'ня 2006 о 15:28 -0700 Stone, Joshua I написав(-ла):
>> This seems to support the notion that the linker elided that function.
>>
>> So, as Eugeniy wondered, why did the translator pick up that function at
>> all?  I'm also curious what IP it chose for the kprobe, if the function
>> no longer exists... Please try this command:
>>
>> $ stap -p2 -vv -e 'probe kernel.function("exit_pfm_fs"){}' 2>&1 | grep
>> 'pc='
>>
>> I suspect that either elfutils is giving 'stale' debug information, or
>> the translator is misinterpreting its results.
> It loks like a bug in some version of gcc. I tried to compile the
> following program with version from Debian stable and unstable on ia64:
> 
> $ cat test.c
> static void __attribute__((section(".exit.text"))) exit_pfm_fs(void)
> {
>         return;
> }
> $
> 
> With gcc 3.3.5:
> 
> $ readelf -a test.o | grep exit_
>      9: 0000000000000000    16 FUNC    LOCAL  DEFAULT    9 exit_pfm_fs
> $ objdump -W test.o
> ...
> The section .debug_info contains:
> 
>   Compilation Unit @ offset 0x0:
>    Length:        52
>    Version:       2
>    Abbrev Offset: 0
>    Pointer Size:  8
>  <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
>      DW_AT_stmt_list   : 0
>      DW_AT_name        : (indirect string, offset: 0x38): test.c
>      DW_AT_comp_dir    : (indirect string, offset: 0x0): /home/eugen
>      DW_AT_producer    : (indirect string, offset: 0xc): GNU C 3.3.5
> (Debian 1:3.3.5-13)
>      DW_AT_language    : 1      (ANSI C)
>  <1><1d>: Abbrev Number: 2 (DW_TAG_subprogram)
>      DW_AT_name        : (indirect string, offset: 0x2c): exit_pfm_fs
>      DW_AT_decl_file   : 1
>      DW_AT_decl_line   : 2
>      DW_AT_prototyped  : 1
>      DW_AT_low_pc      : 0
>      DW_AT_high_pc     : 0x10
>      DW_AT_frame_base  : 1 byte block: 5c       (DW_OP_reg12)
> ...
> $
> 
> With gcc 4.1.2:
> 
> $ readelf -a t.o | grep exit_
> $ objdump -W t.o | grep exit_
> objdump: Error: No comp units in .debug_info section ?objdump: Error: No
> comp units in .debug_info section ?$
> 
>