Ah, thanks! I took a quick look today and I'll look more today. I should have a patch ready in about two weeks, but I'm gonna attach some notes and a link to the git repository I'm working on, in case anyone on the mailing list wants to take a look at it and provide feedback and/or request things while I'm implementing the JSON dump portion of the project. This is all very incomplete, so set your expectations appropriately.
The repo itself is here: https://github.com/cheezeburglar/gcc Most of the action is in tree-dump.cc right now, but I plan to split off all the json dumping capability in it's own file later: https://github.com/cheezeburglar/gcc/blob/master/gcc/tree-dump.cc And, here's an email I sent to Richard (and forgot to cc to the mailing list) along with notes that he gave me during a meeting: In general the idea is that the dump flag -fdump-tree-original-json emits something of the form {"index": 1, "tree_code": foo, "child_1": {...}, ... "child_n": {...}} or {"index": 1, "tree_code": foo, "children": [{...}, {...}]} where index denotes not any part of the tree class but the order in which the nodes are traversed and the "child_n" or "children" contain the index, tree_codes, and other data in the child nodes. In the above example, I don't think it's worth recursing over each child nodes' child. And, if we look at say COMPLEX_TYPE, we'd want each child node to contain at least some of the data if not all (save the child node's children). One option to translating this to HTML is making each index effectively a hyperlink to i's node, so one could traverse the tree by clicking on each index. We could also feed in a recursion depth parameter here, so an individual HTML document would display one node, it's children, and it's children's children up to some depth (possibly 0). I haven't yet gotten the JSON emitted in either of the above forms, so I haven't looked at the technical details of this too closely yet. //Look at debug_tree //Show some examples to community, feedback for HTML once prototypical examples // Also track addresses of tree_nodes, use for unique identifier instead of visitation order? // Make sure that we iterate over data fields in parent nest; in particular make sure all those that are in RAW and maybe all // Static_flag, e.g., has different semantics in different positions - all in tree-core.h. Worry about overloaded meaning. see debug_tree for inspiration // Keep track of different semantics in differing positions. dump_generic_node() might not do this All of this is essentially just a debugging nicety, so I think it'd be acceptable to write this translator in Python. One would also, probably, call into this utility from GDB. I have not yet looked deeply into GDB's python API yet, but I *think* having this script in Python would be ever-so-more convenient. One would ultimately call some function from GDB that takes in some tree and displays all of the above in some web browser. Best, Thor On Wed, Jul 24, 2024 at 6:05 PM David Malcolm <dmalc...@redhat.com> wrote: > > On Wed, 2024-07-24 at 02:59 -0500, Thor Preimesberger via Gcc wrote: > > Sure - we actually already emit json in optinfo-emit-json.cc, and > > there > > are implementations of json and pretty-printing/dumping it out also. > > I got > > a hacky version of our current raw dump working with json objects, > > but > > using the functions and data structures in tree-dump.* "as is" would > > require further processing of the dump's output (and I think some > > further > > modification) in order to make linking related nodes possible - I > > think, at > > least. This seems expensive computationally, so I'm currently > > re-implementing the function dump_generic_nodes from tree-pretty- > > print.cc > > so that it emits JSON instead. > > FWIW if you're working with gcc/json.h I just pushed various > improvements; see: > https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658194.html > > In particular: > https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658195.html > saves me a *lot* of typing in gdb when debugging json stuff. > > Hope this is helpful > Dave >
