Re: binutils, bfd library, debug.h/c files and so on...

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> Attaching a zip with debug.h/c, initial version with
> my modifications, I haven't fully implemented the
> feature which I need, but these are initial changes to
> debug.h/c.

It is most helpful if you generate a diff, using
    diff -pu OLDFILE NEWFILE
and then attach the diff using MIME type text/plain or text/x-patch.
Thanks!

In order to be accepted, your patches must follow the GNU formatting
conventions, described here:
    http://gnu.org/prep/standards/
or just look at the formatting used in the rest of the file.

The approach looks reasonable to me.

> 1. Do I need to inspect all the changes with you ?
> Probably yes, and it's fine by me, but I need to know
> your requirements for source code quality.

If you want to get the patches accepted, then they need to be approved
by one of the binutils maintainers (I am one, but I am not very
active).  The code has to be bug-free, has to compile with -Wall
-Werror, and has to be formatted correctly.

> 2. Thinking in more details, I've realized why do we
> need a separate typedump.exe, when we could integrate
> my function into objdump ?  And that would be my next
> proposal - add into objdump additional flag:
> --print_type_tree_for_perl ?
> I will implement a separate .c file and you will add
> into objdump additional function call to that .c file.

That approach is only going to be OK if you can very clearly specify
what the output should look like.  It's not going to be OK if the
output is only for your program.

Ian

Re: binutils, bfd library, debug.h/c files and so on...

[Tarmo Pikaro]

Hi !

Little bit confused about typedef's...
Original code:
    #include <sys/types.h>

    typedef u_int8_t    byte;
    typedef u_int16_t   word;
    typedef u_int32_t   dword;

objdump --debugging output:
    typedef unsigned char byte;
    typedef short unsigned int word;
    typedef unsigned int dword;

When iterating through
n->name = n->u.type->u.knamed->name->name = 
debug_get_type_name(handle,n->u.type)
= byte | word | dword

debug_get_type_name(handle,n->u.type->u.knamed->type)
= u_int8_t | u_int16_t | u_int32_t

--debugging is geeting at the roots of typedef ?
How does chain looks like in typedef case ? (where to
locate correct names?)

DEBUG_OBJECT_TYPE -> DEBUG_KIND_NAMED ->
DEBUG_KIND_INT ?

> If you want to get the patches accepted, then they
> need to be approved
> by one of the binutils maintainers (I am one, but I
> am not very
> active).

Ok, I propose that we start from you.  :)


> That approach is only going to be OK if you can very
> clearly specify
> what the output should look like.  It's not going to
> be OK if the
> output is only for your program.

I will. Is there some web server where I could place
the documentation ? Or can I put a link to external
documentation ? Or should it be included in binutils ?



--
    Have a nice day!
        Tarmo.


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> How does chain looks like in typedef case ? (where to
> locate correct names?)
> 
> DEBUG_OBJECT_TYPE -> DEBUG_KIND_NAMED ->
> DEBUG_KIND_INT ?

Good question, but offhand I do not know.

> > That approach is only going to be OK if you can very
> > clearly specify
> > what the output should look like.  It's not going to
> > be OK if the
> > output is only for your program.
> 
> I will. Is there some web server where I could place
> the documentation ? Or can I put a link to external
> documentation ? Or should it be included in binutils ?

If it gets accepted, I think we would want to document it in the
binutils manual.

Ian

Re: binutils, bfd library, debug.h/c files and so on...

[Tarmo Pikaro]

> > How does chain looks like in typedef case ? (where
> to
> > locate correct names?)
> > 
> > DEBUG_OBJECT_TYPE -> DEBUG_KIND_NAMED ->
> > DEBUG_KIND_INT ?
> 
> Good question, but offhand I do not know.

 ??? :) ???
Who does then ? Haven't you the one who wrote this
piece of code originally ?

> If it gets accepted, I think we would want to
> document it in the
> binutils manual.

Allright. 
1. With who I should inspect it ?
2. In what format I will supply my documentation? Is
$M word acceptable ?


--
    Have a nice day!
        Tarmo.


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> > > How does chain looks like in typedef case ? (where
> > to
> > > locate correct names?)
> > > 
> > > DEBUG_OBJECT_TYPE -> DEBUG_KIND_NAMED ->
> > > DEBUG_KIND_INT ?
> > 
> > Good question, but offhand I do not know.
> 
>  ??? :) ???
> Who does then ? Haven't you the one who wrote this
> piece of code originally ?

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.

> > If it gets accepted, I think we would want to
> > document it in the
> > binutils manual.
> 
> Allright. 
> 1. With who I should inspect it ?

Any binutils maintainer.

> 2. In what format I will supply my documentation? Is
> $M word acceptable ?

No, to be accepted as a patch it has to be in Texinfo format.

Ian

Printing out type tree using objdump...

[Tarmo Pikaro]

