ftrace scripts and make V=1

ftrace scripts and make V=1

[Dave Airlie]

Hey,

So I spent 3-4 hrs today (I'm stupid yes) tracking down a .o breakage by
blaming rawhide gcc/binutils as I was using make V=1and seeing only the
compiler chain running,

However some ftrace script was sneaking in afterwards
and screwing up the .o without mentioning itself.

Surely V=1 should print all these shitty scripts its running?

Dave.

Re: ftrace scripts and make V=1

[Ingo Molnar]

* Dave Airlie <airlied@gmail.com> wrote:

> Hey,
> 
> So I spent 3-4 hrs today (I'm stupid yes) tracking down a .o 
> breakage by blaming rawhide gcc/binutils as I was using make 
> V=1and seeing only the compiler chain running,

Hm, is this that powerpc related build bug you just reported?

> However some ftrace script was sneaking in afterwards and screwing 
> up the .o without mentioning itself.
> 
> Surely V=1 should print all these shitty scripts its running?

Definitely, and it should print non-shitty scripts too,
just in case ;-)

	Ingo

Re: ftrace scripts and make V=1

[Sam Ravnborg]

On Wed, Aug 05, 2009 at 05:23:26PM +1000, Dave Airlie wrote:
> Hey,
> 
> So I spent 3-4 hrs today (I'm stupid yes) tracking down a .o breakage by
> blaming rawhide gcc/binutils as I was using make V=1and seeing only the
> compiler chain running,
> 
> However some ftrace script was sneaking in afterwards
> and screwing up the .o without mentioning itself.
> 
> Surely V=1 should print all these shitty scripts its running?

The problem is that V=1 is already too chatty,
so people sometimes hide their stuff - as in this case.

I have for some time thought about adding some option
so we can select between:
 - less chatty than today - but print the usefull stuff
 - full debug - print almost everything

It is not that this is hard to implment.
But I never have made up my mind how to enable this.

V=1 - could be the "less chatty" mode
V=2 - could be the "full debug mode"

But we already use "V=2" to tell what caused a file to be rebuild.
This is on the other hand very seldomly used so we could get
away with a new way to request this.
So we limit V=n to select between different verbosity levels.

What do you think?

	Sam

Re: ftrace scripts and make V=1

[Ingo Molnar]

* Sam Ravnborg <sam@ravnborg.org> wrote:

> On Wed, Aug 05, 2009 at 05:23:26PM +1000, Dave Airlie wrote:
> > Hey,
> > 
> > So I spent 3-4 hrs today (I'm stupid yes) tracking down a .o breakage by
> > blaming rawhide gcc/binutils as I was using make V=1and seeing only the
> > compiler chain running,
> > 
> > However some ftrace script was sneaking in afterwards
> > and screwing up the .o without mentioning itself.
> > 
> > Surely V=1 should print all these shitty scripts its running?
> 
> The problem is that V=1 is already too chatty,
> so people sometimes hide their stuff - as in this case.
> 
> I have for some time thought about adding some option
> so we can select between:
>  - less chatty than today - but print the usefull stuff
>  - full debug - print almost everything
> 
> It is not that this is hard to implment.
> But I never have made up my mind how to enable this.
> 
> V=1 - could be the "less chatty" mode
> V=2 - could be the "full debug mode"
> 
> But we already use "V=2" to tell what caused a file to be rebuild.
> This is on the other hand very seldomly used so we could get
> away with a new way to request this.
> So we limit V=n to select between different verbosity levels.
> 
> What do you think?

definitely sounds useful ...

	Ingo

Re: ftrace scripts and make V=1

[Andi Kleen]

Dave Airlie <airlied@gmail.com> writes:

> Hey,
>
> So I spent 3-4 hrs today (I'm stupid yes) tracking down a .o breakage by
> blaming rawhide gcc/binutils as I was using make V=1and seeing only the
> compiler chain running,
>
> However some ftrace script was sneaking in afterwards
> and screwing up the .o without mentioning itself.
>
> Surely V=1 should print all these shitty scripts its running?

I ran into the same problem some time ago and fixed it with these
two patches patch.

-Andi

---

kbuild: Fail build if recordmcount.pl fails

When this script fails the build should fail too. Otherwise there
are mysterious build failures later.

Signed-off-by: Andi Kleen <ak@linux.intel.com>

---
 scripts/Makefile.build |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6.31-rc1-ak/scripts/Makefile.build
===================================================================
--- linux-2.6.31-rc1-ak.orig/scripts/Makefile.build
+++ linux-2.6.31-rc1-ak/scripts/Makefile.build
@@ -206,7 +206,7 @@ cmd_modversions =							\
 endif
 
 ifdef CONFIG_FTRACE_MCOUNT_RECORD
-cmd_record_mcount = perl $(srctree)/scripts/recordmcount.pl "$(ARCH)" \
+cmd_record_mcount = set -e ; perl $(srctree)/scripts/recordmcount.pl "$(ARCH)" \
 	"$(if $(CONFIG_64BIT),64,32)" \
 	"$(OBJDUMP)" "$(OBJCOPY)" "$(CC)" "$(LD)" "$(NM)" "$(RM)" "$(MV)" \
 	"$(if $(part-of-module),1,0)" "$(@)";


---

kbuild: Echo the record_mcount command

I had some problems with record_mcount in the Makefile and it was hard
to track down. Echo it by default to make it easier to diagnose.

Signed-off-by: Andi Kleen <ak@linux.intel.com>

---
 scripts/Makefile.build |    1 +
 1 file changed, 1 insertion(+)

Index: linux-2.6.31-rc1-ak/scripts/Makefile.build
===================================================================
--- linux-2.6.31-rc1-ak.orig/scripts/Makefile.build
+++ linux-2.6.31-rc1-ak/scripts/Makefile.build
@@ -216,6 +216,7 @@ define rule_cc_o_c
 	$(call echo-cmd,checksrc) $(cmd_checksrc)			  \
 	$(call echo-cmd,cc_o_c) $(cmd_cc_o_c);				  \
 	$(cmd_modversions)						  \
+	$(call echo-cmd,record_mcount)					  \
 	$(cmd_record_mcount)						  \
 	scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,cc_o_c)' >    \
 	                                              $(dot-target).tmp;  \


-- 
ak@linux.intel.com -- Speaking for myself only.

Re: ftrace scripts and make V=1

[Steven Rostedt]

On Wed, 5 Aug 2009, Ingo Molnar wrote:

> 
> * Dave Airlie <airlied@gmail.com> wrote:
> 
> > Hey,
> > 
> > So I spent 3-4 hrs today (I'm stupid yes) tracking down a .o 
> > breakage by blaming rawhide gcc/binutils as I was using make 
> > V=1and seeing only the compiler chain running,
> 
> Hm, is this that powerpc related build bug you just reported?

Well we tracked it down and it is powerpc64 specific.

Seems that in drivers/hwmon/lm93.c there's a function called:

   LM93_IN_FROM_REG()

But PPC64 has function descriptors and the real function names (the ones 
you see in objdump) start with a '.'. Thus this in objdump you have:

 Disassembly of section .text:

 0000000000000000 <.LM93_IN_FROM_REG>:
       0:       7c 08 02 a6     mflr    r0
       4:       fb 81 ff e0     std     r28,-32(r1)


The function name used is .LM93_IN_FROM_REG. But gcc considers symbols 
that start with ".L" as a special symbol that is used inside the assembly 
stage.

The nm passed into recordmcount uses the --synthetic option which shows 
the ".L" symbols (my runs outside of the build did not include the 
--synthetic option, so my older patch worked). We see the function as a 
local.

Now to capture all the locations that use "mcount" we need to have a 
reference to link into the object file a list of mcount callers. We need a 
reference that will not disappear. We try to use a global function and if 
that does not work, we use a local function as a reference. But to relink 
the section back into the object, we need to make it global. In this case, 
we run objcopy using --globalize-symbol and --localize-symbol to convert 
the symbol into a global symbol, link the mcount list, then convert it 
back to a local symbol.

This works great except for this case. .L* symbols can not be converted 
into a global symbol, and the mcount section referencing it will remain 
unresolved.

Try this patch and see if it fixes your issue.

Thanks!

-- Steve

diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index d29baa2..4889c44 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -414,7 +414,10 @@ while (<IN>) {
 	    $offset = hex $1;
 	} else {
 	    # if we already have a function, and this is weak, skip it
-	    if (!defined($ref_func) && !defined($weak{$text})) {
+	    if (!defined($ref_func) && !defined($weak{$text}) &&
+		 # PPC64 can have symbols that start with .L and
+		 # gcc considers these special. Don't use them!
+		 $text !~ /^\.L/) {
 		$ref_func = $text;
 		$offset = hex $1;
 	    }

Re: ftrace scripts and make V=1

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> Well we tracked it down and it is powerpc64 specific.
> 
> Seems that in drivers/hwmon/lm93.c there's a function called:
> 
>    LM93_IN_FROM_REG()
> 
> But PPC64 has function descriptors and the real function names (the ones 
> you see in objdump) start with a '.'. Thus this in objdump you have:
> 
>  Disassembly of section .text:
> 
>  0000000000000000 <.LM93_IN_FROM_REG>:
>        0:       7c 08 02 a6     mflr    r0
>        4:       fb 81 ff e0     std     r28,-32(r1)
> 
> 
> The function name used is .LM93_IN_FROM_REG. But gcc considers 
> symbols that start with ".L" as a special symbol that is used 
> inside the assembly stage.
> 
> The nm passed into recordmcount uses the --synthetic option which 
> shows the ".L" symbols (my runs outside of the build did not 
> include the --synthetic option, so my older patch worked). We see 
> the function as a local.
> 
> Now to capture all the locations that use "mcount" we need to have 
> a reference to link into the object file a list of mcount callers. 
> We need a reference that will not disappear. We try to use a 
> global function and if that does not work, we use a local function 
> as a reference. But to relink the section back into the object, we 
> need to make it global. In this case, we run objcopy using 
> --globalize-symbol and --localize-symbol to convert the symbol 
> into a global symbol, link the mcount list, then convert it back 
> to a local symbol.
> 
> This works great except for this case. .L* symbols can not be 
> converted into a global symbol, and the mcount section referencing 
> it will remain unresolved.
> 
> Try this patch and see if it fixes your issue.
> 
> Thanks!
> 
> -- Steve
> 
> diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
> index d29baa2..4889c44 100755
> --- a/scripts/recordmcount.pl
> +++ b/scripts/recordmcount.pl
> @@ -414,7 +414,10 @@ while (<IN>) {
>  	    $offset = hex $1;
>  	} else {
>  	    # if we already have a function, and this is weak, skip it
> -	    if (!defined($ref_func) && !defined($weak{$text})) {
> +	    if (!defined($ref_func) && !defined($weak{$text}) &&
> +		 # PPC64 can have symbols that start with .L and
> +		 # gcc considers these special. Don't use them!
> +		 $text !~ /^\.L/) {
>  		$ref_func = $text;
>  		$offset = hex $1;
>  	    }

Ah, indeed. I'm wondering whether also emitting a build warning 
would be useful - just in the (admittedly unlikely) case of someone 
wondering about why LM93_IN_FROM_REG does not show up in function 
traces.

	Ingo

[tip:tracing/urgent] tracing: do not use functions starting with .L in recordmcount.pl

[tip-bot for Steven Rostedt]

Commit-ID:  3f6e968ef4e1d8d93d8a8505461b0e50a9e97ad8
Gitweb:     http://git.kernel.org/tip/3f6e968ef4e1d8d93d8a8505461b0e50a9e97ad8
Author:     Steven Rostedt <rostedt@goodmis.org>
AuthorDate: Wed, 5 Aug 2009 22:00:14 -0400
Committer:  Steven Rostedt <rostedt@goodmis.org>
CommitDate: Wed, 5 Aug 2009 22:45:07 -0400

tracing: do not use functions starting with .L in recordmcount.pl

On Wed, 5 Aug 2009, Ingo Molnar wrote:
> * Dave Airlie <airlied@gmail.com> wrote:
>
> > Hey,
> >
> > So I spent 3-4 hrs today (I'm stupid yes) tracking down a .o
> > breakage by blaming rawhide gcc/binutils as I was using make
> > V=1and seeing only the compiler chain running,
>
> Hm, is this that powerpc related build bug you just reported?

Well we tracked it down and it is powerpc64 specific.

Seems that in drivers/hwmon/lm93.c there's a function called:

   LM93_IN_FROM_REG()

But PPC64 has function descriptors and the real function names (the ones
you see in objdump) start with a '.'. Thus this in objdump you have:

 Disassembly of section .text:

 0000000000000000 <.LM93_IN_FROM_REG>:
       0:       7c 08 02 a6     mflr    r0
       4:       fb 81 ff e0     std     r28,-32(r1)

The function name used is .LM93_IN_FROM_REG. But gcc considers symbols
that start with ".L" as a special symbol that is used inside the assembly
stage.

The nm passed into recordmcount uses the --synthetic option which shows
the ".L" symbols (my runs outside of the build did not include the
--synthetic option, so my older patch worked). We see the function as a
local.

Now to capture all the locations that use "mcount" we need to have a
reference to link into the object file a list of mcount callers. We need a
reference that will not disappear. We try to use a global function and if
that does not work, we use a local function as a reference. But to relink
the section back into the object, we need to make it global. In this case,
we run objcopy using --globalize-symbol and --localize-symbol to convert
the symbol into a global symbol, link the mcount list, then convert it
back to a local symbol.

This works great except for this case. .L* symbols can not be converted
into a global symbol, and the mcount section referencing it will remain
unresolved.

Reported-by: Dave Airlie <airlied@gmail.com>
LKML-Reference: <alpine.DEB.2.00.0908052011590.5010@gandalf.stny.rr.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>


---
 scripts/recordmcount.pl |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index d29baa2..4889c44 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -414,7 +414,10 @@ while (<IN>) {
 	    $offset = hex $1;
 	} else {
 	    # if we already have a function, and this is weak, skip it
-	    if (!defined($ref_func) && !defined($weak{$text})) {
+	    if (!defined($ref_func) && !defined($weak{$text}) &&
+		 # PPC64 can have symbols that start with .L and
+		 # gcc considers these special. Don't use them!
+		 $text !~ /^\.L/) {
 		$ref_func = $text;
 		$offset = hex $1;
 	    }

Re: [tip:tracing/urgent] tracing: do not use functions starting with .L in recordmcount.pl

[Ingo Molnar]

* tip-bot for Steven Rostedt <rostedt@goodmis.org> wrote:

> Commit-ID:  3f6e968ef4e1d8d93d8a8505461b0e50a9e97ad8
> Gitweb:     http://git.kernel.org/tip/3f6e968ef4e1d8d93d8a8505461b0e50a9e97ad8
> Author:     Steven Rostedt <rostedt@goodmis.org>
> AuthorDate: Wed, 5 Aug 2009 22:00:14 -0400
> Committer:  Steven Rostedt <rostedt@goodmis.org>
> CommitDate: Wed, 5 Aug 2009 22:45:07 -0400
> 
> tracing: do not use functions starting with .L in recordmcount.pl
> 
> On Wed, 5 Aug 2009, Ingo Molnar wrote:
> > * Dave Airlie <airlied@gmail.com> wrote:
> >
> > > Hey,
> > >
> > > So I spent 3-4 hrs today (I'm stupid yes) tracking down a .o
> > > breakage by blaming rawhide gcc/binutils as I was using make
> > > V=1and seeing only the compiler chain running,
> >
> > Hm, is this that powerpc related build bug you just reported?

Btw., a small nitpick for future commit logs: it would have been 
nice to keep this email quote excerpt out of the changelog, it looks 
a bit messy. If it contains useful info then it can be paraphrased 
into the usual 'Dave Airlie reported ...' sentence(s).

Thanks,

	Ingo

Re: ftrace scripts and make V=1

[Steven Rostedt]

On Thu, 6 Aug 2009, Ingo Molnar wrote:
> > diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
> > index d29baa2..4889c44 100755
> > --- a/scripts/recordmcount.pl
> > +++ b/scripts/recordmcount.pl
> > @@ -414,7 +414,10 @@ while (<IN>) {
> >  	    $offset = hex $1;
> >  	} else {
> >  	    # if we already have a function, and this is weak, skip it
> > -	    if (!defined($ref_func) && !defined($weak{$text})) {
> > +	    if (!defined($ref_func) && !defined($weak{$text}) &&
> > +		 # PPC64 can have symbols that start with .L and
> > +		 # gcc considers these special. Don't use them!
> > +		 $text !~ /^\.L/) {
> >  		$ref_func = $text;
> >  		$offset = hex $1;
> >  	    }
> 
> Ah, indeed. I'm wondering whether also emitting a build warning 
> would be useful - just in the (admittedly unlikely) case of someone 
> wondering about why LM93_IN_FROM_REG does not show up in function 
> traces.

Actually, it just skips it as the function to use as the reference point. 
It should still record the mcount for that function. Now we may have an 
issues if all functions in a section start with .L

-- Steve