lkml.org 
[lkml]   [2008]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/5] ftrace: to kill a daemon

On Thu, 7 Aug 2008, Jeremy Fitzhardinge wrote:

> Steven Rostedt wrote:
> > Now, this was no easy task. We needed to add a section to every object
> > file with a list of pointers to the call sites to mcount. The idea I came
> > up with was to make a tmp.s file for every object just after it is compiled.
> > This tmp.s would then be compiled and relinked into the original object.
> > The tmp.s file would have something like:
> >
> > .section __mcount_loc,"a",@progbits
> > .quad location_of_mcount1
> > .quad location_of_mcount2
> > (etc)
> >
>
> I have a few concerns about this scheme:
>
> One is that you assume that all text is in a .text section, and that the
> offsets you compute on a per-section basis are going to be valid in the final
> kernel image. At the very least you should make each offset relative to its
> own function rather than inter-function.

I assume neither ;-)

This works with .text.sched .text.init .text.cpu etc. I use the first
function in each section as my reference point. This is the key.

>
> But it seems pretty fragile overall. Things like -ffunction-sections and
> section gc will invalidate the table you build up.

I don't see how. I'm referencing a function as my pointer. If this was
true, then I wouldn't be able to do

static void my_func(void) { [...] }
struct func_struct {
void (*func)(void);
} f = { my_func; };
My references end up exactly the same as the "f->func" reference does.
If my references are broken, so is this f->func. Which would be bad to
say the least.

>
> It seems to me that you can acheive the same effect by:
>
> 1. link vmlinux with "ld -q", which will leave the relocation
> information intact in the final object
> 2. use "readelf -r" to extract the relocation info, find the
> references to mcount and build a table
> 3. link that table into the kernel image
> 4. repeat to get a stable result

This doesn't seem any less complex than what I did. With this, I would
have to come up with another way to handle modules. This will make
things a lot more complex.

>
> Note that steps 2-4 are identical to kallsyms, both in intent and detail. The
> only difference is the precise table you build and the command you use to
> extract the info from the kernel. From a quick peek at the way Makefile
> implements kallsyms, it looks to me like it would be fairly easy to generalize
> so that you can do the mcount reloc processing in the same relink passes as
> kallsyms with minimal overhead on the kernel build time.

I could work on this. But again, this will put more work into module.c
that I would like to avoid.

>
> It just seems incredibly fiddly to be doing all this per-object.

Actually, this isn't that much fiddling. What I did was simply make a list
of pointers to the call sites to mcount. The pointers used the first
function of each section to offset against. I relinked in the list making
it just like a list done within C. All relocations and magic after this
will be handled just fine.

-- Steve



\
 
 \ /
  Last update: 2008-08-07 23:33    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site