Fork us on GitHub Follow us on Facebook Follow us on Twitter

Changes between Initial Version and Version 4 of Ticket #317


Ignore:
Timestamp:
2012-03-08T14:10:17Z (8 years ago)
Author:
Martin Decky
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #317

    • Property Keywords gsoc12 added
    • Property Component changed from helenos/unspecified to helenos/app/other
    • Property Milestone changed from 0.5.0 to 0.5.1
  • Ticket #317 – Description

    initial v4  
    1 As suggested by Martin Sucha, it would be useful to have a tool to view and edit structured binary data, such as program memory structures (task memory, core file), file system structures, etc.
     1Implement a tool to view and edit structured binary data, such as program memory structures (task memory, core file), file system structures, etc.
    22
    3 I would suggest to create a library that would:
    4  * define data structures (and API to manipulate them) to describe types (basic types, arrays, structs, unions)
    5  * enumerate fields
    6  * compute field offset (address)
    7  * read and write fields
    8  * convert between binary and textual representation
    9  * find targets of links
     3 Details::
     4  The implementation should primarily consist of a versatile library that would provide: 
     5   * An API to dynamically (at run-time) define and manipulate data structures (data schemas) comprising of typical basic and compound data types (integers, arrays, structs, unions, pointers)
     6   * An API to enumerate the members of such data structures
     7   * An API to compute field offsets (addresses)
     8   * An API to read and write values of the members and traverse complex data structures using pointers (with custom pointer resolution routines)
     9   * A parser which would provide a way how to define the data structures (data schemas) in a textual representation (XML-based description, C-like type declaration or a DSL)
     10   * A generator which would output the data structure definition in the textual representation which the library can parse again.
     11   * Support for custom memory back-ends using code plugins (file, task memory [using udebug], block device)
    1012
    11 The type definitions would be defined by plugins:
    12  * plugin for reading DWARF data
    13  * plugin for reading textual definitions
    14  * plugin for specific set of types (e.g. ext2)
     13  The implementation should also contain a readily available definitions for common data structures (either as code plugins or in the form of textural representation), e.g.:
     14   * ubiquitous data structures (doubly-linked link lists, hash tables, etc.)
     15   * ELF file format (with DWARF data)
     16   * FAT file system structures
     17   * ext2 file system structures
    1518
    16 as well as definitions of other link types than pointer (e.g. block address).
     19  An interactive or command-based browser/editor should be provided on top of this library and data structure definitions. The library can be also integrated into other applications, such as the debugger.
    1720
    18 Also plugins for different memory back-ends can be provided (possibly by the user):
    19  * (core) file
    20  * task memory (via Udebug)
    21  * block device
     21 What Gains and Benefits will this bring?::
     22  Easier debugging of file system drivers, easier debugging of running tasks and their live data, easier analysis of core dumps. The open design of the library/editor should make it great also for other future uses (analysis of application data files, etc.).
    2223
    23 On top of this library we can provide tools such as an interactive or command-based browser/editor. It could be also used as part of a debugger and possibly for other debugging purposes.
     24  As the implementation of the library and to a major extend also the implementation of the end-user interactive editor can be done in standard-compliant C with little to no HelenOS-specific code, it can be also usable in other operating systems.
     25
     26 Difficulty::
     27  Medium
     28
     29 Required skills::
     30  A successful applicant will have good skills of programming in the C language and experience with designing reusable and extendable libraries with decent internal structure and public API. For the end-user interactive editor the ability to learn and use HelenOS-specific console manipulation routines is also expected.
     31
     32 Documentation::
     33
     34  * Compact Type Format (compact kernel debugging information used by MDB for Solaris)
     35
     36 Possible mentors::
     37    HelenOS Core Team, Martin Decky