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

[Joel Brobecker <brobecker@gnat.com>]

[-- 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" \