On Fri, Jul 20, 2012 at 02:48:30PM +0200, Vojtech Horky wrote: > 2012/7/20 Sean Bartell <[email protected]>: > >> > Another way would be to parse the script file and create C source code > >> > that declares structs and reads data. This would be an alternative to > >> > writing the C code directly when you need to parse binary data in > >> > HelenOS. I didn't include this in my GSoC plan because it wouldn't help > >> > with the debugger or interactive browser. > > > > - At compile time, you know which formats the program should work with. > > This could be handled by a separate program to generate C code from > > Bithenge scripts. > This is what I had in mind. More precisely, I was thinking rather > about some small portions. For me, perfect example is a single USB > descriptor or a stack frame. And I really do not want anything fancy > (see below) but rather a code generator that would - given the > following Bithenge script - be able to generate following code: > transform point = struct { > .x <- uint32le; > .y <- uint32le; > }; > Generated C code (just to get the feel): > struct point { > int x; > int y; > } > void read_point(void *buffer, struct point *out_point) > { > /* Either parse the script from some string or > build the bithenge_transform_t in the code. */ > ... > /* Not sure if the API can be used like this directly, > but that is not the point now. */ > out_point->x = bithenge_integer_node_value(node[0]); > out_point->y = bithenge_integer_node_value(node[1]); > } > > For the fancy side, you can support creating arrays or linked lists > for repeated elements etc. And then you can go for the performance > side and instead of generating code using Bithenge API, you can create > a single-purpose parser for the specific language (i.e. something like > a Bison over Bithenge). That generated parser can then be used without > Bithenge library at all. > > I think it would be very useful to have the simple generator > implemented. The developer then would not have to write the structure > definitions manually and would directly have functions for parsing > data into them.
Ah, now I understand you. This does seem quite useful. I would skip the stage where the Bithenge API is required, as it doesn't seem like it would save much work. > > I was only thinking of implementing basic browsing, and in fact I think > > it should take less than 7 days. > Can you, please, explain what you exactly mean by basic browsing? It could be either a command-line interface, where you can use commands like ls, cd, and find to explore the Bithenge tree, or a text user interface like top where you can move around in the tree with the arrow keys. It would only allow you to explore different parts of the tree and search for values. > >> For the editing support, I would say that having C API is a minimum. > >> It should allow following actions: > >> * edit primitive values > >> * add/delete from repetitions > >> * add/delete optional structs (aka conditional transforms) > >> Obviously, it must be possible to write the changes back and the > >> changes must be checked to be valid according to the grammar. If you > >> would built some command-line editor above this it would be nice. > > > > Editing primitive values is fine, but the other two are more difficult. > > If Bithenge knows the length of a repetition based on a parameter > > originating from a length field, how does it know to change the length > > field? If there are pointers in the file, how does Bithenge know to > I agree. But this functionality would be extremely useful and shall be > reflected somehow in the overall design of the library. It shall be > documented how to do it, at least on some abstract/high level. > > > change them? Nontrivial editing seems so open-ended that I think it > > should be left until after GSoC. > I agree. It would be great if the tool would be developed even after > GSoC. But still, it ought to be documented somehow... Does this mean you want me to think about the way editing support would be designed, even if I don't actually write code for it? > >> Regarding the DWARF support - I do not know the format well and I do > >> not know whether it is possible to implement core functionality only > >> first and extend later. What I would like to see in the end is a > > > > You can take a look at the DWARF info in a file with readelf -w > > <filename>. I think DWARF support is possible, but it might take > > 2+ weeks to reach a usable state. > You think it would be that demanding to rewrite the specification into > a Bithenge script or you have also something else in mind? I'm thinking of a program that reads DWARF information from an ELF file and converts it into a Bithenge script. You could then apply the script to a crash dump or to the task's memory. My concern is that I'm not familiar with DWARF and it looks complicated, so I can't predict how long it would take to make something useful. _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
