[lkml]   [2008]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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    [W:0.023 / U:44.792 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site