public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* systemtap cannot probe function defined in assemble language
@ 2006-01-23  6:44 Mao, Bibo
  2006-01-23 13:57 ` Frank Ch. Eigler
  0 siblings, 1 reply; 3+ messages in thread
From: Mao, Bibo @ 2006-01-23  6:44 UTC (permalink / raw)
  To: systemtap

Currently there is no switch_to() function in IA64 kernel version,
similar there is function ia64_switch_to() which is defined in assemble
language, but systemtap can not probe this function, and systemtap is
defined as follows:

	kernel.function("ia64_switch_to"){
	}
And in my x86_64 box, it also can not probe kernel_thread() function.


bibo,mao

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

* Re: systemtap cannot probe function defined in assemble language
  2006-01-23  6:44 systemtap cannot probe function defined in assemble language Mao, Bibo
@ 2006-01-23 13:57 ` Frank Ch. Eigler
  2006-01-23 21:03   ` Roland McGrath
  0 siblings, 1 reply; 3+ messages in thread
From: Frank Ch. Eigler @ 2006-01-23 13:57 UTC (permalink / raw)
  To: Mao, Bibo; +Cc: systemtap


"Mao, Bibo" <bibo.mao@intel.com> writes:

> [...]
> 	kernel.function("ia64_switch_to"){}
> And in my x86_64 box, it also can not probe kernel_thread() function.

What does "stap -v ..." tell you?

We may need a new probe point type name that is suitable for assembly
language probing, even in the absence of DWARF debugging information.
It would of course expose no normal $target variables, though could
perhaps expose registers.

A related question.  When building *.S assembly files in the kernel,
is the assembler being told to emit debugging information for them?
On some compiler versions, it's automatic (it turns "gcc -g foo.s"
into "as -g foo.s"), but others require an explicit "-Wa,--gdwarf-2"
CFLAGS.

- FChE

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

* Re: systemtap cannot probe function defined in assemble language
  2006-01-23 13:57 ` Frank Ch. Eigler
@ 2006-01-23 21:03   ` Roland McGrath
  0 siblings, 0 replies; 3+ messages in thread
From: Roland McGrath @ 2006-01-23 21:03 UTC (permalink / raw)
  To: Frank Ch. Eigler; +Cc: Mao, Bibo, systemtap

> We may need a new probe point type name that is suitable for assembly
> language probing, even in the absence of DWARF debugging information.

I'll leave the systemtap language choices to you, but I'm not sure this
necessarily needs a different flavor of probe syntax.  We could just make
it search for ELF symbol names as well as DWARF names.

> It would of course expose no normal $target variables, though could
> perhaps expose registers.

I just recently added to elfutils the library support for supplying target
register names, so this should be easy to wire up whenever you want to do
the translator work.

> A related question.  When building *.S assembly files in the kernel,
> is the assembler being told to emit debugging information for them?

It's not.  I could look into getting this turned on.  For systemtap
purposes, this is only worthwhile if people want to write probes using
specific source locations.  


Thanks,
Roland

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

end of thread, other threads:[~2006-01-23 21:03 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-23  6:44 systemtap cannot probe function defined in assemble language Mao, Bibo
2006-01-23 13:57 ` Frank Ch. Eigler
2006-01-23 21:03   ` Roland McGrath

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