[-- Attachment #1: Type: text/plain, Size: 4546 bytes --]

> 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

[-- Attachment #2: 1187571893-typedef.jpg --]
[-- Type: image/pjpeg, Size: 118597 bytes --]

Re: Printing out type tree using objdump...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> > No, to be accepted as a patch it has to be in
> > Texinfo format.
> Ok , do you know any good texinfo editor ?

Well, emacs, I suppose.  Texinfo is a fairly simple text based
formatting language.

> 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.

Unfortunately, I have a hard time understanding this.

Is pstruct a standard perl module?  If not, does this dump information
actually have anything to do with Perl?

> ‘MyStruct’ =>
> {
>    ‘type’ => ‘structure’,
> 
> 	‘elements’ =>
> 	[
> 		‘test1’ => 
> 		[ 
> 				‘type’ => ‘uint8’
> 		],
> 	]
> };

Can we specify this more formally?  Or is this some sort of Perl
syntax?  (It's been many years since I've used Perl).

Ian

Re: Printing out type tree using objdump...

[Tarmo Pikaro]

> > 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.
> 
> Unfortunately, I have a hard time understanding
> this.
Ok, may be I need to provide some background support?
Tell me which terms here you don't understand, I will
try to clarify the issue.


> Is pstruct a standard perl module?
Yes, but I had some problems with using it, my best
guess is that gcc's stabs debug information has
changed or stabs parser does not work correctly.


>  If not, does
> this dump information
> actually have anything to do with Perl?
It doesn't.... Ok, I have to include reasoning for
using perl, here you go:

-------------------------------------------
3.1	Programming language
Currently I see several alternatives – perl, C#, C++,
C. IÂ’ve decided to start from perl, because it does
not needs to be compiled and its architecture allows
much more simpler tree structures handling than any
other language.
Perl will be used as a primary language, for secondary
will be chosen plain C, because of its portability.
Also without the need to recompile the whole
application the testing and iteration sequence goes
much faster.
-------------------------------------------

But basically after type tree is loaded in perl it can
be written back to C. I just don't want to play with
xmalloc and other allocation libraries, I want to have
a toy language in use...


> > ‘MyStruct’ =>
> > {
> >    ‘type’ => ‘structure’,
> > 
> > 	‘elements’ =>
> > 	[
> > 		‘test1’ => 
> > 		[ 
> > 				‘type’ => ‘uint8’
> > 		],
> > 	]
> > };
> 
> Can we specify this more formally?  Or is this some
> sort of Perl
> syntax?  (It's been many years since I've used
> Perl).

Ok you need to have a good knowledge of perl, 
see for more details perldsc, perlreftut, perlref,
perllol tutorials.

for example from here:
http://webmaster.iu.edu/perl56/pod/perldsc.html

Shortly ...  [1 , 2 , 3] is an array of items '1', '2'
and '3'. { 'a' => 1, 'b' => 2} is a hash of a=1, b=2.
(~aka structure)


--
    Have a nice day!
        Tarmo.


	
		
______________________________________________________ 
Yahoo! for Good 
Donate to the Hurricane Katrina relief effort. 
http://store.yahoo.com/redcross-donate3/ 

Re: Printing out type tree using objdump...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> > > 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.
> > 
> > Unfortunately, I have a hard time understanding
> > this.
> Ok, may be I need to provide some background support?
> Tell me which terms here you don't understand, I will
> try to clarify the issue.

I think I understand every term, I just don't understand what you are
actually saying.

> > > ‘MyStruct’ =>
> > > {
> > >    ‘type’ => ‘structure’,
> > > 
> > > 	‘elements’ =>
> > > 	[
> > > 		‘test1’ => 
> > > 		[ 
> > > 				‘type’ => ‘uint8’
> > > 		],
> > > 	]
> > > };
> > 
> > Can we specify this more formally?  Or is this some
> > sort of Perl
> > syntax?  (It's been many years since I've used
> > Perl).
> 
> Ok you need to have a good knowledge of perl, 
> see for more details perldsc, perlreftut, perlref,
> perllol tutorials.
> 
> for example from here:
> http://webmaster.iu.edu/perl56/pod/perldsc.html
> 
> Shortly ...  [1 , 2 , 3] is an array of items '1', '2'
> and '3'. { 'a' => 1, 'b' => 2} is a hash of a=1, b=2.
> (~aka structure)

I don't need or want to know Perl syntax.  What I need to know is that
the above is actual Perl code.  It sounds like it is.

So from the binutils perspective, what we are really talking about
here is an option to dump the debugging information in a format which
can be easily read by Perl.  Right?  The documentation should focus on
specifying precisely and concisely what the output format is.  The
goal should be to make it possible for anybody to write a parser for
that output format.  Otherwise it does not belong in the generic
binutils.

Ian

Re: Printing out type tree using objdump...

[Tarmo Pikaro]

> > Ok you need to have a good knowledge of perl, 
> > see for more details perldsc, perlreftut, perlref,
> > perllol tutorials.
> > 
> I don't need or want to know Perl syntax.  What I
> need to know is that
> the above is actual Perl code.  It sounds like it
> is.

Ok, I have currently two targets in my mind - the
first one is to simply being able to encode/decode
complex C structures using perl code for it. (Analogue
to pstruct functionality) Type information is
generated instead of functions (like in pstruct) is
because I want to be able to print structures contents
in plain text as well. The second target is the
document I've sent you, but I don't want yet pulich it
on internet until I have some results from target one.
This document I have already sent you and you can
share it internally within binutils, but please don't
publish it yet in internet, please. (It is nice to
have great goal, but it would be nice to be able to
achieve it as well.... :)  )

> So from the binutils perspective, what we are really
> talking about
> here is an option to dump the debugging information
> in a format which
> can be easily read by Perl.  Right?  The
> documentation should focus on
> specifying precisely and concisely what the output
> format is.  The
> goal should be to make it possible for anybody to
> write a parser for
> that output format.  Otherwise it does not belong in
> the generic
> binutils.

I will write needed specifications, what is built on
top of this will be up to developer to decide, I by
myself can provide a public example on being able to
modify C structures from perl.

--
    Have a nice day!
        Tarmo.


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> About printing out structures - debug_write does not
> seems to be feasible for my needs, I will probably
> recosider by tampering into debug.c directly...
> My idea was that I will make debugex.c which will
> #include "debug.c" and I will add needed functions
> there.
> 
> By doing so I will not tamper your code. (my proposal)

Please don't #include "debug.c", at least if you want to get the patch
into the binutils.  Just go ahead and edit debug.c.

Ian

Re: binutils, bfd library, debug.h/c files and so on...

[Tarmo Pikaro]

Hi !

Continuing digging deeper...
After closer consideration I've decided that I don't
need to use debug.h/c from C++, and if I'll do, I will
wrap debug* into my own .c/h and from there into
c++....  No need to change your code.

Checked out objdump --debugging, pretty much what I
need, already extracted parts from objdump. Coded
typedump.c :) (Ok, so we can end-up having additional
utility in binutils, so what? :) )

