[Okteta] [PATCH] Support for pointers in data structures viewer

[Alex Richardson]

Hi,

sorry for the late reply, I was on holiday until now.

Alessandro Di Federico schrieb am Sonntag, 12. August 2012 09:59:47
> Hi, I've just discovered Okteta and I liked it very much, in particular
> for its data structures viewer, however I thought it could be better, so
> I decided to implement a feature I find very useful: pointers. My effort
> is currently focused on being able to completely parse a whole ELF file
> in a single tree. For instance the Elf32_Ehdr struct (`man elf` to see
> its documentation) contains a sh_off field which is a "pointer" to an
> offset in the file, where an array (with length e_shnum) of Elf32_Shdr
> structs begins.
Nice to hear that you like it :)
I had planned on implementing pointers/offsets ages ago, but until now didn't
manage to start working on it. Very nice that you did it!

> Attached you can see an example OSD for ELF with the pointer element and
> a screenshot of the result.
> 
> So here's a resume of what I've done:
>       * Implemented the PointerDataInformation class, which allows to
>         define a pointer to an offset in the file. The contents of the
>         pointed that is parsed after the parsing of the whole structure
>         is finished, so I can use as array size (for instance) a field
>         which comes after the pointer field itself.
Very good, that solves the problem with reading uninitialized data.
>       * Added the totallength attribute to the array element, which
>         allows to set a maximum size in bytes for the array instead that
>         in number of elements. This is useful when there's a list of
>         string and you know their size altogether but not the individual
>         sizes.
Valid use case, hadn't thought of that so far.
>       * Slightly changed the way findChildForDynamicArrayLength works,
>         now it starts from the element which should be added and goes up
>         to the parents searching in all its elements, except the element
>         we came from.
Yes, makes sense with delayed parsing. Sofar only looking at fields defined
before made sense.


> I also had to remove some QSharedPointer (otherwise okteta crashed
> badly) and I left some TODOs for that because I'm not sure that simply
> remove them is a solution.
I will have to look into that and see why it happens. Doesn't make much sense to
me that it works without QSharedPointer, maybe the cause is somewhere else.


> In future I'd like to add also these features:
>       * Pointers to other parts of the tree (for instance
>         Elf32_Sym.st_name is the index of a string in the symbol table)
>       * Union selector, which means an expression to choose the correct
>         field of the union to use/display/highlight
>       * Virtual memory, which means to associate a virtual memory
>         address to a certain offset in the file, this way we could parse
>         pointers on core dumps (or memory dumps in general) too
All very good ideas. I am currently working on a format description for the 
Java .class file format and need indices and maybe union selectors there.

Good to hear that you want to carry on working on it!

Another thing that may be useful is also having relative pointers (i.e. from
the current file offset).
 
> It's still a draft but I hope you like the patch. I'd like to hear your
> opinion on all the points I've mentioned, and I'm available to modify
> the patch to follow your suggestions.

Most of the patch looks fine to me, however I did quite a bit of refactoring
locally so I will have to adapt the patch a little bit.

I will adapt the patch to these changes and check whether everything works.
Once that has been done your elf structure defintion can then replace the
currently installed version.


Bye
Alex