This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

image/pjpeg


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]