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]

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


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


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