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

[Ian Lance Taylor <ian at airs dot com>]

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