From 27e450e8e17a1d3fc761f8fb0a79b5915d874bc6 Mon Sep 17 00:00:00 2001
From: pompolic <pompolic@special-circumstanc.es>
Date: Wed, 8 Jun 2022 21:01:40 +0200
Subject: [PATCH] (WIP) Add command to apply the "current" parser
- Stops when the HParsedToken is returned
- prints AST
- attempts to continue to the next h_do_parse invocation
---
gdb-port/commands.py | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)
diff --git a/gdb-port/commands.py b/gdb-port/commands.py
index 5cce790..9c2e098 100644
--- a/gdb-port/commands.py
+++ b/gdb-port/commands.py
@@ -205,3 +205,22 @@ class HammerParserPrintAST(gdb.Command):
ast_manager.print_ast()
HammerParserPrintAST()
+
+# Step until the "current" parser is applied and returns the HParsedToken, stopping in h_do_parse
+class HammerParseApply(gdb.Command):
+ def __init__(self):
+ super(HammerParseApply, self).__init__("hammer-parse-apply", gdb.COMMAND_OBSCURE)
+ print(":: hammer-parse-apply")
+
+ def invoke(self, arg, from_tty):
+ top_level_parse.setup_ast_stack_index(0) #TODO: is it a problem if this command overwrites it? would it better to use a convenience variable, as with parse-step?
+ # TODO: can this result in a state where we stop due to hammer_step_counter being set, before the parser is applied?
+ # TODO: Would it be better to just never allow stopping at the RET breakpoint?
+
+ # Stop at next HDoParseRetBreakpoint
+ gdb.execute("continue")
+ gdb.set_convenience_variable("hammer_step_counter", 1)
+ # Stop at the next h_do_parse invocation
+ gdb.execute("continue")
+
+HammerParseApply()
--
GitLab