Date:	Tue, 27 Oct 2009 16:04:22 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Li Hong <lihong.hi@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/9] tracing: recordmcount.pl Amend the documentation
 according to the implementation

On Tue, 2009-10-27 at 14:54 +0800, Li Hong wrote:
> In documentation, we says we will use the first function in a section as a
> reference. Actually, the algorithm is: choose the first global function we
> meet as a reference. If there is none, choose the first local one. So let the
> documentation consistent to the code.
> 
> Also add several clarifications.
> 
> Signed-off-by: Li Hong <lihong.hi@...il.com>
> 
> diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
> index 090d300..ac908b3 100755
> --- a/scripts/recordmcount.pl
> +++ b/scripts/recordmcount.pl
> @@ -6,73 +6,88 @@
>  #                   all the offsets to the calls to mcount.
>  #
>  #
> -# What we want to end up with is a section in vmlinux called
> -# __mcount_loc that contains a list of pointers to all the
> -# call sites in the kernel that call mcount. Later on boot up, the kernel
> -# will read this list, save the locations and turn them into nops.
> -# When tracing or profiling is later enabled, these locations will then
> -# be converted back to pointers to some function.
> +# What we want to end up with this is a data area in .init.data in vmlinux 
> +# that contains a list of pointers to all the call sites in the kernel that
> +# call mcount. Later on boot up, the kernel will read this list, save the 
> +# locations and turn them into nops. When tracing or profiling is later 
> +# enabled, these locations will then be converted back to pointers to 
> +# some function.

Yes it is in .init.data, but the point is that we called it __mcount_loc
in the object files. I don't want to blindly throw that name away.

Something to the lines of this.

Each object file will have a section called __mcount_loc that will hold
the list of pointers to mcount callers. After final linking, the vmlinux
will have within .init.data the list of all callers to mcount between
_start_mcount_loc and __stop_mcount_loc.


>  #
>  # This is no easy feat. This script is called just after the original
>  # object is compiled and before it is linked.
>  #
> -# The references to the call sites are offsets from the section of text
> -# that the call site is in. Hence, all functions in a section that
> -# has a call site to mcount, will have the offset from the beginning of
> -# the section and not the beginning of the function.
> +# When parse this object file using 'objdump', the references to the call 
> +# sites are offsets from the section that the call site is in. Hence, all 
> +# functions in a section that  has a call site to mcount, will have the 
                                ^^
                            double space

> +# offset from the beginning of the section and not the beginning of the 
> +# function.
>  #
> -# The trick is to find a way to record the beginning of the section.
> -# The way we do this is to look at the first function in the section
> -# which will also be the location of that section after final link.
> +# But where this section will reside finally in vmlinx is undetermined at 
> +# this point. So we can't use this kind of offsets to record the final
> +# address of this call site.
> +#
> +# The trick is to change the call offset refering the start of a section to
                                         referring

> +# refering a function symbol in this section. During the link step, 'ld' will
     referring


The rest looks good.

-- Steve

> +# compute the final address according to the information we record.
> +# 
>  # e.g.
>  #
>  #  .section ".sched.text", "ax"
> -#

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

Powered by blists - more mailing lists