This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Printing out type tree using objdump...
- From: Tarmo Pikaro <tapika at yahoo dot com>
- To: Ian Lance Taylor <ian at airs dot com>
- Cc: binutils at sourceware dot org
- Date: Tue, 4 Oct 2005 13:51:35 -0700 (PDT)
- Subject: Printing out type tree using objdump...
> Yes, but I wrote it in 1997. I would have to look
> at it closely to
> remember how it is supposed to work, and I don't
> have the time.
Ok...
Luckily I have 'ddd' to play with... See attached
picture... That's intresting into how deep it can go?
:)
> No, to be accepted as a patch it has to be in
> Texinfo format.
Ok , do you know any good texinfo editor ?
Ok, but now I will write down my proposal, if approved
- then can be moved into the documentation...
Can you comment the text below, and also if someone
else will comment it will be good as well...
-----------------------------------------------
-----------------------------------------------
-----------------------------------------------
4 Type tree in objdump
objdump will provide for perl functionality to print
out the type tree.
?objdump --print_c_type_tree_for_perl? will print out
type tree. Type tree is the next step from perl module
called ?pstruct? ? pstruct allowed to parse stabs
debugging information and generate appropriate
functions for filling out necessary C structures. Type
tree assumes that no code will be generated and
developer can perform necessary structure generation
using type tree. Additional perl module,
encode_decode.pm will be supplied with tree walking
support.
In order to avoid unnecessary complexity not
everything what is supported C will be supported by
type tree printing. Here is the list of everything
what will be and what will not be supported:
Basic data types ? uint8, uint16, uint32 and their
aliases int8, int16, int32 will be supported.
(Includes aliases of basic types as well - unsigned
char, unsigned short, unsigned long and so on?)
Any other data type will not be supported (Including
any pointer, function pointers and so on).
Structure definition without typedef ? not supported.
Structure definition with typedef ? supported.
Union definition with typedef ? supported.
Type aliasing using typedef ? supported. (E.g. typedef
uint32 Address;)
Enumerations - supported.
Array of basic types and arrays of any structure ?
supported.
To get type tree to perl developer will have to use
following command line:
my $type_tree=eval(`objdump
?print_c_type_tree_for_perl <object name or executable
file>`);
The executable file or object file must contain
debugging information, so for example can be compiled
using ?gcc ?g <source> -o executable? command line.
3.2 Type tree
Each type definition or structure name is unique;
there cannot be two structures with the same name in
application. (In plain C, C++ allows namespaces usage)
For developer name of field in structure is like a
handle to structure variable ? it?s simple to use.
That?s why structure name will be acting like a key in
type tree.
typedef struct
{
uint8 test1;
}MyStruct;
Will produce following tree:
?MyStruct? =>
{
?type? => ?structure?,
?elements? =>
[
?test1? =>
[
?type? => ?uint8?
],
]
};
Lower case letters will be used to simplify writing.
3.4 Structure size
Structure size must be known in order to be able to
fully automate encode/decode. Structure size can be
defined at compile time if we talking about plain C,
and at run-time if structure is dynamically sizable or
alignment is changed. We will define structure size at
run-time, not at compile time in order to simplify the
handling of structures.
3.5 Aliasing
Quite often developers needs to alias some data type
in order to separate it somehow from a generic one,
for example like this:
typedef int size_t;
Even through some people don't like that kind of
aliasing, I think that it should be possible to create
such aliases. If you look at terminology chapter (3.3)
you will see that aliasing is not a good one, however
terminology must be clarified at some point of time,
and it is an iterative process and takes a lot time,
we meanwhile should be able to adapt to upcoming
changes. Aliasing is also called language richness,
but I see that it is a serious drawback to clarity in
communication and understanding.
Aliases or type definitions will look like this in
type tree:
typedef uint32 Address;
Type tree:
?Address? =>
{
?type? => ?alias?,
?aliased_from_type? => ?uint32?
}
----------------------------------------------
I will need to add more details on how enums, unions
will look like, also arrays. But this is a good
starting point.
--
Have a nice day!
Tarmo.
__________________________________
Yahoo! Mail - PC Magazine Editors' Choice 2005
http://mail.yahoo.com