public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* Markers usage
@ 2008-01-29 16:00 Mathieu Desnoyers
  2008-01-29 16:15 ` Frank Ch. Eigler
  2008-03-19  3:02 ` Bug: duplicate marker entry in Modules.marker Wenji Huang
  0 siblings, 2 replies; 8+ messages in thread
From: Mathieu Desnoyers @ 2008-01-29 16:00 UTC (permalink / raw)
  To: Frank Ch. Eigler, systemtap

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Markers usage
  2008-01-29 16:00 Markers usage Mathieu Desnoyers
@ 2008-01-29 16:15 ` Frank Ch. Eigler
  2008-03-19  3:02 ` Bug: duplicate marker entry in Modules.marker Wenji Huang
  1 sibling, 0 replies; 8+ messages in thread
From: Frank Ch. Eigler @ 2008-01-29 16:15 UTC (permalink / raw)
  To: Mathieu Desnoyers; +Cc: systemtap


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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Bug: duplicate marker entry in Modules.marker
  2008-01-29 16:00 Markers usage Mathieu Desnoyers
  2008-01-29 16:15 ` Frank Ch. Eigler
@ 2008-03-19  3:02 ` Wenji Huang
  2008-03-19  3:07   ` Roland McGrath
  1 sibling, 1 reply; 8+ messages in thread
From: Wenji Huang @ 2008-03-19  3:02 UTC (permalink / raw)
  To: Mathieu Desnoyers; +Cc: systemtap

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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug: duplicate marker entry in Modules.marker
  2008-03-19  3:02 ` Bug: duplicate marker entry in Modules.marker Wenji Huang
@ 2008-03-19  3:07   ` Roland McGrath
  2008-03-19  7:53     ` Wenji Huang
  0 siblings, 1 reply; 8+ messages in thread
From: Roland McGrath @ 2008-03-19  3:07 UTC (permalink / raw)
  To: Wenji Huang; +Cc: Mathieu Desnoyers, systemtap

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.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug: duplicate marker entry in Modules.marker
  2008-03-19  3:07   ` Roland McGrath
@ 2008-03-19  7:53     ` Wenji Huang
  2008-03-19  8:03       ` Roland McGrath
  0 siblings, 1 reply; 8+ messages in thread
From: Wenji Huang @ 2008-03-19  7:53 UTC (permalink / raw)
  To: Roland McGrath; +Cc: Mathieu Desnoyers, systemtap

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug: duplicate marker entry in Modules.marker
  2008-03-19  7:53     ` Wenji Huang
@ 2008-03-19  8:03       ` Roland McGrath
  2008-03-20  1:05         ` Mathieu Desnoyers
  0 siblings, 1 reply; 8+ messages in thread
From: Roland McGrath @ 2008-03-19  8:03 UTC (permalink / raw)
  To: Wenji Huang; +Cc: Mathieu Desnoyers, systemtap

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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug: duplicate marker entry in Modules.marker
  2008-03-19  8:03       ` Roland McGrath
@ 2008-03-20  1:05         ` Mathieu Desnoyers
  2008-03-20  8:29           ` Roland McGrath
  0 siblings, 1 reply; 8+ messages in thread
From: Mathieu Desnoyers @ 2008-03-20  1:05 UTC (permalink / raw)
  To: Roland McGrath; +Cc: Wenji Huang, systemtap

* 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

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Bug: duplicate marker entry in Modules.marker
  2008-03-20  1:05         ` Mathieu Desnoyers
@ 2008-03-20  8:29           ` Roland McGrath
  0 siblings, 0 replies; 8+ messages in thread
From: Roland McGrath @ 2008-03-20  8:29 UTC (permalink / raw)
  To: Mathieu Desnoyers; +Cc: Wenji Huang, systemtap

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:

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2008-03-20  8:29 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-01-29 16:00 Markers usage Mathieu Desnoyers
2008-01-29 16:15 ` Frank Ch. Eigler
2008-03-19  3:02 ` Bug: duplicate marker entry in Modules.marker Wenji Huang
2008-03-19  3:07   ` Roland McGrath
2008-03-19  7:53     ` Wenji Huang
2008-03-19  8:03       ` Roland McGrath
2008-03-20  1:05         ` Mathieu Desnoyers
2008-03-20  8:29           ` Roland McGrath

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).