Markers usage

Markers usage

[Mathieu Desnoyers]

Hi Frank,

Quick question :

I see in your presentation that using markers arguments is done with
$arg2. Is it the field name or a simply the argument number ?

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Markers usage

[Frank Ch. Eigler]

Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> writes:

> I see in your presentation that using markers arguments is done with
> $arg2. Is it the field name or a simply the argument number ?

That's the argument number.  The arguments are only informally named
in the marker format string, so they don't form an unambiguous naming
convention.  However, we could export parameters by that name too when
present.  (I'll add the suggestion to our bug #4446.)

- FChE

Bug: duplicate marker entry in Modules.marker

[Wenji Huang]

Hi Mathieu,

When I use marker in 2.6.25-rc5, found there could be duplicate marker 
entries in Modules.marker.

It can be reproduced through these steps:
     1. define trace_mark(mark1, "format 1, %d",var1). There is the 
entry in Modules.marker.
		mark1 vmlinux format 1, %d
     2. build and boot the kernel
     3. modify the marker, such as trace_mark(mark1, "format 2, 
%d",var1). There are two entries:
		mark1 vmlinux format 1, %d
		mark1 vmlinux format 2, %d

Although marker supports multi handlers, the only one marker is defined 
in kernel and stap script kernel.mark("mark1")
will be triggered two times.

Best regards,
Wenji

Re: Bug: duplicate marker entry in Modules.marker

[Roland McGrath]

I think modpost always merges the contents of the old file.
This is necessary for the separate runs for vmlinux and each module.
Perhaps the run for vmlinux should wipe the file.
But I'm not sure off hand that modpost will always be run for
each .ko in that case.

Re: Bug: duplicate marker entry in Modules.marker

[Wenji Huang]

Roland McGrath wrote:
> I think modpost always merges the contents of the old file.
> This is necessary for the separate runs for vmlinux and each module.
> Perhaps the run for vmlinux should wipe the file.
> But I'm not sure off hand that modpost will always be run for
> each .ko in that case.
> 

Yes, modpost will re run in building for every module.

For .ko, there are two cases:

  1. In kernel source tree, some stuff which are configured as M:
    Define marker in module -> "make modules" -> Modify -> "make modules"
       there are two entries.

  2. External module, such as probe module generated by staprun.
    Define marker in module -> Build -> Modify -> Build
    there is only one entry. In fact, another Module.markers exists in
    the module dir.

So I think just only to empty the file in the run for vmlinux is not
enough. "make modules" need to keep the marker entry in vmlinux and 
regenerate
others.

Regards.
Wenji

Re: Bug: duplicate marker entry in Modules.marker

[Roland McGrath]

I modelled Module.markers generation on Module.symvers generation.
How does it deal with the problem?

Re: Bug: duplicate marker entry in Modules.marker

[Mathieu Desnoyers]

* Roland McGrath (roland@redhat.com) wrote:
> I modelled Module.markers generation on Module.symvers generation.
> How does it deal with the problem?

Is is me or they seem to detect, for each symbol, if it has changed and
they overwrite the original one ?

We could do the same with markers I guess. After having sorted them, we
could determine, for each, if there was an entry in the original file
and modify it if needed.

Separate concern : I would really like to have some kind of format
string coherency verification in there : when we extract the markers
from a build tree, we should be able to check that all the markers with
the same name have the same format string. Otherwise the incoherency
will only be detected at runtime.

Regards,

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Bug: duplicate marker entry in Modules.marker

[Roland McGrath]

If marker names are unique, then it's easy to deal with.  When I was doing
the modpost hack, I think I recall seeing something with an overloaded name
used with two different formats.  I thought it was nutty, but that it
appeared to be the plan.  So I made modpost only look for duplicates of the
whole "name module format" line.

Come to think of it, maybe it's easy to deal with another way anyhow.
All the lines from the old file that use the module name we are processing
now should be replaced, right?  What about this?


Thanks,
Roland

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 695b5d6..e23147b 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1973,7 +1973,8 @@ static void read_markers(const char *fname)
 			mod->skip = 1;
 		}
 
-		add_marker(mod, marker, fmt);
+		if (!mod->skip)
+			add_marker(mod, marker, fmt);
 	}
 	return;
 fail:

Re: Bug: duplicate marker entry in Modules.marker

[Roland McGrath]

Sorry, should have been (?):

diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 695b5d6..ca8015d 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1973,7 +1973,8 @@ static void read_markers(const char *fname)
 			mod->skip = 1;
 		}
 
-		add_marker(mod, marker, fmt);
+		if (mod->skip)
+			add_marker(mod, marker, fmt);
 	}
 	return;
 fail:

Re: Bug: duplicate marker entry in Modules.marker

[Wenji Huang]

The marker maybe has same name, but different format.

Roland McGrath wrote:
> Sorry, should have been (?):
> 
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 695b5d6..ca8015d 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -1973,7 +1973,8 @@ static void read_markers(const char *fname)
>  			mod->skip = 1;
>  		}
>  
> -		add_marker(mod, marker, fmt);
> +		if (mod->skip)
> +			add_marker(mod, marker, fmt);
>  	}

Good solution, it's OK in case of modules, but vmlinux. I just defined 
marker in built-in code and changed it.
Still two entries.
I guess the above modification together with emptying the file before 
run of modpost for vmlinux
will solve the problem.

Regards,
Wenji