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


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


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