[RFA/testsuite/ada] Refine expected output of start command

[RFA/testsuite/ada] Refine expected output of start command

[Joel Brobecker]

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

Hello,

While refreshing my memory on how the start command is implemented,
I found that it would currently only work with stabs. This concerns
Ada only, as this is the only language that I remember of that has
a main procedure name that's different from "main".

Anyway, so I checked out the results of gdb.ada/null_record.exp which
I thought were an all PASS. And it is. It's just that the regexp
used to match the expected output is not stringent enough. Basically,
since the current mechanism doesn't work with dwarf2, GDB sets the
temporary breakpoint inside "main", rather than "null_record".
So we get this output:

        (gdb) start
        Breakpoint 1 at 0x8049762: file b~null_record.adb, line 102.
        Starting program: /[...]/null_record 
        main ([...]) at b~null_record.adb:102
        102           Ensure_Reference : System.Address := Ada_Main_Program_Name'Address;

Procedure main is defined in what we call the "binder file", which
is a file generated by the binder, a tool used just prior to linking.
The name of that file follows a convention: "b~" followed by the
name of the file containing the main program name. In this case,
it's "b~null_record.adb".

That's too close to what we put in our regexp for the expected output,
unfortunately. The gdb_test used to be:

        gdb_test "start" \
                 "Breakpoint \[0-9\]+ at .*null_record.adb.*" \
                 "start"

So the test passes although we didn't land at the expected location.

The attached patch changes what we check. Instead of checking
that we inserted a breakpoint inside null_record.adb, I thought
it was better to verify that we landed inside the right function
(null_record) in null_record.adb. This is because inserting the
breakpoint there does not guaranty that we will actually land
there. And that makes it unecessary to refine the check against
the source filename where we landed, since there will be no
null_record() function in the binder file.

2004-10-20  Joel Brobecker  <brobecker@gnat.com>

        * gdb.ada/null_record.exp: Check where we stopped after
        sending the start command, instead of where the associated
        temporary breakpoint was inserted.

This causes the "start" test above to FAIL for now. But the fix for
this should be available soon.

OK to commit? (I verified that this PASSes again once I apply my fix)

Thanks,
-- 
Joel

[-- Attachment #2: null_record.exp.diff --]
[-- Type: text/plain, Size: 565 bytes --]

Index: null_record.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.ada/null_record.exp,v
retrieving revision 1.3
diff -u -p -r1.3 null_record.exp
--- null_record.exp	8 Jun 2004 05:05:33 -0000	1.3
+++ null_record.exp	21 Oct 2004 02:48:40 -0000
@@ -35,7 +35,7 @@ gdb_reinitialize_dir $srcdir/$subdir
 gdb_load ${binfile}
 
 gdb_test "start" \
-         "Breakpoint \[0-9\]+ at .*null_record.adb.*" \
+         "null_record \\(\\) at .*null_record.adb.*" \
          "start"
 
 gdb_test "ptype empty" \

Re: [RFA/testsuite/ada] Refine expected output of start command

[Daniel Jacobowitz]

On Wed, Oct 20, 2004 at 07:49:15PM -0700, Joel Brobecker wrote:
> Hello,
> 
> While refreshing my memory on how the start command is implemented,
> I found that it would currently only work with stabs. This concerns
> Ada only, as this is the only language that I remember of that has
> a main procedure name that's different from "main".
> 
> Anyway, so I checked out the results of gdb.ada/null_record.exp which
> I thought were an all PASS. And it is. It's just that the regexp
> used to match the expected output is not stringent enough. Basically,
> since the current mechanism doesn't work with dwarf2, GDB sets the
> temporary breakpoint inside "main", rather than "null_record".
> So we get this output:

Actually, it's been failing for me for a maybe related reason:

(gdb) start
Breakpoint 1 at 0x8048ad0: file b~null_record.adb, line 99.
Starting program: /opt/src/binutils/x86-as/gdb/testsuite/gdb.ada/null_record 
main (argc=1, argv=(system.address) 0xbffff524, envp=(system.address) 0xbffff52c) at b~null_record.adb:99
99            Ensure_Reference : System.Address :=
Ada_Main_Program_Name'Address;
(gdb) PASS: gdb.ada/null_record.exp: start
ptype empty
type = function return int
(gdb) FAIL: gdb.ada/null_record.exp: ptype on null record

> 2004-10-20  Joel Brobecker  <brobecker@gnat.com>
> 
>         * gdb.ada/null_record.exp: Check where we stopped after
>         sending the start command, instead of where the associated
>         temporary breakpoint was inserted.
> 
> This causes the "start" test above to FAIL for now. But the fix for
> this should be available soon.
> 
> OK to commit? (I verified that this PASSes again once I apply my fix)

This is OK.

-- 
Daniel Jacobowitz

Re: [RFA/testsuite/ada] Refine expected output of start command

[Joel Brobecker]

> Actually, it's been failing for me for a maybe related reason:
> 
> (gdb) start
> Breakpoint 1 at 0x8048ad0: file b~null_record.adb, line 99.
> Starting program: /opt/src/binutils/x86-as/gdb/testsuite/gdb.ada/null_record 
> main (argc=1, argv=(system.address) 0xbffff524, envp=(system.address) 0xbffff52c) at b~null_record.adb:99
> 99            Ensure_Reference : System.Address :=
> Ada_Main_Program_Name'Address;
> (gdb) PASS: gdb.ada/null_record.exp: start
> ptype empty
> type = function return int
> (gdb) FAIL: gdb.ada/null_record.exp: ptype on null record

Hmmm, no I don't think it's the same reason. And the test passes for
me.

Could you do an experiment for me, and tell me what the language
is after you load the executable? It should be auto,ada.  Same after
you've done the start.

Of maybe you could send me separately your executable, so I can take
a look...

> > 2004-10-20  Joel Brobecker  <brobecker@gnat.com>
> > 
> >         * gdb.ada/null_record.exp: Check where we stopped after
> >         sending the start command, instead of where the associated
> >         temporary breakpoint was inserted.
> > 
> > This causes the "start" test above to FAIL for now. But the fix for
> > this should be available soon.
> > 
> > OK to commit? (I verified that this PASSes again once I apply my fix)
> 
> This is OK.

Thanks, committed.

-- 
Joel

Re: [RFA/testsuite/ada] Refine expected output of start command

[Michael Chastain]

From gdb-patches-return-36411-mec.gnu=mindspring.com@sources.redhat.com  Wed Oct 20 23:43:05 2004
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Sender: gdb-patches-owner@sources.redhat.com
Date: Wed, 20 Oct 2004 19:49:15 -0700
From: Joel Brobecker <brobecker@gnat.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA/testsuite/ada] Refine expected output of start command

Approved.

I don't know Ada so I'm at the mercy of people who do.
Your explanation is persuasive though.

It's okay if improving a test changes the result from a bad PASS
to a good FAIL.

===

2004-10-20  Joel Brobecker  <brobecker@gnat.com>

        * gdb.ada/null_record.exp: Check where we stopped after
        sending the start command, instead of where the associated
        temporary breakpoint was inserted.