Messages in this thread Patch in this message | | | From | John Garry <> | Subject | [Question] perf tools: lex parsing issue | Date | Mon, 23 Aug 2021 12:27:43 +0100 |
| |
Hi jirka,
If you remember from some time ago we discussed how the lex parsing creates strange aliases:
https://lore.kernel.org/lkml/20200320093006.GA1343171@krava/
I am no expert on l+y, but it seems that we simply don't set the term config field for known term types. Well, not for PARSE_EVENTS__TERM_TYPE_SAMPLE_PERIOD type anyway.
This super hack resolves that issue:
--->8----
--- a/tools/perf/util/parse-events.y +++ b/tools/perf/util/parse-events.y @@ -765,7 +765,12 @@ event_config ',' event_term struct list_head *head = $1; struct parse_events_term *term = $3
+ if (term->type_term == PARSE_EVENTS__TERM_TYPE_SAMPLE_PERIOD) { + term->config = strdup("period"); + } + if (!head) { parse_events_term__delete(term); YYABORT; --
----8-----
So we get "umask=0x80,period=0x30d40,event=0x6" now, rather than "umask=0x80,(null)=0x30d40,event=0x6", for the perf_pmu_alias.str, as an example.
Did you ever get a chance to look into this issue? Do you know how could or should this field be set properly?
Some more background: The reason I was looking at this is because I think it causes a problem for pmu-events (JSONs) aliasing for some PMUs. Specifically it's PMU which use "config=xxx" in sysfs files in /sys/bus/event_source/devices/PMUx/events/, rather than "event=xxx". The actual problem is that I trigger this warn in pmu.c: static void perf_pmu_assign_str(char *name, const char *field, char **old_str, char **new_str) { if (*new_str) { /* Have new string, check with old */ if (strcasecmp(*old_str, *new_str)) pr_debug("alias %s differs i ... <--- As I get "config=event=0xXXX" vs "config=(null)=0xXXX"
As I am not sure how to solve that yet, but, since we have config=(null), I thought it best to solve the first issue first.
Thanks, John
| |