About printing out structures - debug_write does not
seems to be feasible for my needs, I will probably
recosider by tampering into debug.c directly...
My idea was that I will make debugex.c which will
#include "debug.c" and I will add needed functions
there.

By doing so I will not tamper your code. (my proposal)

libdwarf developer did not yet reply to me, so I think
I will stick to binutils. :)

About what will be printed out...
I will try to form suitable for perl output and use
DataDumper module to reserse engeneere printed
lines...
so from perl code would look like this:
my $print=`typedump.exe myexe.exe`;
$type_tree=eval($print);

Here is a little bit more of design issues:
---------------------------------------------
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.3 Terminology

Structure (C, C++)Alias: Sequence, Complex type
(XML)Alias: Element (RelaxNG)

(People, this is ridiculous! Just by renaming the
type, you wonÂ’t get anything newer.)
Refers to a structure, an array of elements.

Comments are welcomed...




--
    Have a nice day!
        Tarmo.


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> Meanwhile - Ian, can you check out what modifications
> I must make to get access to one/two dimentional
> arrays?

Given an object of kind DEBUG_KIND_ARRAY, it's the fields of struct
debug_array_type in debug.c.  You'll need some sort of accessor
functions for them.  They'll return things like
    type->u.karray->element_type

All arrays are represented as one dimensional arrays.  A two
dimensional array will be represented as an array whose element_type
is another array.

Ian

Re: binutils, bfd library, debug.h/c files and so on...

[Tarmo Pikaro]

> Of course, if the most convenient way for you to get
> the debugging
> information is BFD, then rddbg.c will mostly work
> fine as is.

Hmm... Guessing I will include one file and will get
100 more at the same price. :)
I've already came accross the question of handling the
dependencies somehow... Wrote a perl script to handle
these issues...

Application source codes were grouped logically by
simple naming notation: (aaa, bbb in this case)
$MY_MODULES{'bbb'}=
{
    'INCLUDE_SOURCES' =>
    [

        {  
            'HELPSTRING' => 'bbbs source code',
            'FILE' => 'bbb.c'
        }
    ]
};

$MY_MODULES{'aaa'}=
{
    'INCLUDE_SOURCES' =>
    [

        {  
            'HELPSTRING' => 'aaas source code',
            'FILE' => 'aaa.c'
        }
    ],
    
    DEPENDENCIES => [
        'base_services',
        'bbb'
    ]
};

and had a merge_trees function which would check
whether given source codes are already included or
not.

And printing out the source tree would go like that:
#-------------------------------------------
# Prints out the tree
#-------------------------------------------
sub print_tree
{
    my $tree=shift;
    require Data::Dumper;
    print Data::Dumper::Dumper($tree);
} #print_tree


Anyway... 
I will try to compile all files as they are without
any modifications and include all object files needed
(size of executable is not my primary concern)

Meanwhile - Ian, can you check out what modifications
I must make to get access to one/two dimentional
arrays?



--
    Have a nice day!
        Tarmo.


		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

"H. J. Lu" <hjl@lucon.org> writes:

