Hi...
This is my first post, so if this is off topic for this list, please direct
me
to another one that is more appropriate. Thanks
That said, I am wanting to dynamically modify the kernel in specific places
to
implement a custom kernel trace mechanism. The general idea is that, when
the
"trace" is off, there are NOP instruction sequences at various places in the
kernel. When the "trace" is turned on, those same NOPs are replaced by JMPs
to code that implements the trace (such as logging events, using the MSR and
PMC's etc..).
This was a trick that was done in my old days of OS/2 performance tools
developement to get trace information from the running kernel. In that
case,
we simply remapped the appropriate code segments to data segments (I think
back then it was called 'aliasing code segments') and used that segment to
make changes to the kernel code on the fly.
Is it possible to do the same thing in Linux?
Thanks
Tom
Tom Collins writes:
> I am wanting to dynamically modify the kernel in specific places to
> implement a custom kernel trace mechanism. The general idea is that,
> when the "trace" is off, there are NOP instruction sequences at various
> places in the kernel. When the "trace" is turned on, those same NOPs
> are replaced by JMPs to code that implements the trace (such as logging
> events, using the MSR and PMC's etc..).
>
> This was a trick that was done in my old days of OS/2 performance tools
> developement to get trace information from the running kernel.
>
> Is it possible to do the same thing in Linux?
See IBM "dprobes" project. It is basically what you are describing
(AFAIK). It makes sense, because a lot of the OS/2 folks are now working
on Linux.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Dprobes is one mechanism for doing what you want. It works the same way
OS/2 dynamic trace did. Another mecnahism, also available from the dprobes
web page is the GKHI (generalised kernel hooks interface). If you know you
want tracepoints in permanently assigned locations then you could code a
gkhi hook in the kernel which is essentially two jmps. When the hook is
inactive the first jmp bypasses the second, which jumps to the hook exit
dispatcher routine. When active the first jmp uses a zero offset. If you
use the gkhi you'll need to write you own hook exits, which presumably will
trace data and drop it into a trace buffer of your own making. Again if you
do decide to use ghki, please wait for 1.0 to be dropped next week
sometime.
If you go down the dprobes route you'll see that it inter-operates with
Linux Trace Toolkit to give you a dynamic tracing capability for Linux
(user and kernel space). We're currently working on custom formatting for
raw trace data events created by dprobes. If you're familiar with os/2 then
TRCUST might mean something to you in connection with custom formatting.
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
Andreas Dilger <[email protected]> on 27/02/2001 17:05:37
Please respond to Andreas Dilger <[email protected]>
To: "Collins, Tom" <[email protected]>
cc: [email protected]
Subject: Re: Dynamically altering code segments
Tom Collins writes:
> I am wanting to dynamically modify the kernel in specific places to
> implement a custom kernel trace mechanism. The general idea is that,
> when the "trace" is off, there are NOP instruction sequences at various
> places in the kernel. When the "trace" is turned on, those same NOPs
> are replaced by JMPs to code that implements the trace (such as logging
> events, using the MSR and PMC's etc..).
>
> This was a trick that was done in my old days of OS/2 performance tools
> developement to get trace information from the running kernel.
>
> Is it possible to do the same thing in Linux?
See IBM "dprobes" project. It is basically what you are describing
(AFAIK). It makes sense, because a lot of the OS/2 folks are now working
on Linux.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
Hey...thank you ... I have looked at the Linux Trace Toolkit
and was wondering if such a thing could be done. I also
have visited the dprobes web site and that looked like
it had the mechanisms I was looking for.
Will the updated version appear next week at the dprobes
web site? I assume that it will.
I have one more question: My trace code is currently
implemented as a kernel loadable module. Would I need
to change that so that it is built as part of the kernel,
or can I keep it as a loadable module? If I can keep it
as a module, I would ensure that the module would be the
only place that would enable/disable the trace, (don't
want the kernel jumping to a nonexistant address :O ..)
Thanks again...will be looking for the upgrade next week...
Tom
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Tuesday, February 27, 2001 12:15 PM
To: Andreas Dilger
Cc: Collins, Tom; [email protected]
Subject: Re: Dynamically altering code segments
Dprobes is one mechanism for doing what you want. It works the same way
OS/2 dynamic trace did. Another mecnahism, also available from the dprobes
web page is the GKHI (generalised kernel hooks interface). If you know you
want tracepoints in permanently assigned locations then you could code a
gkhi hook in the kernel which is essentially two jmps. When the hook is
inactive the first jmp bypasses the second, which jumps to the hook exit
dispatcher routine. When active the first jmp uses a zero offset. If you
use the gkhi you'll need to write you own hook exits, which presumably will
trace data and drop it into a trace buffer of your own making. Again if you
do decide to use ghki, please wait for 1.0 to be dropped next week
sometime.
If you go down the dprobes route you'll see that it inter-operates with
Linux Trace Toolkit to give you a dynamic tracing capability for Linux
(user and kernel space). We're currently working on custom formatting for
raw trace data events created by dprobes. If you're familiar with os/2 then
TRCUST might mean something to you in connection with custom formatting.
Richard Moore - RAS Project Lead - Linux Technology Centre (PISC).
http://oss.software.ibm.com/developerworks/opensource/linux
Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
IBM UK Ltd, MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
Andreas Dilger <[email protected]> on 27/02/2001 17:05:37
Please respond to Andreas Dilger <[email protected]>
To: "Collins, Tom" <[email protected]>
cc: [email protected]
Subject: Re: Dynamically altering code segments
Tom Collins writes:
> I am wanting to dynamically modify the kernel in specific places to
> implement a custom kernel trace mechanism. The general idea is that,
> when the "trace" is off, there are NOP instruction sequences at various
> places in the kernel. When the "trace" is turned on, those same NOPs
> are replaced by JMPs to code that implements the trace (such as logging
> events, using the MSR and PMC's etc..).
>
> This was a trick that was done in my old days of OS/2 performance tools
> developement to get trace information from the running kernel.
>
> Is it possible to do the same thing in Linux?
See IBM "dprobes" project. It is basically what you are describing
(AFAIK). It makes sense, because a lot of the OS/2 folks are now working
on Linux.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
"Collins, Tom" wrote:
[snip]
> I have one more question: My trace code is currently
> implemented as a kernel loadable module. Would I need
> to change that so that it is built as part of the kernel,
> or can I keep it as a loadable module? If I can keep it
> as a module, I would ensure that the module would be the
> only place that would enable/disable the trace, (don't
> want the kernel jumping to a nonexistant address :O ..)
[snip]
No need to do that, except if you modify the binary dynamically.
If that's the case, then you'll probably have to make it part
of the kernel. But ... if you modify your code to use the
pre-existing hooks that come with LTT, you may not need to
modify anything more than what is provided with by the LTT
patch. That is, you may want to know that LTT provides a
hooking mechanism similar, but less flexible, than the one
GKHI provides. The advantage, though, is that there are pre-defined
hooks inserted with the LTT patch which can be used right
away without further instrumentation.
As this type of hooking comes more and more in need, I'm
currently discussing with Richard the possibility of using
the LTT pre-defined hooks with GKHI in order to provide an
extensible hooking mechanism for the kernel that comes equipped
with an already quite useful set of hooks, which, of course,
can be dynamically enabled/disabled.
Using this type of hooking, you only need to worry about
registering/unregistering your callbacks since the kernel
doesn't jump in your code, but in the hooks management code
first.
Best regards,
Karim
===================================================
Karim Yaghmour
[email protected]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===================================================
"Collins, Tom" wrote:
> Hi...
>
> This is my first post, so if this is off topic for this list, please
direct
> me
> to another one that is more appropriate. Thanks
>
> That said, I am wanting to dynamically modify the kernel in specific
places
> to
> implement a custom kernel trace mechanism. The general idea is that,
when
> the
> "trace" is off, there are NOP instruction sequences at various places
in the
> kernel. When the "trace" is turned on, those same NOPs are replaced
by JMPs
> to code that implements the trace (such as logging events, using the
MSR and
> PMC's etc..).
>
> This was a trick that was done in my old days of OS/2 performance
tools
> developement to get trace information from the running kernel. In
that
> case,
> we simply remapped the appropriate code segments to data segments (I
think
> back then it was called 'aliasing code segments') and used that
segment to
> make changes to the kernel code on the fly.
>
> Is it possible to do the same thing in Linux?
>
the CS and DS segment descriptors already both map 0-4G, the DS being
read-write.
what you want is to change page protections, the system call mprotect()
comes
to mind.