Two possible function stabs patches

Two possible function stabs patches

[Geoffrey Keating]

OK, so I have not one, but two patches!

The first one is less interesting.  It uses the language's name for the 
function, unless it's a C++ function, in which case it uses the 
(mangled) assembler name.  It'll give a stab like

         .stabs  "__ZN3bar3fooEv:F(0,1)",36,0,2,__ZN3bar3fooEv
or
         .stabs  "foo:F(0,1)",36,0,2,foo.11

The second one uses the 'printable name' for the function.  That is, 
for C it's just the name, and for C++ it's the demangled version of its 
name.  I am not at all sure it'll work, because it gives stabs like:

         .stabs  "int bar::foo():F(0,1)",36,0,2,__ZN3bar3fooEv

which I suspect can't be parsed.

Could someone help me test these?  It needs a machine that can use 
stabs and on which the GDB testsuite doesn't give too many false 
positives.

-- 
Geoff Keating <geoffk@apple.com>

Re: Two possible function stabs patches

[Geoffrey Keating]

On Wednesday, July 30, 2003, at 07:17  AM, Andrew Cagney wrote:

>> Oops!  Forgot to attach the actual patches.  Fixed below.
>> OK, so I have not one, but two patches!
>
> Um, these appear to come with a little history (Solaris perhaphs?).  
> Can you provide a bit of a background?  You'll likely also want to add 
> something to the GNU stabs document found in the GDB distro.

So far as I know, this is a bug that has been in GCC since 1992, and 
before that I don't know what the history is.  I looked at the stabs 
document in GDB; this patch makes GCC more compliant with it.

>> The first one is less interesting.  It uses the language's name for 
>> the function, unless it's a C++ function, in which case it uses the 
>> (mangled) assembler name.  It'll give a stab like
>>         .stabs  "__ZN3bar3fooEv:F(0,1)",36,0,2,__ZN3bar3fooEv
>> or
>>         .stabs  "foo:F(0,1)",36,0,2,foo.11
>> The second one uses the 'printable name' for the function.  That is, 
>> for C it's just the name, and for C++ it's the demangled version of 
>> its name.  I am not at all sure it'll work, because it gives stabs 
>> like:
>>         .stabs  "int bar::foo():F(0,1)",36,0,2,__ZN3bar3fooEv
>> which I suspect can't be parsed.
>> Could someone help me test these?  It needs a machine that can use 
>> stabs and on which the GDB testsuite doesn't give too many false 
>> positives.
>
> I'd strongly encourage you to install GNU/Linux and *BSD on a couple 
> local old/slow Mac boxes.  It will make testing a lot easier.

All my old/slow boxen get used for GCC regression testing...

-- 
Geoff Keating <geoffk@apple.com>

Re: Two possible function stabs patches

[Michael Elizabeth Chastain]

Geoff K suggests:

  int main(void)
  {
     static int foo(void)  { return 1; }
     return foo() == 1 ? 0 : 1;
  }

  break foo

Hmmmm.  I'll bet that this would be the first code in the test
suite with nested functions.  It is a supported gcc feature,
so that would be good to test.  We'll probably generate a bunch
of new KFAILs with this.

I'll put this on my TODO list, but I have to postpone this until
after the gdb 6.0 release.  It's a question of tuits.

Michael C

Re: Two possible function stabs patches

[Geoffrey Keating]

[This might be a duplicate, in which case please ignore it...]

On Tuesday, July 29, 2003, at 10:47  PM, Michael Elizabeth Chastain 
wrote:

> First patch:
>
>   no regressions in gdb test suite output
>   no improvements, either
>   native i686-pc-linux-gnu
>   red hat linux 8
>   binutils 2.14
>   -gstabs+

Excellent!  Except, that probably means that the gdb testsuite could do 
with some more testcases.  Is there a GDB person who could add the one 
I mentioned earlier,

int main(void)
{
   static int foo(void)  { return 1; }
   return foo() == 1 ? 0 : 1;
}

break foo

?

> Second patch:
>
>   still running ...
>
> My test bed deletes the build directories for gcc after it builds
> each gcc, so I got to do a little extra build-from-scratch
> this evening.  Argh.
>
Thank you for all your work!