> On Wed, Sep 28, 2005 at 12:36:27PM -0700, Ian Lance Taylor wrote:
> > Tarmo Pikaro <tapika@yahoo.com> writes:
> > 
> > > Got libelf, dwarfdump and libdwarf, managed to compile
> > > without any problem under windows/ cygwin, but
> > > dwarfdump does not show any information about
> > > executables compiled with gcc for windows (.exe).
> > > Guessing it is not elf file format anymore, but PE
> > > (portable executable) ?!
> > 
> > That's true, Windows doesn't use ELF.  I guess I'm not sure offhand
> > which debugging format gcc uses by default on Windows.
> > 
> 
> I modified objdump to dump DWARF info. It works on ELF and Mach-O.
> I guess it should work on other formats. See
> 
> http://sourceware.org/ml/binutils/2005-09/msg00179.html
> 
> Some patches need update. But the general idea is the same.

That is useful, but it's not what the original poster wants, though.
He specifically wants the debug.h interface, as printed by objdump
--debugging (though not for DWARF).

Ian

Re: binutils, bfd library, debug.h/c files and so on...

[H. J. Lu]

On Wed, Sep 28, 2005 at 12:36:27PM -0700, Ian Lance Taylor wrote:
> Tarmo Pikaro <tapika@yahoo.com> writes:
> 
> > Got libelf, dwarfdump and libdwarf, managed to compile
> > without any problem under windows/ cygwin, but
> > dwarfdump does not show any information about
> > executables compiled with gcc for windows (.exe).
> > Guessing it is not elf file format anymore, but PE
> > (portable executable) ?!
> 
> That's true, Windows doesn't use ELF.  I guess I'm not sure offhand
> which debugging format gcc uses by default on Windows.
> 

I modified objdump to dump DWARF info. It works on ELF and Mach-O.
I guess it should work on other formats. See

http://sourceware.org/ml/binutils/2005-09/msg00179.html

Some patches need update. But the general idea is the same.


H.J.

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> Got libelf, dwarfdump and libdwarf, managed to compile
> without any problem under windows/ cygwin, but
> dwarfdump does not show any information about
> executables compiled with gcc for windows (.exe).
> Guessing it is not elf file format anymore, but PE
> (portable executable) ?!

That's true, Windows doesn't use ELF.  I guess I'm not sure offhand
which debugging format gcc uses by default on Windows.

> Meanwhile lets continue this discussion on porting
> debug.h/c to newer environment.
> Ian already told me that we wishes to continue
> discussion over this mailing list, but its seems to be
> unreasonable to bring all the debugging information
> here. I would propose by myself to form two-three
> person mail list and continue discussion in private,
> after we get first version working, we will switch to
> public mail list again.

The binutils mailing list really is the right place to discuss
binutils development.

> > > > They are not currently in any library.  If
> > somebody wants to put them
> > > > into a library, I wouldn't object.  I don't
> > think it would be too
> > > > hard.
> 
> I can do it, but this library needs to be maintained
> as well. And this maintenance is most important issue
> from all, if we would not need to maintain anything,
> then I would use C++ reflection and old port. But it's
> not working, guessing something changed?!

Well, that kind of thing happens in the binutils too.  I mean, getting
the patches into the binutils won't help unless somebody maintains
them.  And nobody is really maintaining debug.h/debug.c in the sense
that if they break nobody jumps in to fix them.  It takes more than
just having the code around; somebody has to be interested in it.

> debug.h needs to be included from C++, and following
> lines compiler does not like:
>   typedef struct debug_type *debug_type;
> proposal to name structure names with suffix, like
> this:
>   typedef struct debug_type_str *debug_type;
> (Replacement to many places...)

Sounds fine.

> rddbg.c seems to be dependent from following files:
> 
> #include "bfd.h"
> #include "bucomm.h"
> #include "libiberty.h"
> #include "debug.h"
> #include "budbg.h"
> 
> Do I include them all, or should I somehow filter away
> non-needed helper files ?

rddbg.c is designed to read debugging information from a BFD.  When
you don't have a BFD, you probably shouldn't use rddbg.c.  You should
write different code which does the same thing with the debugging
information which you have.

Of course, if the most convenient way for you to get the debugging
information is BFD, then rddbg.c will mostly work fine as is.

Ian

Re: binutils, bfd library, debug.h/c files and so on...

[Tarmo Pikaro]

Hi !

Got libelf, dwarfdump and libdwarf, managed to compile
without any problem under windows/ cygwin, but
dwarfdump does not show any information about
executables compiled with gcc for windows (.exe).
Guessing it is not elf file format anymore, but PE
(portable executable) ?!

Unix utilities tends to be cross compatible with
everything, but the fact remains that they are not
working in any platform.  :)

Anyway, I will try to contact libdwarf developer and
ask what he thinks on subject.

Meanwhile lets continue this discussion on porting
debug.h/c to newer environment.
Ian already told me that we wishes to continue
discussion over this mailing list, but its seems to be
unreasonable to bring all the debugging information
here. I would propose by myself to form two-three
person mail list and continue discussion in private,
after we get first version working, we will switch to
public mail list again.

