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


(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 


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