Re: STABS API..

[Justin McCann <jneilm at yahoo dot com>]

--- Guy Shepherd <gshepherd7@yahoo.com> wrote:
> Hi Justin
> 
> I came across your post on the binutils mailing
> list. I am looking for the same sort of thing. 
> I didn't see any responses to your post however.
> Did you have any luck in finding one?
> 
> Thanks,
> 
> Guy
> 

Guy-- 

Hope you don't mind me posting to the list. I guess my
first question wasn't put well enough. Maybe someone
will read this and have mercy enough to point out
where I'm wrong or missing something....

Did I find a fairly easy-to-use interface to the STABS
debugging information? Well, no and yes; not exactly.
I did some more reading of the source code, and did
figure out a few things about how the binutils work. I
think I might have distilled it down partly to what I
need. I wouldn't call it necessarily easy-to-use, but
maybe it's just what you get due to the complexity of
the debug info.

This might be *MUCH* more info than you wanted, but
here's what I've figured out so far....

You can run 
   objdump [-g | --debugging] <filename>
and get all of the type information dumped out in a
C-like syntax. 

<tangent>This works on gnu-built executables built on
Solaris, but doesn't appear to work on RH Linux
executables by default. I vaguely recall reading
something about a linker or compiler option to enable
carrying debug symbols into the executable (the
inverse of gcc -s), but haven't found any other
references to it.</tangent>

Basically 'objdump -g' it shows what the types
themselves look like as C source code, with comments
for the sizes and offsets for each of the fields
inside of structs/unions. For each type, it just gives
the first level of information that is in the STABS
string for that type. It doesn't show you directly
what all of the subtypes would look like; you'd have
to do the struct-building recursively. Here's an
example of what 'objdump -g' outputs:

struct mytype { /* size 128 id 2 */
  struct _pthread_mutex /* id 3 */ lockall; /* bitsize
0x00000000000000c0, bitpos 0x0000000000000000 */
  unsigned int i; /* bitsize 0x0000000000000020,
bitpos 0x00000000000000c0 */
  struct _pthread_rwlock /* id 4 */ locki; /* bitsize
0x0000000000000200, bitpos 0x0000000000000100 */
  char *foo; /* bitsize 0x0000000000000020, bitpos
0x0000000000000300 */
  struct _pthread_mutex /* id 3 */ lockfoo; /* bitsize
0x00000000000000c0, bitpos 0x0000000000000340 */
};

So, to figure out exactly where in "lockfoo" an offset
refers to (like my original email), you'd have to look
in the 'struct _pthread_mutex' type information, too.

It also will output the addresses of functions, the
variables and addresses on the function's stack, and
the line numbers and addresses of the real lines of
source code. For example:

void *thread_function (void *arg /* 0x0000000000000044
*/)
{ /* 0x0000000000010bac */
  /* file /fs/junkfood/jmccann/proj/DynEval2/test11.c
line 61 addr 0x0000000000010bac */
  { /* 0x0000000000010bb4 */
    mytype_t *mt /* 0x00000000ffffffec */;
    /* file
/fs/junkfood/jmccann/proj/DynEval2/test11.c line 62
addr 0x0000000000010bb4 */
    /* file
/fs/junkfood/jmccann/proj/DynEval2/test11.c line 64
addr 0x0000000000010bbc */
...
}

... Okay, so all of that is to say, that objdump DOES
parse out the STABS information in a semi-usable form.
You'll probably have to build your own API from what
objdump has, unless you can find (or someone can
recommend) something else.

Some files you might find relevant are:
binutils-2.11.94/binutils/objdump.c
binutils-2.11.94/binutils/rddbg.c
binutils-2.11.94/binutils/stabs.c
binutils-2.11.94/binutils/debug.c
binutils-2.11.94/binutils/debug.h
binutils-2.11.94/binutils/prdbg.c

binutils/objdump.c has command-line parsing (which I
threw out for my purposes) and then reads in the
appropriate file and creates 'abfd', which is passed
around almost everywhere else.

binutils/rddbg.c actually reads the debugging info out
of the file(s) referred to in 'abfd', and then calls
other functions (i.e. parse_stab) to parse it and
build the data structures

binutils/stabs.c has functions for parsing the stabs
info (e.g. parse_stab)

binutils/debug.c has 'struct debug_type', which
contains all of the info that gets pulled out of the
symbol table, and functions for actually creating and
populating the appropriate data structures. I think
this is one of the most important ones to look at,
since it tells what the data structures look like, and
the reason below....

binutils/prdbg.c actually goes through the
debug-symbols data structures and prints them out (to
create the output I showed above). To do anything
useful, I think you'd want to model this sort of
behavior, only not just building strings and printing
out everything in the functions you write. It actually
creates a 'struct debug_write_fns' with a big list of
function pointers to handle each type of debugging
symbol, and then passes that to 'debug.c:debug_write',
which loops over all of the debug symbols and calls
the appropriate function pointer as it hits that type
of symbol. 

I *think* the essential files you need to link with
are:

objdump_CFILES = objdump.c budemang.c prdbg.c rddbg.c
debug.c stabs.c ieee.c rdcoff.c bucomm.c filemode.c
bfdstabs.c

So, you:
1. Read in the file and create abfd (ex. in objdump.c)
2. Get the symbols out of the file (from debug.c)

Then:
A. Create your own functions to handle each symbol
type
B. Call write_debug (or a function that does something
similar) with your function pointers to do whatever it
is you want. 

Or:
Write your own code that combines A & B. I'm sure I'm
skipping a lot of steps, and am overcomplicating it.
But that's what I've come up with so far.

Let me know how it works out,
    Justin



		
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html