> > > They are not currently in any library.  If
> somebody wants to put them
> > > into a library, I wouldn't object.  I don't
> think it would be too
> > > hard.

I can do it, but this library needs to be maintained
as well. And this maintenance is most important issue
from all, if we would not need to maintain anything,
then I would use C++ reflection and old port. But it's
not working, guessing something changed?!

Ok, let's make it so that I will form a separate
project (from scratch) and try to pick up needed
source codes and tell you more about my requirements
to your source code.

debug.h needs to be included from C++, and following
lines compiler does not like:
  typedef struct debug_type *debug_type;
proposal to name structure names with suffix, like
this:
  typedef struct debug_type_str *debug_type;
(Replacement to many places...)

rddbg.c seems to be dependent from following files:

#include "bfd.h"
#include "bucomm.h"
#include "libiberty.h"
#include "debug.h"
#include "budbg.h"

Do I include them all, or should I somehow filter away
non-needed helper files ?

(I see that we have to modify a lot of code in order
to make it work as a separate library, may be we
should stick to libbfd.a, or is there needed
functionality included ????)


--- Ian Lance Taylor <ian@airs.com> wrote:

> Daniel Jacobowitz <drow@false.org> writes:
> 
> > On Tue, Sep 27, 2005 at 02:53:12PM -0700, Ian
> Lance Taylor wrote:
> > > > How will I get all functionality that I need -
> do I
> > > > (1) include directly all needed files (2) get
> a
> > > > precompiled library from binutils and link it
> against
> > > > my application.
> > > 
> > > They are not currently in any library.  If
> somebody wants to put them
> > > into a library, I wouldn't object.  I don't
> think it would be too
> > > hard.
> > 
> > There's definitely some benefit for a
> format-agnostic debug info
> > library - but what the formats can represent
> varies drastically, so it
> > seems like a substantial project.
> 
> In principle all the basic stuff is there in
> debug.h.  It's true that
> it can't currently represent everything that DWARF
> can represent, but
> it can represent pretty much everything that anybody
> other than a
> debugger or a stack unwinder would care about.
> 
> > Reading this thread I wonder if we
> > should just recommend libdwarf instead for
> DWARF-2.
> 
> Definitely something to consider.  I haven't looked
> at libdwarf
> myself.
> 
> Ian
> 



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com

Re: binutils, bfd library, debug.h/c files and so on...

[Daniel Jacobowitz]

On Tue, Sep 27, 2005 at 03:03:23PM -0700, Ian Lance Taylor wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > On Tue, Sep 27, 2005 at 02:53:12PM -0700, Ian Lance Taylor wrote:
> > > > How will I get all functionality that I need - do I
> > > > (1) include directly all needed files (2) get a
> > > > precompiled library from binutils and link it against
> > > > my application.
> > > 
> > > They are not currently in any library.  If somebody wants to put them
> > > into a library, I wouldn't object.  I don't think it would be too
> > > hard.
> > 
> > There's definitely some benefit for a format-agnostic debug info
> > library - but what the formats can represent varies drastically, so it
> > seems like a substantial project.
> 
> In principle all the basic stuff is there in debug.h.  It's true that
> it can't currently represent everything that DWARF can represent, but
> it can represent pretty much everything that anybody other than a
> debugger or a stack unwinder would care about.

Ah, binutils/debug.h; I thought we were talking about a bit of bfd.
It's much more complete than I'd expected.  I guess how useful it is
will depend on what you want to do with it :-)

> > Reading this thread I wonder if we
> > should just recommend libdwarf instead for DWARF-2.
> 
> Definitely something to consider.  I haven't looked at libdwarf
> myself.

It's an extremely powerful tool, but of course dwarf-specific.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

Daniel Jacobowitz <drow@false.org> writes:

> On Tue, Sep 27, 2005 at 02:53:12PM -0700, Ian Lance Taylor wrote:
> > > How will I get all functionality that I need - do I
> > > (1) include directly all needed files (2) get a
> > > precompiled library from binutils and link it against
> > > my application.
> > 
> > They are not currently in any library.  If somebody wants to put them
> > into a library, I wouldn't object.  I don't think it would be too
> > hard.
> 
> There's definitely some benefit for a format-agnostic debug info
> library - but what the formats can represent varies drastically, so it
> seems like a substantial project.

In principle all the basic stuff is there in debug.h.  It's true that
it can't currently represent everything that DWARF can represent, but
it can represent pretty much everything that anybody other than a
debugger or a stack unwinder would care about.

> Reading this thread I wonder if we
> should just recommend libdwarf instead for DWARF-2.

Definitely something to consider.  I haven't looked at libdwarf
myself.

Ian

Re: binutils, bfd library, debug.h/c files and so on...

[Daniel Jacobowitz]

On Tue, Sep 27, 2005 at 02:53:12PM -0700, Ian Lance Taylor wrote:
> > How will I get all functionality that I need - do I
> > (1) include directly all needed files (2) get a
> > precompiled library from binutils and link it against
> > my application.
> 
> They are not currently in any library.  If somebody wants to put them
> into a library, I wouldn't object.  I don't think it would be too
> hard.

