public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* relocatable kernel support, bug #4224
@ 2007-03-22 20:57 Frank Ch. Eigler
  2007-03-22 21:26 ` Roland McGrath
  0 siblings, 1 reply; 3+ messages in thread
From: Frank Ch. Eigler @ 2007-03-22 20:57 UTC (permalink / raw)
  To: systemtap

Hi -

My final patch for this problem is now in CVS.  Please test it on some
recent kernels, for I'd like to refresh Fedora's systemtap with a
snapshot pronto.

The language change generated by this issue is summarized thusly in
src/NEWS:


- The numeric forms of kernel.statement() and kernel.function() probe points
  are now interpreted as relocatable values - treated as relative to the
  _stext symbol in that kernel binary.  Since some modern kernel images
  are relocated to a different virtual address at startup, such addresses
  may shift up or down when actually inserted into a running kernel.

     kernel.statement(0xdeadbeef): validated, interpreted relative to _stext,
                                   may map to 0xceadbeef at run time.

  In order to specify unrelocated addresses, use the new ".absolute"
  probe point suffix for such numeric addresses.  These are only
  allowed in guru mode, and provide access to no $target variables.
  They don't use debugging information at all, actually.

     kernel.statement(0xfeedface).absolute: raw, unvalidated, guru mode only


- FChE

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: relocatable kernel support, bug #4224
  2007-03-22 20:57 relocatable kernel support, bug #4224 Frank Ch. Eigler
@ 2007-03-22 21:26 ` Roland McGrath
  2007-03-22 21:32   ` Frank Ch. Eigler
  0 siblings, 1 reply; 3+ messages in thread
From: Roland McGrath @ 2007-03-22 21:26 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: systemtap

I don't understand why a runtime function is involved in this at all.  
The kernel is not like other modules, you always know you can refer to it
directly and know a symbol you can use.  Just generate code that does:

	foo_addr = vmlinux_foo_addr_const - vmlinux_stext_addr_const + &_stext;

The work will be done at load time by kernel/module.c code, and pretty
efficiently.  There is no need for runtime data structures about this.


Thanks,
Roland

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: relocatable kernel support, bug #4224
  2007-03-22 21:26 ` Roland McGrath
@ 2007-03-22 21:32   ` Frank Ch. Eigler
  0 siblings, 0 replies; 3+ messages in thread
From: Frank Ch. Eigler @ 2007-03-22 21:32 UTC (permalink / raw)
  To: Roland McGrath; +Cc: systemtap

Hi -

> I don't understand why a runtime function is involved in this at all.  
> [...]
> foo_addr = vmlinux_foo_addr_const - vmlinux_stext_addr_const + &_stext;

_stext is not module-exported.  But really, the _stp_module_relocate
function calls are fast for this case anyway.


- FChE

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2007-03-22 21:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-03-22 20:57 relocatable kernel support, bug #4224 Frank Ch. Eigler
2007-03-22 21:26 ` Roland McGrath
2007-03-22 21:32   ` Frank Ch. Eigler

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).