Seen some problems with elfuitls-0.131 on x86_64

Seen some problems with elfuitls-0.131 on x86_64

[Srinivasa Ds]

Iam facing some problems with elfutils-0.131 on x86_64. 

   1) [root@llm42 obj]# ./stap -vvvvvv ../src/testsuite/buildok/seventeen.stp

SystemTap translator/driver (version 0.6/0.131 built 2007-12-17)
Copyright (C) 2005-2007 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
Created temporary directory "/tmp/stap8sz4gd"
Searched '/home/systemtap/tmp/stap_testing_200712171145/install/share/systemtap/tapset/x86_64/*.stp', found 1
Searched '/home/systemtap/tmp/stap_testing_200712171145/install/share/systemtap/tapset/*.stp', found 37
Pass 1: parsed user script and 38 library script(s) in 510usr/10sys/526real ms.
control symbols: kts: 0xffffffff8046c570 kte: 0xffffffff8046f451 stext: 0xffffffff80209000
parsed 'pipe_write' -> func 'pipe_write'
pattern 'kernel' matches module 'kernel'
focused on module 'kernel = [0xffffffff80200000-0xffffffff809968a0, bias 0x0] file /boot/vmlinux-2.6.24-rc5 ELF machine x86_64 (code 62)
pattern 'pipe_write' matches function 'pipe_write'
selected function pipe_write
probe pipe_write@fs/pipe.c:396 kernel pc=0xffffffff8029b631
finding location for local 'write_fifo_fops' near address ffffffff8029b631, module bias 0
dwarf_builder releasing dwflpp
semantic error: cannot relocate user-space dso (?) address: identifier '$write_fifo_fops' at ../src/testsuite/buildok/seventeen.stp:8:19
Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) in 230usr/60sys/288real ms.
Pass 2: analysis failed.  Try again with more '-v' (verbose) options.
Running rm -rf /tmp/stap8sz4gd

On debugging I found that mod->reloc_info(no relocation info) is NULL and hence the problem. 

So Am I missing something??

2) Same could be the reason for bug 5483. Where I could clearly see that elfutils fails to fetch the init section name and causing the problem.

Could somebody throw light on this

Thanks
 Srinivasa DS

Re: Seen some problems with elfuitls-0.131 on x86_64

[Roland McGrath]

This is a systemtap issue.  dwfl_module_relocations is now 1 for the
kernel, not 0.  That's because we have a "relocatable kernel" on some
platforms, where a boot-time offset has to be added to static addresses.

I have not investigated 5483. 


Thanks,
Roland

Re: Seen some problems with elfuitls-0.131 on x86_64

[Srinivasa Ds]

Roland McGrath wrote:
> This is a systemtap issue.  dwfl_module_relocations is now 1 for the
> kernel, not 0.  That's because we have a "relocatable kernel" on some
> platforms, where a boot-time offset has to be added to static addresses.
> 
> I have not investigated 5483. 
> 

Thanks Roland for your reply. Could please clarify my doubt.

When we need to add a probe point to kernel, we check for  relocation
information for it, through dwfl_module_relocations().
For a kernel which is built without CONFIG_RELOC option,there will be 
no relocation info. Hence I expect dwfl_module_relocations() to return 0.
(Please correct If Iam wrong)

But In my system with elfutils-0.131, Iam getting return value of 
dwfl_module_relocations() as 1.(Thats because mod->e_type is ET_DYN)
I think thats a wrong value. This is causing some bugs in systemtap.

Could please throw some light on this.

Thanks
 Srinivasa DS

Re: Seen some problems with elfuitls-0.131 on x86_64

[Roland McGrath]

> When we need to add a probe point to kernel, we check for  relocation
> information for it, through dwfl_module_relocations().
> For a kernel which is built without CONFIG_RELOC option,there will be 
> no relocation info. Hence I expect dwfl_module_relocations() to return 0.
> (Please correct If Iam wrong)

No, there is no way to determine this.  So libdwfl always assumes the
kernel might be relocatable.  ELF kernels are ET_EXEC files, but a
relocatable kernel acts like ET_DYN; libdwfl treats kernels exactly that
way.  Previous 

  

Re: Seen some problems with elfuitls-0.131 on x86_64

[Roland McGrath]

> When we need to add a probe point to kernel, we check for  relocation
> information for it, through dwfl_module_relocations().
> For a kernel which is built without CONFIG_RELOC option,there will be 
> no relocation info. Hence I expect dwfl_module_relocations() to return 0.
> (Please correct If Iam wrong)

No, there is no feasible way to determine this from the built kernel image.
So libdwfl always assumes the kernel might be relocatable.  ELF kernels are
ET_EXEC files, but a relocatable kernel acts like ET_DYN, i.e. its whole
image is loaded at an offset from the addresses used in the ELF file
libdwfl treats kernels exactly that way, so dwfl_module_relocation_info has
one relocation, with name "", like it's described to for ET_DYN.

Previous versions of elfutils did not do this, and so relying on the
dwfl_module_relocations mechanism failed to work with running kernels that
were in fact relocated.

Systemtap ought to recognize a 1, "" dwfl_module_relocation_info as meaning
a relocatable kernel when it comes from a kernel address space Dwfl.  (Or
it can just ignore dwfl_module_relocations for the kernel module and expect
it always to require a simple runtime bias.)

When dealing with user-space objects, dwfl_module_relocations returns 0 for
ET_EXEC files, which use absolute addresses, and 1, "" for ET_DYN
(including PIE) files, which require a simple runtime bias.  


Thanks,
Roland