There's definitely some benefit for a format-agnostic debug info
library - but what the formats can represent varies drastically, so it
seems like a substantial project. Reading this thread I wonder if we
should just recommend libdwarf instead for DWARF-2.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> > debug.h/debug.c is the generic interface.  There are
> > specific
> > implementations for stabs and for IEEE debug info.
> 
> So it's not that simple. Can you provide me some
> background information about stabs and IEEE debug info

Well, stabs is documented here:
    http://sourceware.org/gdb/current/onlinedocs/stabs_toc.html

I don't know if there is online documentation for the IEEE debug
format.  I used to have hardcopy documentation for it, but I think I
left it at a former job.

> ? But normally if you compile in linux (e.g. redhat)
> and in windows (cygwin), which debug information is
> used there ? May be we should stick to the one format
> ?

On GNU/Linux you normally get DWARF, and I assume the same is true for
cygwin.

> > > Ok - first of all all symbols that I need are
> > defined
> > > in debug.c, we will probably need to move them
> > into .h
> > > file. (struct debug_*, enum debug_*).
> > 
> > My original idea was to keep the structs defined in
> > debug.c and use
> > accessor functions.  A number of accessor functions
> > are already
> > defined.  No doubt they are insufficient, but I'd
> > think the first
> > approach would be to add accessor functions.
> 
> Can you give me some background information about
> accessor functions ? (document or example would be
> fine)

They are declared and commented in debug.h.  There isn't any other
documentation.

> How will I get all functionality that I need - do I
> (1) include directly all needed files (2) get a
> precompiled library from binutils and link it against
> my application.

They are not currently in any library.  If somebody wants to put them
into a library, I wouldn't object.  I don't think it would be too
hard.

> > I don't think there is currently a way to ask for
> > all the types.  
> 
> debug_type*
> debug_get_all_classes (handle)
>      PTR handle;

Yes, this looks like the right kind of thing.

> > You
> > can ask for a particular struct using
> > debug_find_tagged_type().  Given
> > a debug_type for a struct, you can get the fields
> > via
> > debug_get_fields().  Given a field, you can use
> > debug_get_field_type(), debug_get_field_name(),
> > debug_get_field_bitpos() and
> > debug_get_field_bitsize().
> 
> Sounds good. Should I open the file before calling
> these functions ?

Those functions assume that you already have a handle for the
debugging information, as returned by, e.g., read_debugging_info in
rddbg.c.  That is, you have to read and parse all the debug
information before you can start calling functions like
debug_find_tagged_type().

> > > Support for single and two dimentional structures
> > is
> > > also needed.
> > 
> > I'm not sure what this means.
> arrays. sorry.
> e.g. uint8 array[34];

Arrays are represented but I don't think there are currently any
accessor functions for them.

By the way, the only current users of the debug information are the
convertors and the printer.  The printer is what you get from objdump
--debugging.  The convertors are used by objcopy to translate
debugging information from one format to another (and are the reason I
wrote this code in the first place).  Both the convertors and the
printer work by using struct debug_write_fns, defined in debug.h, and
providing definitions for all the callbacks.  The debug_write function
walks through all the debugging information and calls the callbacks
defined in struct debug_write_fns.  This approach is not appropriate
for inspection of the debug information.

