This is the mail archive of the
mailing list for the systemtap project.
Re: Status of kernel marker support
* David Smith (email@example.com) wrote:
> Mathieu Desnoyers wrote:
> >The best is to get the latest marker post I made on LKML, posted back
> >Fri, 28 Sep 2007 10:28:45. However, since you don't have the full
> >patchset to be merged in the -mm tree, it is probably best for me to
> >prepare a tarball. Here it is:
> Thanks for the tarball - I've been downloading the patches from a lkml
> web archive today and there were a bit mangled so this will help.
The mangling comes from the checkpatch.pl fixes Andrew added to his own
tree. If you want the, you would have to dig into the mm-commits mailing
> >Please keep in mind that it will break the tools you have, which depends
> >on the __markers_strings section to be a "real" section, not just a blob
> >of data.
> >In order to get the markers from the kernel image, you should use the
> >__start___markers and __stop___markers symbols. (since the __markers
> >section is packed in the .data section in the linker scripts, I think
> >__markers will just vanish) (see include/asm-generic/vmlinux.lds.h for
> >To get the markers from the kernel modules, using the __markers sections
> >seems like a good solution.
> I figured the removal of the __markers_string section was coming, so
> I've been trying to look into this.
> I've certainly seen that distinction in the 9/18 patch set - the main
> kernel has the __markers section packed in the .data section (surrounded
> by __start___markers and __stop___markers) but kernel modules have a
> distinct __markers section.
> Out of curiosity, was there a particular reason for the two different
> methods or did it just work out that way?
In the kernel, we don't "need" the markers section, because all we care
about is to get symbols pointing to the beginning and the end of the
section. For the modules, however, we need to have a distinct section
because we have to get pointers to the beginning of the section and get
the section size in load_module() (using find_sec). So, basically, yes,
it worked out that way. And yes, it is heavily inspired of the way other
sections are dealt with in the kernel and in load_module(). :)
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68