Hi Sean.
Please, see my comments below. I removed the parts where we already
agreed on something to make the e-mail shorter.
2012/7/20 Sean Bartell <wingedtachik...@gmail.com>:
>> > 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.
>> My preference depends which functionality you plan to implement into
>> these "interactive" tools. From my point of view, I do not care about
>> eye-candy stuff and I would be happy with command-line tools.
>>
>> For me, important functionality of the browser is search (e.g. file
>> system node where .filename is hello.c) and scalability (i.e.
>> reasonable performance when iterating over huge inputs).
>
> 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?
>> 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...
>> 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?
>> In your timeline, you mentioned FAT format but it can be something
>> else as well. Ideally something that would demonstrate all
>> capabilities of your implementation. If that is not possible with
>> single format, using several simpler ones is possible as well, of
>> course. For example, TCP frames, call stacks or USB transaction
>> frames. Another useful example is exploring another task's memory -
>> e.g. crawling through some linked list when pointed to its head.
>
> I still think FAT is a good goal because it needs a variety of different
> features to decode fully. TCP frames could be a good intermediate goal.
I didn't meant it that FAT is a bad goal. I was only suggesting that
there are other possibilities if FAT would be too time-demanding to
describe in Bithenge.
>> I think you can now concentrate on the repetitions, bitfields etc. and
>> meanwhile, the rest (browser, editor, DWARF) could be discussed in
>> more detail.
>
> I'll send a new update tomorrow with a plan for the next few weeks.
Great!
Thanks for the report.
- Vojta
_______________________________________________
HelenOS-devel mailing list
HelenOS-devel@lists.modry.cz
http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