> > > the type information needs to be readed out from
> > file,
> > > so we will need file operations as well as object
> > > reading capabilities (?, At least in older version
> > of
> > > RTTI there are included following files: rddbg.c
> > > debug.c bucomm.c stabs.c filemode.c prdbg.c ieee.c
> > 
> > OK.  For stabs the relevant code is in stabs.c.  You
> > can just call
> > parse_stab with each stab string.  That is currently
> > done by the code
> > in rddbg.c.  As far as I know stabs.c doesn't care
> > where the stabs
> > strings come from.
> Ok...  Can you provide me with some background
> information on stabs ?

See the document cited above.

> rddbg perfoms reading of debug information from
> execuable file or object ?

Yes.

Ian

Re: binutils, bfd library, debug.h/c files and so on...

[Tarmo Pikaro]

(Sorry for confusion, reposting this to binutils
mailing list as well)

--- Ian Lance Taylor <ian@airs.com> wrote:
> debug.h/debug.c is the generic interface.  There are
> specific
> implementations for stabs and for IEEE debug info.

So it's not that simple. Can you provide me some
background information about stabs and IEEE debug info
? But normally if you compile in linux (e.g. redhat)
and in windows (cygwin), which debug information is
used there ? May be we should stick to the one format
?

> > Ok - first of all all symbols that I need are
> defined
> > in debug.c, we will probably need to move them
> into .h
> > file. (struct debug_*, enum debug_*).
> 
> My original idea was to keep the structs defined in
> debug.c and use
> accessor functions.  A number of accessor functions
> are already
> defined.  No doubt they are insufficient, but I'd
> think the first
> approach would be to add accessor functions.

Can you give me some background information about
accessor functions ? (document or example would be
fine)

How will I get all functionality that I need - do I
(1) include directly all needed files (2) get a
precompiled library from binutils and link it against
my application.


> > I will try to list here all that I need, can you
> > recommend me which structures I should be looking
> for:
> > I need type information on all C's structures,
> field *
> > N, their names, types and offsets within a struct.
> > (Which debug_* struct corresponds to it?)
> 
> I don't think there is currently a way to ask for
> all the types.  

debug_type*
debug_get_all_classes (handle)
     PTR handle;
{
  struct debug_handle *info = (struct debug_handle *)
handle;
  struct debug_unit *u;
  struct debug_type_compare_list *list;
  debug_type *classes;
  int size = 0;
  list = NULL;
  /* We search the globals of all the compilation
units.  I don't know
     if this is correct or not.  It would be easy to
change.  */

  for (u = info->units; u != NULL; u = u->next)
    {
      struct debug_file *f;

      for (f = u->files; f != NULL; f = f->next)
	{
	  struct debug_name *n;

	  if (f->globals != NULL)
	    {
	      for (n = f->globals->list; n != NULL; n =
n->next)
		{
                  if (n->kind == DEBUG_OBJECT_TAG) {
                    debug_type real =
debug_get_real_type(handle, n->u.tag, NULL);
                    if (real->kind == DEBUG_KIND_CLASS
||
                        real->kind ==
DEBUG_KIND_STRUCT) {
                      struct debug_type_compare_list
*item;
                      item = (struct
debug_type_compare_list *) xmalloc(sizeof *item);
                      memset (item, 0, sizeof *item);
                      item->next = list;
                      item->t1 = n->u.tag;
                      size++;
                      list = item;
                    }
                  }
                }
            }
        }
    }
  classes = (debug_type*) xmalloc((size+1) * sizeof
*classes);
  classes[size--] = NULL;
  while (list != NULL) {
    struct debug_type_compare_list *item;
    classes[size--] = list->t1;
    list->t1 = NULL;
    item = list;
    list = list->next;
    item->next = NULL;
    free(item);
  }
      
  return classes;
}

Copy pasted from Reflect RTTI, I've already noticed
that it is not included in debug.c. :)

> You
> can ask for a particular struct using
> debug_find_tagged_type().  Given
> a debug_type for a struct, you can get the fields
> via
> debug_get_fields().  Given a field, you can use
> debug_get_field_type(), debug_get_field_name(),
> debug_get_field_bitpos() and
> debug_get_field_bitsize().

Sounds good. Should I open the file before calling
these functions ?

> > Support for single and two dimentional structures
> is
> > also needed.
> 
> I'm not sure what this means.
arrays. sorry.
e.g. uint8 array[34];

