Re: Function pointer stab information - where are the argument types?

[Daniel Jacobowitz <drow at mvista dot com>]

On Sat, Jan 04, 2003 at 12:09:45AM -0000, Dave Hooper wrote:
> I'm new to the gcc lists, so I apologise deeply if this has already been
> discussed to death.  I did perform a search of the archives and found
> nothing relevant.  And I apologise in advance for an over-long post.
> 
> I'm using gcc 3.2 20020927 (prerelease) on cygwin.  If I compile the
> following *simple* code with gcc with -gstabs (or -gstabs+) and -save-temps
> (for the .s)
> 
> int (*f1)(void);
> int (*f2)(int, char*);
> int main(void)
> {
>     return(-1);
> }
> 
> then the stabs in the .s show both f1 and f2 as having the same type, when
> they're hardly interchangeable
> 
>  .stabs  "f1:G(1,1)=*(1,2)=f(0,1)",32,0,0,0
>  .stabs  "f2:G(1,3)=*(1,4)=f(0,1)",32,0,0,0
> 
> Furthermore running "whatis f1" and "whatis f2" in gdb give identical
> results (Running gdb -v gives GNU gdb 2002-12-19-cvs (cygwin-special))
> 
>  (gdb) whatis f1
>  type = int (*)(void)
>  (gdb) whatis f2
>  type = int (*)(void)
> 
> 
> >From similar discussion on gdb development lists (circa Feb 2002) it appears
> gdb supports the 'g' stab to convey function argument type information.  In
> fact to verify this I took a hex editor to the executable resulting from the
> compilation above and edited the stab table for f2 from:
> f2:G(1,3)=*(1,4)=f(0,1)<NUL>
> to
> f2:G(1,3)=*(1,4)=f(0,1)(0,1)(0,1)#<NUL>
> just to see what would happen.  gdb reported:
> 
>  (gdb) whatis f2
>  type = int (*)(int, int)
> 
> 
> My question is, why does gcc not generate this stab information itself?  Is
> the 'g' stab type unsupported/unofficial/deprecated (my guess would be no as
> the gdb discussion originated around February)?  Is gcc just slow at

It's a Sun extension to the stabs format.  Of course, the whole stabs
format is a series of Sun extensions to a Sun format, so it's not clear
how much that means.  But I'm pretty sure the 'g' type is newer than
the base of the current stabs generator.

No one is terribly motivated to work on the generated stabs, either.

> catching up on this (with other, more important developments, this would not
> surprise me, and I will gladly attempt the patch myself)?  Or has a patch
> already been made to a more recent codebase than 3.2?
> 
> The reason I need such information is because I'm using gcc as a
> preprocessing step to determine the number and type of arguments of
> functions defined in external source/header files.  As a specific example, I
> need to programatically obtain the type of a function declared in a header
> file (but not defined).  I could of course write my own C++ parser but I
> figured I could make use of gcc natively by compiling dummy code such as the
> following and then just parsing the stabs:

> Thanks in advance if anyone knows an easier way to achieve what I need;
> otherwise what is the status of the 'g' stab and whether or not it should be
> added to dbxout.c ?

Sure, there's a much easier way: use DWARF-2.  I believe this works on
Cygwin now.  It's structured, and much more precise than the stabs;
tremendously easier to parse, too.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer