Hi, Vojtech, Vojtech Horky on 2012-07-21: > >> >> 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? > The more I think about it, the more I see that to design a generic > editing support is a complicated task. But how about a demo only? For > example, code for editing zero-terminated strings. Do you think that > writing such example would make sense and is feasible?
I could try to design some editing support, at least for the relatively simple cases, but I don't know how long it would take to design and implement it. I think with the limited time remaining in GSoC, I should focus on more predictable tasks. > >> >> 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. > That is an ambitious task. And predicting its time demands is almost > impossible if you know very little about DWARF. So, we shall create > some subset of this task. IIRC it was Jiri Svoboda who came up > originally with the idea of using such library for a (to be created) > debugger. Maybe he can give some guidance on the scope of this task. One of the reasons DWARF is so complex is that it tries to provide debugging information even when the compiler uses optimization tricks and the values aren't stored directly in memory. Although DWARF is the most powerful solution in the long term, I could implement a simpler format that only works on global variables in much less time. The question is, how would the non-DWARF debugging information be generated? Thanks, Sean Bartell _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