> > the type information needs to be readed out from
> file,
> > so we will need file operations as well as object
> > reading capabilities (?, At least in older version
> of
> > RTTI there are included following files: rddbg.c
> > debug.c bucomm.c stabs.c filemode.c prdbg.c ieee.c
> 
> OK.  For stabs the relevant code is in stabs.c.  You
> can just call
> parse_stab with each stab string.  That is currently
> done by the code
> in rddbg.c.  As far as I know stabs.c doesn't care
> where the stabs
> strings come from.
Ok...  Can you provide me with some background
information on stabs ?

rddbg perfoms reading of debug information from
execuable file or object ?



	
		
______________________________________________________ 
Yahoo! for Good 
Donate to the Hurricane Katrina relief effort. 
http://store.yahoo.com/redcross-donate3/ 

Re: binutils, bfd library, debug.h/c files and so on...

[Tarmo Pikaro]

(Sorry for confusion, reposting this to binutils
mailing list as well)

> OK, makes sense.  Note that most toolchains these
> days use DWARF2 or
> DWARF3 (except for Apple, which continues to use
> stabs).  Nobody has
> written a debug.h interface for DWARF yet.

Ok, I think we can start from the best alternative
(Guessing you're suggesting DWARF2 or 3 ?) and make
appropriate modifications to source code.

Ok, but do we have an agreement that such
modifications are needed ?

I have digged deeper into binutils code and to my
understanding there currently does not exists any
simple to use API, which would provide reading out 
debugging information. (Correct me if I'm wrong)

What purpose does debug.h/c serves ?  Is it for DWARF
reading ? Which code is responsible for DWARF2/3
reading ?

Anyway, it's a details, perhaps we should clarify how
"read out debug information" API will look like.
I can provide my skills in making this happen, but you
will need at least assist me, and also I want you to
take over the maintanance of the code as well.

Ok - first of all all symbols that I need are defined
in debug.c, we will probably need to move them into .h
file. (struct debug_*, enum debug_*).

I see that porting to something new will not going to
be an easy task, so I would propose to create a new
.h/.lib files for "read out debug information" API.

Of course we could still stick to already existing
lib, but to my understanding it will be better to
start from scratch so all dependencies will be well
known and new system will not cause any damage to the
old one.

type_information.h / lib would be my proposal.

But also maintaining two systems is not a good
solution - I think that for now we can directly move
all we need from debug.* file, and later on split
debug.c into several source codes.

I will try to list here all that I need, can you
recommend me which structures I should be looking for:
I need type information on all C's structures, field *
N, their names, types and offsets within a struct.
(Which debug_* struct corresponds to it?)
Support for single and two dimentional structures is
also needed.

the type information needs to be readed out from file,
so we will need file operations as well as object
reading capabilities (?, At least in older version of
RTTI there are included following files: rddbg.c
debug.c bucomm.c stabs.c filemode.c prdbg.c ieee.c

- We will probably needs some funtions from some of
thoose files.)

I've actually managed to compile already rddbg.c
debug.c bucomm.c, but after found out the list of
errors in stabs.c I had an idea that it would be
better to start from scratch with the expert helping
me out. So that's why I'm not sending you my
modifications.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> I want to revive this project and make it correctly.
> What I want to achieve is:
> - Ripping off completely debug information from files
> compiled by gcc.
> 
> All the changes I will make to binutils source codes I
> want you to pick up and approve into newer versions of
> binutils.
> 
> Please don't give me high level bullshit about .NET
> reflection, java...  I have studied them in forehead
> and pretty much I'm informed about their behavior.
> 
> About the changes - so far I've found some problems
> with putting debug.h to work from c++ and I know that
> my predecessor have solved them already, also some
> function prototypes are missing and so on.

OK, makes sense.  Note that most toolchains these days use DWARF2 or
DWARF3 (except for Apple, which continues to use stabs).  Nobody has
written a debug.h interface for DWARF yet.

> Ok, but getting more into details is probably not
> intrested to anyone - I have explained here some
> basics.

This mailing list is all about the details, at least with regard to
how debug.h, etc., should be changed.

Ian

Re: binutils, bfd library, debug.h/c files and so on...

[Tarmo Pikaro]

Hi !

During my search through the internet I wanted to
build up type information tree to be used in my own
application. I must say that internet is crowded with
many many different approaches to this one.

At this point I want to use perl (If I will have to
tell why, then it's longer story), and I've came
accross perl script called 'pstruct', however it did
not work correctly for me.

After this I've started digging deeper and find out
that stabs file which pstruct is parsing is actually
debug information and there are plenty other different
file format to save debug information.

Digging even deeper I've came accross
http://www.garret.ru/~knizhnik/cppreflection/docs/reflect.html
Reflection package for C++.
And find out that given package uses some source codes
from binutils (aout64.h, bucomm.c, bucomm.h, budbg.h,
debug.c, debug.h, demangle.h, filemode.c, filenames.h
, ieee.c, ieee.h, prdbg.c, rddbg.c, stab.h, stabs.c)

but from some older version.
Since developer were not in touch with you all the
change he made to binutils source codes are done by
himself and lost for binutils.

I want to revive this project and make it correctly.
What I want to achieve is:
- Ripping off completely debug information from files
compiled by gcc.

All the changes I will make to binutils source codes I
want you to pick up and approve into newer versions of
binutils.

Please don't give me high level bullshit about .NET
reflection, java...  I have studied them in forehead
and pretty much I'm informed about their behavior.

About the changes - so far I've found some problems
with putting debug.h to work from c++ and I know that
my predecessor have solved them already, also some
function prototypes are missing and so on.

Ok, but getting more into details is probably not
intrested to anyone - I have explained here some
basics.

--- Ian Lance Taylor <ian@airs.com> wrote:

> Tarmo Pikaro <tapika@yahoo.com> writes:
> 
> > I want to get access to file debug information and
> > binutils contains such information. However it is
> not
> > in easily accessable form. Who is maintaining
> > debug.h/c - can I discuss with him on further
> > development ?
> 
> I don't think anybody is maintaining those files in
> the sense that you
> mean.  I wrote them, and I don't think anybody else
> has done any
> substantial work on them.  But I wrote them back in
> 1997, and I
> haven't done any substantial work on them since then
> either.
> 
> I'd be happy to talk about them, but in general I'd
> rather to keep the
> conversation on the mailing list.
> 
> Ian
> 



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: binutils, bfd library, debug.h/c files and so on...

[Ian Lance Taylor]

Tarmo Pikaro <tapika@yahoo.com> writes:

> I want to get access to file debug information and
> binutils contains such information. However it is not
> in easily accessable form. Who is maintaining
> debug.h/c - can I discuss with him on further
> development ?

I don't think anybody is maintaining those files in the sense that you
mean.  I wrote them, and I don't think anybody else has done any
substantial work on them.  But I wrote them back in 1997, and I
haven't done any substantial work on them since then either.

I'd be happy to talk about them, but in general I'd rather to keep the
conversation on the mailing list.

Ian

binutils, bfd library, debug.h/c files and so on...

[Tarmo Pikaro]

Hi !

I want to get access to file debug information and
binutils contains such information. However it is not
in easily accessable form. Who is maintaining
debug.h/c - can I discuss with him on further
development ?

-- Tarmo.


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com