Blame SOURCES/libtraceevent-Handle-parsing-of-REC-case.patch

00167c
From 62823da1bd46f24e2b498513a809011dfe16cd9b Mon Sep 17 00:00:00 2001
00167c
From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
00167c
Date: Tue, 8 Jun 2021 17:27:44 -0400
00167c
Subject: [PATCH] libtraceevent: Handle parsing of "(REC)->" case
00167c
00167c
If a trace event wraps the special __entry variable to dereference it with
00167c
parenthesis, it shows up in the trace event format file wrapping the
00167c
"(REC)" as well. For example, the "func_repeats" event passed the __entry
00167c
into a helper macro in the TP_printk() portion, and the macro correctly
00167c
wrapped its parameter in parenthesis. This caused the output to show:
00167c
00167c
 "(((u64)(REC)->top_delta_ts << 32) | (REC)->bottom_delta_ts)"
00167c
00167c
The parser then failed to parse the "(REC)->" portion, as it expected the
00167c
"->" to appear directly after the "REC". This is not a requirement, and
00167c
the parser should be able to handle such cases.
00167c
00167c
When this occurred, trace-cmd would error with the following message:
00167c
00167c
trace-cmd: No such file or directory
00167c
  Error: expected type 4 but read 5
00167c
00167c
Link: https://lore.kernel.org/linux-trace-devel/20210608172744.796e93b7@gandalf.local.home
00167c
00167c
Fixes: 6582b0a ("tools/events: Add files to create libtraceevent.a")
00167c
Reported-by: Julia Lawall <julia.lawall@inria.fr>
00167c
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
00167c
---
00167c
 src/event-parse.c | 27 ++++++++++++++++++++++++---
00167c
 1 file changed, 24 insertions(+), 3 deletions(-)
00167c
00167c
diff --git a/src/event-parse.c b/src/event-parse.c
00167c
index 97c1a97..1217491 100644
00167c
--- a/src/event-parse.c
00167c
+++ b/src/event-parse.c
00167c
@@ -2311,8 +2311,19 @@ process_entry(struct tep_event *event __maybe_unused, struct tep_print_arg *arg,
00167c
 	char *field;
00167c
 	char *token;
00167c
 
00167c
-	if (read_expected(TEP_EVENT_OP, "->") < 0)
00167c
-		goto out_err;
00167c
+	type = read_token_item(&token);
00167c
+	/*
00167c
+	 * Check if REC happens to be surrounded by parenthesis, and
00167c
+	 * return if that's the case, as "(REC)->" is valid.
00167c
+	 * but return TEP_EVENT_ITEM.
00167c
+	 */
00167c
+	if (type == TEP_EVENT_DELIM && strcmp(token, ")") == 0) {
00167c
+		*tok = token;
00167c
+		return TEP_EVENT_ITEM;
00167c
+	}
00167c
+
00167c
+	if (test_type_token(type, token,  TEP_EVENT_OP, "->"))
00167c
+		goto out_free;
00167c
 
00167c
 	if (read_expect_type(TEP_EVENT_ITEM, &token) < 0)
00167c
 		goto out_free;
00167c
@@ -2338,7 +2349,6 @@ process_entry(struct tep_event *event __maybe_unused, struct tep_print_arg *arg,
00167c
 
00167c
  out_free:
00167c
 	free_token(token);
00167c
- out_err:
00167c
 	*tok = NULL;
00167c
 	return TEP_EVENT_ERROR;
00167c
 }
00167c
@@ -3033,6 +3043,17 @@ process_paren(struct tep_event *event, struct tep_print_arg *arg, char **tok)
00167c
 	if (type == TEP_EVENT_ERROR)
00167c
 		goto out_free;
00167c
 
00167c
+	/*
00167c
+	 * If REC is surrounded by parenthesis, the process_arg()
00167c
+	 * will return TEP_EVENT_ITEM with token == ")". In
00167c
+	 * this case, we need to continue processing the item
00167c
+	 * and return.
00167c
+	 */
00167c
+	if (type == TEP_EVENT_ITEM && strcmp(token, ")") == 0) {
00167c
+		free_token(token);
00167c
+		return process_entry(event, arg, tok);
00167c
+	}
00167c
+
00167c
 	if (test_type_token(type, token, TEP_EVENT_DELIM, ")"))
00167c
 		goto out_free;
00167c
 
00167c
-- 
00167c
2.31.1
00167c