Re: [PATCH 0/5] ftrace: to kill a daemon

[Steven Rostedt]

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/