[RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

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

Hello,

Hmmm, dejagnu is still quite obscure for me, so I don't think I'll come
up with the perfect universal solution to add support for Ada testcases
right from the start... So instead I'll proceed tiny steps at a time...

First step: Being able to build most Ada programs. Let's first restrict
ourselves to Ada-only programs. Such a program necessarily have its
main program written in Ada. With GNAT, this main program must be
located in its own file. And to build the entire application, one
usually does:

        % gnatmake -g <filename>

where <filename> is the name of the file containing the main subprogram.
The extension may be omitted. Dependencies are automatically handled
by gnatmake.

In this patch, I suggest we defined a new function gdb_compile_ada in
lib/gdb.exp which will allow us to build Ada programs using the command
above.

I have a question: I am uncertain as to how cross targets are handled.
Suppose we built a powerpc-elf debugger. How does the testsuite know
which compiler to use. Does it have so machinery that will translate
gcc into powerpc-elf-gcc by default? Would the same apply to gnatmake
in gdb_compile_ada via target_compile?

In the medium term, we will want to improve gdb_compile_ada to allow
the testsuite to use different runtimes (we have sjlj exceptions vs
ZCX exceptions, longcall vs no-longcall, shared vs static) or different
options (we want to use -mieee on tru64 for instance). I believe this
should be easily done via the options field.

As for multilanguage examples, I'll leave that for later as well, but
I don't think that would be too big a problem.

2004-02-24  J. Brobecker  <brobecker@gnat.com>

        * lib/gdb.exp (gdb_compile_ada): New function.

Tested on x86-linux. I used that function to build a simple program,
and I was able to debug it.

Comments? Or, one can always dream, ok to apply?

The next steps will involve creating the gdb.ada directory, update
the configure scripts, and add our first example (the null record one).

Thanks,
-- 
Joel

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

Index: lib/gdb.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
retrieving revision 1.49
diff -u -p -r1.49 gdb.exp
--- lib/gdb.exp	23 Feb 2004 19:27:46 -0000	1.49
+++ lib/gdb.exp	24 Feb 2004 19:50:10 -0000
@@ -1361,6 +1361,17 @@ proc gdb_compile_objc {source dest type 
     }
 }
 
+proc gdb_compile_ada {source dest type options} {
+    
+    lappend options "compiler=gnatmake"
+
+    set result [target_compile $source $dest $type $options]
+    if { $result != "" } {
+        verbose "target_compile failed: $result" 2
+        return "gdb_compile_ada failed: $result"
+    }
+}
+
 proc send_gdb { string } {
     global suppress_flag;
     if { $suppress_flag } {

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

Hello,

> 2004-02-24  J. Brobecker  <brobecker@gnat.com>
> 
>         * lib/gdb.exp (gdb_compile_ada): New function.

Please ignore this patch. It has a few problems:

  - Object files are placed in the testsuite directory. I'd rather
    see them being placed in gdb.ada.

  - There is a problem with gdb_compile_ada. In Ada target_compile
    always returns some output, so the current implementation thinks
    the compilation fails, while it is not necessarily the case.
    I changed the test to check for the dest file, rather than
    analyzing the output.

Will send an updated patch when I have a complete ada testcase working.


> Index: lib/gdb.exp
> ===================================================================
> RCS file: /cvs/src/src/gdb/testsuite/lib/gdb.exp,v
> retrieving revision 1.49
> diff -u -p -r1.49 gdb.exp
> --- lib/gdb.exp	23 Feb 2004 19:27:46 -0000	1.49
> +++ lib/gdb.exp	24 Feb 2004 19:50:10 -0000
> @@ -1361,6 +1361,17 @@ proc gdb_compile_objc {source dest type 
>      }
>  }
>  
> +proc gdb_compile_ada {source dest type options} {
> +    
> +    lappend options "compiler=gnatmake"
> +
> +    set result [target_compile $source $dest $type $options]
> +    if { $result != "" } {
> +        verbose "target_compile failed: $result" 2
> +        return "gdb_compile_ada failed: $result"
> +    }
> +}
> +
>  proc send_gdb { string } {
>      global suppress_flag;
>      if { $suppress_flag } {


-- 
Joel

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

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

Here is a new patch that takes into account the remarks I made
earlier: 

  - There is a problem with gdb_compile_ada. In Ada target_compile
    always returns some output, so the current implementation thinks
    the compilation fails, while it is not necessarily the case.
    I changed the test to check for the dest file, rather than
    analyzing the output.

    Done.

  - Object files are placed in the testsuite directory. I'd rather
    see them being placed in gdb.ada.

    I managed to do this, but I a not completely sure that it's such
    a good idea after all. See patch below. On the one hand, the object
    files et al are placed in gdb.ada rather than gdb/testsuite, but
    on the other hand this has a slight impact in the debug info generated
    by the compiler, since the source file name is no longer absolute.
    So this change is not completely transparent for the debugger...
    What do you think?

I am also copying my previous message, in case you would have some
comments about it as well.

On Tue, Feb 24, 2004 at 11:56:15AM -0800, Joel Brobecker wrote:
> Hmmm, dejagnu is still quite obscure for me, so I don't think I'll come
> up with the perfect universal solution to add support for Ada testcases
> right from the start... So instead I'll proceed tiny steps at a time...
> 
> First step: Being able to build most Ada programs. Let's first restrict
> ourselves to Ada-only programs. Such a program necessarily have its
> main program written in Ada. With GNAT, this main program must be
> located in its own file. And to build the entire application, one
> usually does:
> 
>         % gnatmake -g <filename>
> 
> where <filename> is the name of the file containing the main subprogram.
> The extension may be omitted. Dependencies are automatically handled
> by gnatmake.
> 
> In this patch, I suggest we defined a new function gdb_compile_ada in
> lib/gdb.exp which will allow us to build Ada programs using the command
> above.
> 
> I have a question: I am uncertain as to how cross targets are handled.
> Suppose we built a powerpc-elf debugger. How does the testsuite know
> which compiler to use. Does it have so machinery that will translate
> gcc into powerpc-elf-gcc by default? Would the same apply to gnatmake
> in gdb_compile_ada via target_compile?
> 
> In the medium term, we will want to improve gdb_compile_ada to allow
> the testsuite to use different runtimes (we have sjlj exceptions vs
> ZCX exceptions, longcall vs no-longcall, shared vs static) or different
> options (we want to use -mieee on tru64 for instance). I believe this
> should be easily done via the options field.
> 
> As for multilanguage examples, I'll leave that for later as well, but
> I don't think that would be too big a problem.

2004-02-24  J. Brobecker  <brobecker@gnat.com>

        * lib/gdb.exp (gdb_compile_ada): New function.

Tested on x86-linux using the following little dejagnu testcase:

        if $tracelevel then {
            strace $tracelevel
        }
        
        load_lib "ada.exp"
        
        set testfile "null_record"
        set srcfile ${testfile}.adb
        set binfile ${objdir}/${subdir}/${testfile}
        
        if {[gdb_compile_ada "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable [list debug ]] != "" } {
          return -1
        }
        
        gdb_exit
        gdb_start
        gdb_reinitialize_dir $srcdir/$subdir
        gdb_load ${binfile}
        
        gdb_begin "" "Breakpoint \[0-9\]+ at .*null_record.adb.*"
        
        gdb_test "ptype empty" \
                 "type = record null; end record" \
                 "ptype on null record"

The result are:

        # of expected passes            2

Yay! :-)

Comments? Ok to apply?

-- 
Joel

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

Index: gdb.exp
===================================================================
RCS file: /nile.c/cvs/Dev/gdb/gdb-6.0/gdb/testsuite/lib/gdb.exp,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 gdb.exp
--- gdb.exp	5 Oct 2003 10:40:20 -0000	1.1.1.1
+++ gdb.exp	24 Feb 2004 23:07:52 -0000
@@ -1323,6 +1323,39 @@ proc gdb_compile_objc {source dest type 
     }
 }
 
+#
+# Compile some Ada code.
+#
+proc gdb_compile_ada {source dest type options} {
+
+    lappend options "compiler=gnatmake"
+
+    # gnatmake leaves some compilation artifacts behind, such as
+    # .o or .ali files. We want them to be placed besides the dest
+    # file to avoid having them pollute the current directory. So
+    # we temporarily change directory while compiling.
+    #
+    # As a consequence, we need to adjust the source path to become
+    # absolute. Otherwise, the compiler will not find it. We assume
+    # that the dest path is already absolute.
+
+    regsub "^.*/" "$source" "" source_basename
+    set source_dirname [absolute [file dirname $source]]
+    set source $source_dirname/$source_basename
+
+    set cwd [pwd]
+    cd [file dirname $dest]
+    set result [target_compile $source $dest $type $options]
+    cd $cwd
+
+    # Make sure that the dest file has been created.  Otherwise,
+    # the build has failed.
+    if ![file exists $dest] {
+        verbose "Ada compilation failed: $result"
+        return "Ada compilation failed."
+    }
+}
+
 proc send_gdb { string } {
     global suppress_flag;
     if { $suppress_flag } {

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

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

Continuing my fascinating monologous with myself :)

>   - Object files are placed in the testsuite directory. I'd rather
>     see them being placed in gdb.ada.
> 
>     I managed to do this, but I a not completely sure that it's such
>     a good idea after all. See patch below. On the one hand, the object
>     files et al are placed in gdb.ada rather than gdb/testsuite, but
>     on the other hand this has a slight impact in the debug info generated
>     by the compiler, since the source file name is no longer absolute.
>     So this change is not completely transparent for the debugger...
>     What do you think?

Actually, I just noticed that the few tests that do generate object
files and other compilation artifacts actually leave them in the
testsuite directory, not inside the gdb.* directories.

So I would be tempted to discard the idea above of making sure that
all these artifacts be placed in the gdb.ada directory for all Ada
testcases. Hence the attached patch. One note, however: contrary to
C where temporary .o files are automatically deleted, gnatmake leaves
behind. This is to allow incremental builds, similar what make does.
This will cause a much higher number of object files to be created
in the testsuite directory. I hope this is fine? Otherwise, we'll
can use the previous approach, but I believe it should be done
consistently across all languages.

2004-02-24  J. Brobecker  <brobecker@gnat.com>

        * lib/gdb.exp (gdb_compile_ada): New function.

Tested on x86-linux.

-- 
Joel

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

Index: lib/gdb.exp
===================================================================
RCS file: /nile.c/cvs/Dev/gdb/gdb-6.0/gdb/testsuite/lib/gdb.exp,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 gdb.exp
--- lib/gdb.exp	5 Oct 2003 10:40:20 -0000	1.1.1.1
+++ lib/gdb.exp	25 Feb 2004 18:24:38 -0000
@@ -1323,6 +1323,23 @@ proc gdb_compile_objc {source dest type 
     }
 }
 
+#
+# Compile some Ada code.
+#
+proc gdb_compile_ada {source dest type options} {
+
+    lappend options "compiler=gnatmake"
+
+    set result [target_compile $source $dest $type $options]
+
+    # Make sure that the dest file has been created.  Otherwise,
+    # the build has failed.
+    if ![file exists $dest] {
+        verbose "Ada compilation failed: $result"
+        return "Ada compilation failed."
+    }
+}
+
 proc send_gdb { string } {
     global suppress_flag;
     if { $suppress_flag } {

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Daniel Jacobowitz]

On Wed, Feb 25, 2004 at 10:32:11AM -0800, Joel Brobecker wrote:
> Continuing my fascinating monologous with myself :)
> 
> >   - Object files are placed in the testsuite directory. I'd rather
> >     see them being placed in gdb.ada.
> > 
> >     I managed to do this, but I a not completely sure that it's such
> >     a good idea after all. See patch below. On the one hand, the object
> >     files et al are placed in gdb.ada rather than gdb/testsuite, but
> >     on the other hand this has a slight impact in the debug info generated
> >     by the compiler, since the source file name is no longer absolute.
> >     So this change is not completely transparent for the debugger...
> >     What do you think?
> 
> Actually, I just noticed that the few tests that do generate object
> files and other compilation artifacts actually leave them in the
> testsuite directory, not inside the gdb.* directories.
> 
> So I would be tempted to discard the idea above of making sure that
> all these artifacts be placed in the gdb.ada directory for all Ada
> testcases. Hence the attached patch. One note, however: contrary to
> C where temporary .o files are automatically deleted, gnatmake leaves
> behind. This is to allow incremental builds, similar what make does.
> This will cause a much higher number of object files to be created
> in the testsuite directory. I hope this is fine? Otherwise, we'll
> can use the previous approach, but I believe it should be done
> consistently across all languages.

I would prefer to have them placed in the subdirectory.  Can't you
specify an output directory for gnatmake?  It seems like a terrible
limitation.

Also, gdb_compile_ada may want to remove the incremental files in this
case, since the testsuite will not use them.
> +    lappend options "compiler=gnatmake"

See find_gcc in dejagnu's libgloss.exp.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

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

On Wed, Feb 25, 2004 at 03:17:49PM -0500, Daniel Jacobowitz wrote:
> On Wed, Feb 25, 2004 at 10:32:11AM -0800, Joel Brobecker wrote:
> > Continuing my fascinating monologous with myself :)
> > 
> > >   - Object files are placed in the testsuite directory. I'd rather
> > >     see them being placed in gdb.ada.
> > > 
> > >     I managed to do this, but I a not completely sure that it's such
> > >     a good idea after all. See patch below. On the one hand, the object
> > >     files et al are placed in gdb.ada rather than gdb/testsuite, but
> > >     on the other hand this has a slight impact in the debug info generated
> > >     by the compiler, since the source file name is no longer absolute.
> > >     So this change is not completely transparent for the debugger...
> > >     What do you think?
> > 
> > Actually, I just noticed that the few tests that do generate object
> > files and other compilation artifacts actually leave them in the
> > testsuite directory, not inside the gdb.* directories.
> > 
> > So I would be tempted to discard the idea above of making sure that
> > all these artifacts be placed in the gdb.ada directory for all Ada
> > testcases. Hence the attached patch. One note, however: contrary to
> > C where temporary .o files are automatically deleted, gnatmake leaves
> > behind. This is to allow incremental builds, similar what make does.
> > This will cause a much higher number of object files to be created
> > in the testsuite directory. I hope this is fine? Otherwise, we'll
> > can use the previous approach, but I believe it should be done
> > consistently across all languages.
> 
> I would prefer to have them placed in the subdirectory.  Can't you
> specify an output directory for gnatmake?  It seems like a terrible
> limitation.

Normally, gnatmake is just a tool like make which job is to call the
compiler with the appropriate switches. It actually does a "little more"
since is also evaluates the dependencies and determines which files need
to be recompiled, but the general idea is that gnatmake = make for GNAT.

That being said, it just occured to me that there is a very simple way
to control the location of the files generated by gnatmake: the GNAT
project files. I created a new file gnat_ada.gpr.in in gdb.ada which
contains the following:

<<
--  This project files allows us to control the loation where the
--  compilation artifacts produced when building the Ada examples
--  are stored.

project Gnat_Ada is

   for Source_Dirs use ("@srcdir@");
   --  No need to set the Object_Dir, it is set to "." by default.

end Gnat_Ada;
>>

And then building a typical Ada program will be done using the
following command:

        % gnatmake -P$objdir/gdb.ada/gnat_ada -g <src_file> -o <dest>

where <src_file> is the name of the Ada file (*basename* only)
and <dest> is the name of the executable (can be basename or fullname,
it doesn't matter)

> Also, gdb_compile_ada may want to remove the incremental files in this
> case, since the testsuite will not use them.

gnatmake will. For instance gnatmake won't recompile the test programs
on subsequent runs, unless the sources have changes. Or if we have two
test programs depending on the same unit, this unit will only be compiled
once. I think we should keep them, they are useful.

> > +    lappend options "compiler=gnatmake"
> 
> See find_gcc in dejagnu's libgloss.exp.

Could you explain a bit more what you mean (sorry, dejagnu is still
new to me, and I have allergic reactions to tcl and expect :-/)?
Do you means that I should create a new find_gnatmake function and
then do

        lappend options "compiler=[find_gnatmake]"

instead? I think this is the last sticky point to look at before being
able to properly submit these changes for inclusion.

Here is a small preview of where I current am, adding our first ada
testcase to our dejagnu testsuite. This is with our debugger based on
6.0, but should be fairly close to apply to head as well.

        * lib/gdb.exp (gdb_compile_ada): New function.
        * lib/ada.exp: New file.
        * gdb.ada/Makefile.in: New file.
        * gdb.ada/gnat_ada.gpr.in: New file.
        * Makefile.in (ALL_SUBDIRS): Add gdb.ada.
        * configure.in: Generate gdb.ada/Makefile and gdb.ada/gnat_ada.gpr.

And the new testcase:

        * gdb.ada/bar.ads: New file.
        * gdb.ada/bar.adb: New file.
        * gdb.ada/null_record.adb: New file.
        * gdb.ada/null_record.exp: New file.

Am I on the right track?

Thanks,
-- 
Joel

[-- Attachment #2: lib-gdb.exp.diff --]
[-- Type: text/plain, Size: 940 bytes --]

Index: lib/gdb.exp
===================================================================
RCS file: /nile.c/cvs/Dev/gdb/gdb-6.0/gdb/testsuite/lib/gdb.exp,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 gdb.exp
--- lib/gdb.exp	5 Oct 2003 10:40:20 -0000	1.1.1.1
+++ lib/gdb.exp	26 Feb 2004 22:31:36 -0000
@@ -1323,6 +1323,26 @@
     }
 }
 
+#
+# Compile some Ada code.
+#
+proc gdb_compile_ada {source dest type options} {
+
+    set objdir [file dirname $dest]
+
+    lappend options "compiler=gnatmake"
+    append options " additional_flags=-P$objdir/gnat_ada"
+
+    set result [target_compile $source $dest $type $options]
+
+    # Make sure that the dest file has been created.  Otherwise,
+    # the build has failed.
+    if ![file exists $dest] {
+        verbose "Ada compilation failed: $result"
+        return "Ada compilation failed."
+    }
+}
+
 proc send_gdb { string } {
     global suppress_flag;
     if { $suppress_flag } {

[-- Attachment #3: ada.exp --]
[-- Type: text/plain, Size: 126 bytes --]

load_lib libgloss.exp

proc gdb_begin {args expected_output} {
   gdb_test "begin $args" "$expected_output" "begin command"
}

[-- Attachment #4: Makefile.in --]
[-- Type: text/plain, Size: 580 bytes --]

VPATH = @srcdir@
srcdir = @srcdir@

EXECUTABLES = null_record

MISCELLANEOUS =

all info install-info dvi install uninstall installcheck check:
	@echo "Nothing to be done for $@..."

clean mostlyclean:
	-gnatclean -Pgnat_ada -q $(EXECUTABLES)
	-rm -f *~ *.o a.out xgdb *.x *.ci *.tmp
	-rm -f core core.coremaker coremaker.core corefile $(EXECUTABLES)
	-rm -f $(MISCELLANEOUS) twice-tmp.c

distclean maintainer-clean realclean: clean
	-rm -f *~ core
	-rm -f Makefile config.status config.log gnat_ada.gpr
	-rm -f *-init.exp
	-rm -fr *.log summary detail *.plog *.sum *.psum site.*

[-- Attachment #5: gnat_ada.gpr.in --]
[-- Type: text/plain, Size: 289 bytes --]

--  This project files allows us to control the loation where the
--  compilation artifacts produced when building the Ada examples
--  are stored.

project Gnat_Ada is

   for Source_Dirs use ("@srcdir@");
   --  No need to set the Object_Dir, it is set to "." by default.

end Gnat_Ada;

[-- Attachment #6: dejagnu.ada.diff --]
[-- Type: text/plain, Size: 1464 bytes --]

Index: Makefile.in
===================================================================
RCS file: /nile.c/cvs/Dev/gdb/gdb-6.0/gdb/testsuite/Makefile.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile.in
--- Makefile.in	5 Oct 2003 10:40:09 -0000	1.1.1.1
+++ Makefile.in	26 Feb 2004 22:29:22 -0000
@@ -35,8 +35,8 @@
 EXEEXT = @EXEEXT@
 SUBDIRS = @subdirs@
 RPATH_ENVVAR = @RPATH_ENVVAR@
-ALL_SUBDIRS = gdb.arch gdb.asm gdb.base gdb.cp gdb.disasm gdb.java gdb.mi \
-	gdb.objc gdb.threads gdb.trace $(SUBDIRS)
+ALL_SUBDIRS = gdb.ada gdb.arch gdb.asm gdb.base gdb.cp gdb.disasm \
+	gdb.java gdb.mi gdb.objc gdb.threads gdb.trace $(SUBDIRS)
 
 EXPECT = `if [ -f $${rootme}/../../expect/expect ] ; then \
           echo $${rootme}/../../expect/expect ; \
Index: configure.in
===================================================================
RCS file: /nile.c/cvs/Dev/gdb/gdb-6.0/gdb/testsuite/configure.in,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 configure.in
--- configure.in	5 Oct 2003 10:40:09 -0000	1.1.1.1
+++ configure.in	26 Feb 2004 22:29:22 -0000
@@ -112,6 +112,7 @@
 AC_EXEEXT
 
 AC_CONFIG_SUBDIRS($configdirs)
-AC_OUTPUT([Makefile gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile \
+AC_OUTPUT([Makefile gdb.ada/Makefile gdb.ada/gnat_ada.gpr \
+  gdb.arch/Makefile gdb.asm/Makefile gdb.base/Makefile \
   gdb.cp/Makefile gdb.disasm/Makefile gdb.java/Makefile gdb.mi/Makefile \
   gdb.objc/Makefile gdb.threads/Makefile gdb.trace/Makefile])

[-- Attachment #7: bar.ads --]
[-- Type: text/plain, Size: 83 bytes --]


package Bar is

   type Empty is null record;

   procedure Do_Nothing;

end Bar;

[-- Attachment #8: bar.adb --]
[-- Type: text/plain, Size: 98 bytes --]

package body Bar is

   procedure Do_Nothing is
   begin
      null;
   end Do_Nothing;

end Bar;

[-- Attachment #9: null_record.adb --]
[-- Type: text/plain, Size: 84 bytes --]

with Bar; use Bar;

procedure Null_Record is
begin
   Do_Nothing;
end Null_Record;


[-- Attachment #10: null_record.exp --]
[-- Type: text/plain, Size: 503 bytes --]

if $tracelevel then {
    strace $tracelevel
}

load_lib "ada.exp"

set testfile "null_record"
set srcfile ${testfile}.adb
set binfile ${objdir}/${subdir}/${testfile}

if {[gdb_compile_ada "${srcfile}" "${binfile}" executable [list debug ]] != "" } {
  return -1
}

gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}

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

gdb_test "ptype empty" \
         "type = record null; end record" \
         "ptype on null record"

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Daniel Jacobowitz]

On Thu, Feb 26, 2004 at 02:37:42PM -0800, Joel Brobecker wrote:
> And then building a typical Ada program will be done using the
> following command:
> 
>         % gnatmake -P$objdir/gdb.ada/gnat_ada -g <src_file> -o <dest>
> 
> where <src_file> is the name of the Ada file (*basename* only)
> and <dest> is the name of the executable (can be basename or fullname,
> it doesn't matter)

Great.

> > Also, gdb_compile_ada may want to remove the incremental files in this
> > case, since the testsuite will not use them.
> 
> gnatmake will. For instance gnatmake won't recompile the test programs
> on subsequent runs, unless the sources have changes. Or if we have two
> test programs depending on the same unit, this unit will only be compiled
> once. I think we should keep them, they are useful.

Well, I'm not so sure that qualifies as useful for the testsuite, but
if they go into gdb.ada I don't care :)

> > > +    lappend options "compiler=gnatmake"
> > 
> > See find_gcc in dejagnu's libgloss.exp.
> 
> Could you explain a bit more what you mean (sorry, dejagnu is still
> new to me, and I have allergic reactions to tcl and expect :-/)?
> Do you means that I should create a new find_gnatmake function and
> then do
> 
>         lappend options "compiler=[find_gnatmake]"
> 
> instead? I think this is the last sticky point to look at before being
> able to properly submit these changes for inclusion.

Aye.  You can put find_gnatmake in gdb.exp for now and submit it to
dejagnu later.

The basic goals of the function are:
  - Find an in-tree gnatmake and pass it appropriate options to run
    from in-tree, for testing a combined tree.
  - Use [transform], which will supply the appropriate cross prefixes.

> load_lib libgloss.exp
> 
> proc gdb_begin {args expected_output} {
>    gdb_test "begin $args" "$expected_output" "begin command"
> }

What's begin do again in your sources?  Also, I'm not sure about the
need for an ada.exp; what else do you expet to go here?

Otherwise it looks reasonable.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

Hello Daniel,

I think I am starting to slooooowly understand how this is all supposed
to work. Would you mind reviewing what I have done so far, though, to
see if I am heading in the right direction. I modified some files in
dejagnu (used the CVS version from src), modified gdb.exp in gdb/.../lib,
and added some others.

First, some answers to your previous questions:

> > gnatmake will. For instance gnatmake won't recompile the test programs
> > on subsequent runs, unless the sources have changes. Or if we have two
> > test programs depending on the same unit, this unit will only be compiled
> > once. I think we should keep them, they are useful.
> 
> Well, I'm not so sure that qualifies as useful for the testsuite, but
> if they go into gdb.ada I don't care :)

Great :)

> > proc gdb_begin {args expected_output} {
> >    gdb_test "begin $args" "$expected_output" "begin command"
> > }
> 
> What's begin do again in your sources?  Also, I'm not sure about the
> need for an ada.exp; what else do you expet to go here?

"begin" is the Ada equivalent of the "break main; run" sequence in
C. Basically, the main function in Ada is not necessarily called main.
In fact, it is almost always never called main. The "begin" command
digs into an Ada executable, finds the function name of the main
routine, puts a temporary breakpoint inside it, and then "run".

proc "gdb_begin" is designed to be the equivalent of "runto_main"
for C and C++.

So far, I don't anticipate anything else in ada.exp, but my little
finger tells me that we will likely need something else one day which
will fit perfectly into that file. Perhaps even our new gdb_compile_ada
procedure should be placed into this file?  I am perfectly happy to put
this proc in gdb.exp, however, and drop the idea of a new ada.exp file.

> Aye.  You can put find_gnatmake in gdb.exp for now and submit it to
> dejagnu later.
> 
> The basic goals of the function are:
>   - Find an in-tree gnatmake and pass it appropriate options to run
>     from in-tree, for testing a combined tree.
>   - Use [transform], which will supply the appropriate cross prefixes.

OK, here is how I understand thigs should be implemented to add support
for Ada.

  - In libgloss.exp, I need to add a new function "find_gnatmake"

<<
+proc find_gnatmake {} {
+    global tool_root_dir
+
+    set root "$tool_root_dir/gcc"
+    set GM ""
+
+    if ![is_remote host] {
+        set file [lookfor_file $root gnatmake]
+        if { $file != "" } {
+            set GM "$file -I$root/ada/rts --GCC=$root/xgcc --GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs --GCC=$root/xgcc -margs";
+        }
+    }
+
+    if {$GM == ""} {
+        set GM [transform gnatmake]
+    }
+
+    return $GM
+}
+
>>

  - In target.exp (default_target_compile): I need to add handling of
    Ada sources via the "ada" option keyword:

<<
@@ -333,6 +333,19 @@ proc default_target_compile {source dest
     }
 
     foreach i $options {
+       if { $i == "ada" } {
+           set compiler_type "ada"
+           if [board_info $dest exists gnatmakeflags] {
+               append add_flags " [target_info gnatmakeflags]"
+           }
+           # append add_flags " [gnatmake_include_flags]";
+           if [board_info $dest exists gnatmakecompiler] {
+               set compiler [target_info gnatmakecompiler];
+           } else {
+               set compiler [find_gnatmake];
+           }
+       }
+
        if { $i == "c++" } {
            set compiler_type "c++"
            if [board_info $dest exists cxxflags] {
@@ -412,6 +425,7 @@ proc default_target_compile {source dest
     global CC_FOR_TARGET
     global CXX_FOR_TARGET
     global F77_FOR_TARGET
+    global GNATMAKE_FOR_TARGET
     
     if [info exists CC_FOR_TARGET] {
        if { $compiler == "" } {
@@ -428,6 +442,12 @@ proc default_target_compile {source dest
     if [info exists F77_FOR_TARGET] {
        if { $compiler_type == "f77" } {
            set compiler $F77_FOR_TARGET
+       }
+    }
+
+    if [info exists GNATMAKE_FOR_TARGET] {
+       if { $compiler_type == "ada" } {
+           set compiler $GNATMAKE_FOR_TARGET
        }
     }
>> 

Then my new gdb_compile_ada function in gdb.exp simply becomes:

<<
proc gdb_compile_ada {source dest objdir type options} {

    append options " ada"
    append options " additional_flags=-P${objdir}/gnat_ada"

    set result [target_compile $source $dest $type $options]

    # Make sure that the dest file has been created.  Otherwise,
    # the build has failed.
    if ![file exists $dest] {
        verbose "Ada compilation failed: $result"
        return "Ada compilation failed."
    }
}
>>

And a simple testcase checking the null record problem is gone:

<<
if $tracelevel then {
    strace $tracelevel
}

load_lib "ada.exp"

set testfile "null_record"
set srcfile ${testfile}.adb
set binfile ${objdir}/${subdir}/${testfile}

if {[gdb_compile_ada "${srcfile}" "${binfile}" "${objdir}/${subdir}" executable [list debug ]] != "" } {
  return -1
}

gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}

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

gdb_test "ptype empty" \
         "type = record null; end record" \
         "ptype on null record"
>>

What do you think?

Thanks a lot for you help, Daniel,
-- 
Joel

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Daniel Jacobowitz]

On Tue, Mar 02, 2004 at 08:21:07PM -0800, Joel Brobecker wrote:
> "begin" is the Ada equivalent of the "break main; run" sequence in
> C. Basically, the main function in Ada is not necessarily called main.
> In fact, it is almost always never called main. The "begin" command
> digs into an Ada executable, finds the function name of the main
> routine, puts a temporary breakpoint inside it, and then "run".
> 
> proc "gdb_begin" is designed to be the equivalent of "runto_main"
> for C and C++.

OK; any interest in breaking out the language-independent bits of this
feature for review and discussion?  While it's pretty uninteresting for
C/C++, it should work there.  For Java and Fortran this could be
useful, since they also have the concept of a main program.  At least
GCJ does, I'm not sure about Java in general.

By the way, there's a problem with gdb_begin: it can only be used once
because it counts as a PASS/FAIL with a specific hardcoded name.  It
should either not be a test, or more likely, should have a unique name.
At that point, why have a procedure for it?  You're just passing its
arguments to gdb_test.

> So far, I don't anticipate anything else in ada.exp, but my little
> finger tells me that we will likely need something else one day which
> will fit perfectly into that file. Perhaps even our new gdb_compile_ada
> procedure should be placed into this file?  I am perfectly happy to put
> this proc in gdb.exp, however, and drop the idea of a new ada.exp file.

I'm perfectly happy with it in ada.exp.  If we do that, let's put
gdb_compile_ada there also.

>   - In libgloss.exp, I need to add a new function "find_gnatmake"
> 
> <<
> +proc find_gnatmake {} {
> +    global tool_root_dir
> +
> +    set root "$tool_root_dir/gcc"
> +    set GM ""
> +
> +    if ![is_remote host] {
> +        set file [lookfor_file $root gnatmake]
> +        if { $file != "" } {
> +            set GM "$file -I$root/ada/rts --GCC=$root/xgcc --GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs --GCC=$root/xgcc -margs";
> +        }
> +    }
> +
> +    if {$GM == ""} {
> +        set GM [transform gnatmake]
> +    }
> +
> +    return $GM
> +}
> +
> >>

Looks plausible to me.  Note, we could also put this in ada.exp.  TCL
doesn't much care.  But if you'll need changes to dejagnu anyway then
libgloss.exp is probably the right place; I hadn't noticed this next
bit:

>   - In target.exp (default_target_compile): I need to add handling of
>     Ada sources via the "ada" option keyword:
> 
> <<
> @@ -333,6 +333,19 @@ proc default_target_compile {source dest
>      }
>  
>      foreach i $options {
> +       if { $i == "ada" } {
> +           set compiler_type "ada"
> +           if [board_info $dest exists gnatmakeflags] {
> +               append add_flags " [target_info gnatmakeflags]"
> +           }
> +           # append add_flags " [gnatmake_include_flags]";
> +           if [board_info $dest exists gnatmakecompiler] {
> +               set compiler [target_info gnatmakecompiler];
> +           } else {
> +               set compiler [find_gnatmake];
> +           }
> +       }
> +
>         if { $i == "c++" } {
>             set compiler_type "c++"
>             if [board_info $dest exists cxxflags] {

How would you feel about adaflags and adacompiler instead, for parallel
with the other languages?  Maybe adaflags and gnatmake, since gnatmake
isn't strictly speaking the "compiler".

> @@ -412,6 +425,7 @@ proc default_target_compile {source dest
>      global CC_FOR_TARGET
>      global CXX_FOR_TARGET
>      global F77_FOR_TARGET
> +    global GNATMAKE_FOR_TARGET
>      
>      if [info exists CC_FOR_TARGET] {
>         if { $compiler == "" } {
> @@ -428,6 +442,12 @@ proc default_target_compile {source dest
>      if [info exists F77_FOR_TARGET] {
>         if { $compiler_type == "f77" } {
>             set compiler $F77_FOR_TARGET
> +       }
> +    }
> +
> +    if [info exists GNATMAKE_FOR_TARGET] {
> +       if { $compiler_type == "ada" } {
> +           set compiler $GNATMAKE_FOR_TARGET
>         }
>      }
> >> 

Looks good... these bits will of course have to go to dejagnu@gnu.org
once you have something working.  I'd prefer to find a way to bail out
gracefully if the host DejaGNU doesn't have them, too.  We can use
[info proc find_gnatmake] for that, in gdb_compile_ada.

> Then my new gdb_compile_ada function in gdb.exp simply becomes:
> 
> <<
> proc gdb_compile_ada {source dest objdir type options} {
> 
>     append options " ada"
>     append options " additional_flags=-P${objdir}/gnat_ada"
> 
>     set result [target_compile $source $dest $type $options]
> 
>     # Make sure that the dest file has been created.  Otherwise,
>     # the build has failed.

Please mention explicitly that gnatmake produces output even if
successful.

>     if ![file exists $dest] {
>         verbose "Ada compilation failed: $result"
>         return "Ada compilation failed."
>     }
> }
> >>
> 
> And a simple testcase checking the null record problem is gone:
> 
> <<
> if $tracelevel then {
>     strace $tracelevel
> }
> 
> load_lib "ada.exp"
> 
> set testfile "null_record"
> set srcfile ${testfile}.adb
> set binfile ${objdir}/${subdir}/${testfile}
> 
> if {[gdb_compile_ada "${srcfile}" "${binfile}" "${objdir}/${subdir}" executable [list debug ]] != "" } {
>   return -1
> }
> 
> gdb_exit
> gdb_start
> gdb_reinitialize_dir $srcdir/$subdir
> gdb_load ${binfile}
> 
> gdb_begin "" "Breakpoint \[0-9\]+ at .*null_record.adb.*"
> 
> gdb_test "ptype empty" \
>          "type = record null; end record" \
>          "ptype on null record"
> >>
> 
> What do you think?

The test itself looks sane.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

Thank you very much for your very helpful comments, Daniel!

> OK; any interest in breaking out the language-independent bits of this
> feature for review and discussion?  While it's pretty uninteresting for
> C/C++, it should work there.  For Java and Fortran this could be
> useful, since they also have the concept of a main program.  At least
> GCJ does, I'm not sure about Java in general.

Sure. I'll make a note of starting a new thread about this. I think it
will be useful even in C. Using "begin" is shorter than doing "tbreak
main; run" (although one can use a user-defined function, true).

> By the way, there's a problem with gdb_begin: it can only be used once
> because it counts as a PASS/FAIL with a specific hardcoded name.  It
> should either not be a test, or more likely, should have a unique name.

True (but one could argue that runto_main has the same problem, right?  :-)
We can add an extra optional parameter (to be used only when this
function is used more than once in a given testcase), but...

> At that point, why have a procedure for it?  You're just passing its
> arguments to gdb_test.

... that would not be necessary if we decide that it's not worth
creating this new function. Indeed, it is just as simple to call
gdb_test directly. Except that I just remembered that there are cases
where we will need to pass an argument to the begin command [1].

I know of only one system (VxWorks) where this is extra parameter
is necessary. On this system, and with GNAT, the extra parameter is
identical to the name of the executable (ie we've decided that the entry
point name would be identical to the name of main procedure).  So I
think we eventually want gdb_begin to be intelligent enough to compute
the name of the entry-point, and then fill in the extra parameter
automatically. I haven't thought this through yet, but I see one way of
doing it:

proc gdb_begin {entry_point expected_output opt_id} {
   set begin_command "begin"

   if [is_remote host] {
       if [istarget "*-*-vxworks*"] {
           # The VxWorks debugger requires that we provide the name of
           # the entry-point in the module we want to debug.
           set begin_command "$begin_command $entry_point"
       }
   }

   gdb_test "begin $entry_point" "$expected_output" "begin command $opt_id"
}

As I don't see any supported platform where this would be necessary yet,
I simply suggest that we keep the original gdb_begin procedure,
but with an extra comment inside saying that we expect that this
function might eventually be upgraded to support certain more tricky
cases such as remote-debugging on VxWorks targets for instance (and with
an extra optional parameter to address the issue you raised above).
In the meantime, this function allows us to track all calls to the
"begin" command.

Sounds fair?

> > So far, I don't anticipate anything else in ada.exp, but my little
> > finger tells me that we will likely need something else one day which
> > will fit perfectly into that file. Perhaps even our new gdb_compile_ada
> > procedure should be placed into this file?  I am perfectly happy to put
> > this proc in gdb.exp, however, and drop the idea of a new ada.exp file.
> 
> I'm perfectly happy with it in ada.exp.  If we do that, let's put
> gdb_compile_ada there also.

OK, will move the function there if we agree on keeping gdb_begin.
Which will eventually have to be moved to gdb.exp if we later agree
on implementing the begin command for all languages :-).

> >   - In libgloss.exp, I need to add a new function "find_gnatmake"
> > 
> > <<
> > +proc find_gnatmake {} {
> > +    global tool_root_dir
> > +
> > +    set root "$tool_root_dir/gcc"
> > +    set GM ""
> > +
> > +    if ![is_remote host] {
> > +        set file [lookfor_file $root gnatmake]
> > +        if { $file != "" } {
> > +            set GM "$file -I$root/ada/rts --GCC=$root/xgcc --GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs --GCC=$root/xgcc -margs";
> > +        }
> > +    }
> > +
> > +    if {$GM == ""} {
> > +        set GM [transform gnatmake]
> > +    }
> > +
> > +    return $GM
> > +}
> > +
> > >>
> 
> Looks plausible to me.  Note, we could also put this in ada.exp.  TCL
> doesn't much care.  But if you'll need changes to dejagnu anyway then
> libgloss.exp is probably the right place; I hadn't noticed this next
> bit:
> 
> >   - In target.exp (default_target_compile): I need to add handling of
> >     Ada sources via the "ada" option keyword:
> > 
> > <<
> > @@ -333,6 +333,19 @@ proc default_target_compile {source dest
> >      }
> >  
> >      foreach i $options {
> > +       if { $i == "ada" } {
> > +           set compiler_type "ada"
> > +           if [board_info $dest exists gnatmakeflags] {
> > +               append add_flags " [target_info gnatmakeflags]"
> > +           }
> > +           # append add_flags " [gnatmake_include_flags]";
> > +           if [board_info $dest exists gnatmakecompiler] {
> > +               set compiler [target_info gnatmakecompiler];
> > +           } else {
> > +               set compiler [find_gnatmake];
> > +           }
> > +       }
> > +
> >         if { $i == "c++" } {
> >             set compiler_type "c++"
> >             if [board_info $dest exists cxxflags] {
> 
> How would you feel about adaflags and adacompiler instead, for parallel
> with the other languages?  Maybe adaflags and gnatmake, since gnatmake
> isn't strictly speaking the "compiler".

I am happy with "adaflags", but as you have guessed, I'm a bit
relunctant with "adacompiler". I like "gnatmake" better than
"gnatmakecompiler" (yeeewww!). Maybe "adamake"?

> > @@ -412,6 +425,7 @@ proc default_target_compile {source dest
> >      global CC_FOR_TARGET
> >      global CXX_FOR_TARGET
> >      global F77_FOR_TARGET
> > +    global GNATMAKE_FOR_TARGET
> >      
> >      if [info exists CC_FOR_TARGET] {
> >         if { $compiler == "" } {
> > @@ -428,6 +442,12 @@ proc default_target_compile {source dest
> >      if [info exists F77_FOR_TARGET] {
> >         if { $compiler_type == "f77" } {
> >             set compiler $F77_FOR_TARGET
> > +       }
> > +    }
> > +
> > +    if [info exists GNATMAKE_FOR_TARGET] {
> > +       if { $compiler_type == "ada" } {
> > +           set compiler $GNATMAKE_FOR_TARGET
> >         }
> >      }
> > >> 
> 
> Looks good... these bits will of course have to go to dejagnu@gnu.org
> once you have something working.  I'd prefer to find a way to bail out
> gracefully if the host DejaGNU doesn't have them, too.  We can use
> [info proc find_gnatmake] for that, in gdb_compile_ada.

It sounded like a good idea, and I added the following check.

    if ![info proc find_gnatmake] {
        # If the version of dejagnu being used does not provide
        # procedure find_gnatmake, then we know the build will fail.
        # Better to bail out gracefully now rather than having
        # dejagnu abort the entire run later when it finds it needs
        # this procedure but can't find it.
        verbose "find_gnatmake procedure not found. Update dejagnu?"
        return "Ada compilation failed: find_gnatmake procedure not found."
    }

However, since find_gnatmake will only be called iff target_compile
(which is in dejagnu:target.exp) is upgraded to recognize the "ada"
option keyword. Otherwise, I've tried it, it defaults to using gcc.
And the gdb_compile_ada then fails without aborting the entire
testsuite run. So it looks like we can do without the extra check.

> > Then my new gdb_compile_ada function in gdb.exp simply becomes:
> > 
> > <<
> > proc gdb_compile_ada {source dest objdir type options} {
> > 
> >     append options " ada"
> >     append options " additional_flags=-P${objdir}/gnat_ada"
> > 
> >     set result [target_compile $source $dest $type $options]
> > 
> >     # Make sure that the dest file has been created.  Otherwise,
> >     # the build has failed.
> 
> Please mention explicitly that gnatmake produces output even if
> successful.

Good idea. I just addded:

    # The Ada build always produces some output, even when the build
    # succeeds. Thus, we can not use the output the same way we do in
    # gdb_compile to determine whether the build has succeeded or not.
    # We therefore simply check whether the dest file has been created
    # or not. Unless not present, the build has succeeded.


> The test itself looks sane.

Cool! :-)

Thanks again, Daniel.

-- 
Joel

[1] At least on VxWorks, the user needs to provide the name of the
    entry-point into the "executable" (aka "module") he wants to run.
    This allow GDB to tell the target where to start the execution of
    the inferior from. The extra argument is also necessary for the
    "run" command too.

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Daniel Jacobowitz]

On Thu, Mar 04, 2004 at 10:03:22PM -0800, Joel Brobecker wrote:
> Thank you very much for your very helpful comments, Daniel!
> 
> > OK; any interest in breaking out the language-independent bits of this
> > feature for review and discussion?  While it's pretty uninteresting for
> > C/C++, it should work there.  For Java and Fortran this could be
> > useful, since they also have the concept of a main program.  At least
> > GCJ does, I'm not sure about Java in general.
> 
> Sure. I'll make a note of starting a new thread about this. I think it
> will be useful even in C. Using "begin" is shorter than doing "tbreak
> main; run" (although one can use a user-defined function, true).
> 
> > By the way, there's a problem with gdb_begin: it can only be used once
> > because it counts as a PASS/FAIL with a specific hardcoded name.  It
> > should either not be a test, or more likely, should have a unique name.
> 
> True (but one could argue that runto_main has the same problem, right?  :-)

No.  Take a look at the implementation of runto; it does not issue a
PASS if it messes up.  It does issue a fixed fail message but the
expectation is that you'll bail out of the test script if that happens.

> We can add an extra optional parameter (to be used only when this
> function is used more than once in a given testcase), but...
> 
> > At that point, why have a procedure for it?  You're just passing its
> > arguments to gdb_test.
> 
> ... that would not be necessary if we decide that it's not worth
> creating this new function. Indeed, it is just as simple to call
> gdb_test directly. Except that I just remembered that there are cases
> where we will need to pass an argument to the begin command [1].
> 
> I know of only one system (VxWorks) where this is extra parameter
> is necessary. On this system, and with GNAT, the extra parameter is
> identical to the name of the executable (ie we've decided that the entry
> point name would be identical to the name of main procedure).  So I
> think we eventually want gdb_begin to be intelligent enough to compute
> the name of the entry-point, and then fill in the extra parameter
> automatically. I haven't thought this through yet, but I see one way of
> doing it:
> 
> proc gdb_begin {entry_point expected_output opt_id} {
>    set begin_command "begin"
> 
>    if [is_remote host] {
>        if [istarget "*-*-vxworks*"] {
>            # The VxWorks debugger requires that we provide the name of
>            # the entry-point in the module we want to debug.
>            set begin_command "$begin_command $entry_point"
>        }
>    }
> 
>    gdb_test "begin $entry_point" "$expected_output" "begin command $opt_id"
> }
> 
> As I don't see any supported platform where this would be necessary yet,
> I simply suggest that we keep the original gdb_begin procedure,
> but with an extra comment inside saying that we expect that this
> function might eventually be upgraded to support certain more tricky
> cases such as remote-debugging on VxWorks targets for instance (and with
> an extra optional parameter to address the issue you raised above).
> In the meantime, this function allows us to track all calls to the
> "begin" command.
> 
> Sounds fair?

I would like to discuss the meaning of begin separately.  You haven't
told me what the parameter is; what GDB uses it for; or why providing
something other than the name of the entry point would be useful. 
Since if it isn't useful, GDB should take care of this itself on
vxworks for a uniform command syntax.

> I am happy with "adaflags", but as you have guessed, I'm a bit
> relunctant with "adacompiler". I like "gnatmake" better than
> "gnatmakecompiler" (yeeewww!). Maybe "adamake"?

Let's stick to gnatmake.  If someday (unlikely, but hey...) DejaGNU is
used to test some other Ada compiler, I bet it won't have a foomake
that takes gnatmake arguments.

> It sounded like a good idea, and I added the following check.
> 
>     if ![info proc find_gnatmake] {
>         # If the version of dejagnu being used does not provide
>         # procedure find_gnatmake, then we know the build will fail.
>         # Better to bail out gracefully now rather than having
>         # dejagnu abort the entire run later when it finds it needs
>         # this procedure but can't find it.
>         verbose "find_gnatmake procedure not found. Update dejagnu?"
>         return "Ada compilation failed: find_gnatmake procedure not found."
>     }
> 
> However, since find_gnatmake will only be called iff target_compile
> (which is in dejagnu:target.exp) is upgraded to recognize the "ada"
> option keyword. Otherwise, I've tried it, it defaults to using gcc.
> And the gdb_compile_ada then fails without aborting the entire
> testsuite run. So it looks like we can do without the extra check.

But it will fail messily after trying to use GCC to compile Ada source,
right?  That's what I want to avoid.

> [1] At least on VxWorks, the user needs to provide the name of the
>     entry-point into the "executable" (aka "module") he wants to run.
>     This allow GDB to tell the target where to start the execution of
>     the inferior from. The extra argument is also necessary for the
>     "run" command too.

Ooh, an explanatory footnote.  I missed that.  I understand why this
might be, but is it ever useful to the user to provide something other
than the normal, debug-info-specified entry point?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Daniel Jacobowitz]

On Tue, Mar 02, 2004 at 08:21:07PM -0800, Joel Brobecker wrote:
> "begin" is the Ada equivalent of the "break main; run" sequence in
> C. Basically, the main function in Ada is not necessarily called main.
> In fact, it is almost always never called main. The "begin" command
> digs into an Ada executable, finds the function name of the main
> routine, puts a temporary breakpoint inside it, and then "run".
> 
> proc "gdb_begin" is designed to be the equivalent of "runto_main"
> for C and C++.

OK; any interest in breaking out the language-independent bits of this
feature for review and discussion?  While it's pretty uninteresting for
C/C++, it should work there.  For Java and Fortran this could be
useful, since they also have the concept of a main program.  At least
GCJ does, I'm not sure about Java in general.

By the way, there's a problem with gdb_begin: it can only be used once
because it counts as a PASS/FAIL with a specific hardcoded name.  It
should either not be a test, or more likely, should have a unique name.
At that point, why have a procedure for it?  You're just passing its
arguments to gdb_test.

> So far, I don't anticipate anything else in ada.exp, but my little
> finger tells me that we will likely need something else one day which
> will fit perfectly into that file. Perhaps even our new gdb_compile_ada
> procedure should be placed into this file?  I am perfectly happy to put
> this proc in gdb.exp, however, and drop the idea of a new ada.exp file.

I'm perfectly happy with it in ada.exp.  If we do that, let's put
gdb_compile_ada there also.

>   - In libgloss.exp, I need to add a new function "find_gnatmake"
> 
> <<
> +proc find_gnatmake {} {
> +    global tool_root_dir
> +
> +    set root "$tool_root_dir/gcc"
> +    set GM ""
> +
> +    if ![is_remote host] {
> +        set file [lookfor_file $root gnatmake]
> +        if { $file != "" } {
> +            set GM "$file -I$root/ada/rts --GCC=$root/xgcc --GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs --GCC=$root/xgcc -margs";
> +        }
> +    }
> +
> +    if {$GM == ""} {
> +        set GM [transform gnatmake]
> +    }
> +
> +    return $GM
> +}
> +
> >>

Looks plausible to me.  Note, we could also put this in ada.exp.  TCL
doesn't much care.  But if you'll need changes to dejagnu anyway then
libgloss.exp is probably the right place; I hadn't noticed this next
bit:

>   - In target.exp (default_target_compile): I need to add handling of
>     Ada sources via the "ada" option keyword:
> 
> <<
> @@ -333,6 +333,19 @@ proc default_target_compile {source dest
>      }
>  
>      foreach i $options {
> +       if { $i == "ada" } {
> +           set compiler_type "ada"
> +           if [board_info $dest exists gnatmakeflags] {
> +               append add_flags " [target_info gnatmakeflags]"
> +           }
> +           # append add_flags " [gnatmake_include_flags]";
> +           if [board_info $dest exists gnatmakecompiler] {
> +               set compiler [target_info gnatmakecompiler];
> +           } else {
> +               set compiler [find_gnatmake];
> +           }
> +       }
> +
>         if { $i == "c++" } {
>             set compiler_type "c++"
>             if [board_info $dest exists cxxflags] {

How would you feel about adaflags and adacompiler instead, for parallel
with the other languages?  Maybe adaflags and gnatmake, since gnatmake
isn't strictly speaking the "compiler".

> @@ -412,6 +425,7 @@ proc default_target_compile {source dest
>      global CC_FOR_TARGET
>      global CXX_FOR_TARGET
>      global F77_FOR_TARGET
> +    global GNATMAKE_FOR_TARGET
>      
>      if [info exists CC_FOR_TARGET] {
>         if { $compiler == "" } {
> @@ -428,6 +442,12 @@ proc default_target_compile {source dest
>      if [info exists F77_FOR_TARGET] {
>         if { $compiler_type == "f77" } {
>             set compiler $F77_FOR_TARGET
> +       }
> +    }
> +
> +    if [info exists GNATMAKE_FOR_TARGET] {
> +       if { $compiler_type == "ada" } {
> +           set compiler $GNATMAKE_FOR_TARGET
>         }
>      }
> >> 

Looks good... these bits will of course have to go to dejagnu@gnu.org
once you have something working.  I'd prefer to find a way to bail out
gracefully if the host DejaGNU doesn't have them, too.  We can use
[info proc find_gnatmake] for that, in gdb_compile_ada.

> Then my new gdb_compile_ada function in gdb.exp simply becomes:
> 
> <<
> proc gdb_compile_ada {source dest objdir type options} {
> 
>     append options " ada"
>     append options " additional_flags=-P${objdir}/gnat_ada"
> 
>     set result [target_compile $source $dest $type $options]
> 
>     # Make sure that the dest file has been created.  Otherwise,
>     # the build has failed.

Please mention explicitly that gnatmake produces output even if
successful.

>     if ![file exists $dest] {
>         verbose "Ada compilation failed: $result"
>         return "Ada compilation failed."
>     }
> }
> >>
> 
> And a simple testcase checking the null record problem is gone:
> 
> <<
> if $tracelevel then {
>     strace $tracelevel
> }
> 
> load_lib "ada.exp"
> 
> set testfile "null_record"
> set srcfile ${testfile}.adb
> set binfile ${objdir}/${subdir}/${testfile}
> 
> if {[gdb_compile_ada "${srcfile}" "${binfile}" "${objdir}/${subdir}" executable [list debug ]] != "" } {
>   return -1
> }
> 
> gdb_exit
> gdb_start
> gdb_reinitialize_dir $srcdir/$subdir
> gdb_load ${binfile}
> 
> gdb_begin "" "Breakpoint \[0-9\]+ at .*null_record.adb.*"
> 
> gdb_test "ptype empty" \
>          "type = record null; end record" \
>          "ptype on null record"
> >>
> 
> What do you think?

The test itself looks sane.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

Hello Daniel,

I think I am starting to slooooowly understand how this is all supposed
to work. Would you mind reviewing what I have done so far, though, to
see if I am heading in the right direction. I modified some files in
dejagnu (used the CVS version from src), modified gdb.exp in gdb/.../lib,
and added some others.

First, some answers to your previous questions:

> > gnatmake will. For instance gnatmake won't recompile the test programs
> > on subsequent runs, unless the sources have changes. Or if we have two
> > test programs depending on the same unit, this unit will only be compiled
> > once. I think we should keep them, they are useful.
> 
> Well, I'm not so sure that qualifies as useful for the testsuite, but
> if they go into gdb.ada I don't care :)

Great :)

> > proc gdb_begin {args expected_output} {
> >    gdb_test "begin $args" "$expected_output" "begin command"
> > }
> 
> What's begin do again in your sources?  Also, I'm not sure about the
> need for an ada.exp; what else do you expet to go here?

"begin" is the Ada equivalent of the "break main; run" sequence in
C. Basically, the main function in Ada is not necessarily called main.
In fact, it is almost always never called main. The "begin" command
digs into an Ada executable, finds the function name of the main
routine, puts a temporary breakpoint inside it, and then "run".

proc "gdb_begin" is designed to be the equivalent of "runto_main"
for C and C++.

So far, I don't anticipate anything else in ada.exp, but my little
finger tells me that we will likely need something else one day which
will fit perfectly into that file. Perhaps even our new gdb_compile_ada
procedure should be placed into this file?  I am perfectly happy to put
this proc in gdb.exp, however, and drop the idea of a new ada.exp file.

> Aye.  You can put find_gnatmake in gdb.exp for now and submit it to
> dejagnu later.
> 
> The basic goals of the function are:
>   - Find an in-tree gnatmake and pass it appropriate options to run
>     from in-tree, for testing a combined tree.
>   - Use [transform], which will supply the appropriate cross prefixes.

OK, here is how I understand thigs should be implemented to add support
for Ada.

  - In libgloss.exp, I need to add a new function "find_gnatmake"

<<
+proc find_gnatmake {} {
+    global tool_root_dir
+
+    set root "$tool_root_dir/gcc"
+    set GM ""
+
+    if ![is_remote host] {
+        set file [lookfor_file $root gnatmake]
+        if { $file != "" } {
+            set GM "$file -I$root/ada/rts --GCC=$root/xgcc --GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs --GCC=$root/xgcc -margs";
+        }
+    }
+
+    if {$GM == ""} {
+        set GM [transform gnatmake]
+    }
+
+    return $GM
+}
+
>>

  - In target.exp (default_target_compile): I need to add handling of
    Ada sources via the "ada" option keyword:

<<
@@ -333,6 +333,19 @@ proc default_target_compile {source dest
     }
 
     foreach i $options {
+       if { $i == "ada" } {
+           set compiler_type "ada"
+           if [board_info $dest exists gnatmakeflags] {
+               append add_flags " [target_info gnatmakeflags]"
+           }
+           # append add_flags " [gnatmake_include_flags]";
+           if [board_info $dest exists gnatmakecompiler] {
+               set compiler [target_info gnatmakecompiler];
+           } else {
+               set compiler [find_gnatmake];
+           }
+       }
+
        if { $i == "c++" } {
            set compiler_type "c++"
            if [board_info $dest exists cxxflags] {
@@ -412,6 +425,7 @@ proc default_target_compile {source dest
     global CC_FOR_TARGET
     global CXX_FOR_TARGET
     global F77_FOR_TARGET
+    global GNATMAKE_FOR_TARGET
     
     if [info exists CC_FOR_TARGET] {
        if { $compiler == "" } {
@@ -428,6 +442,12 @@ proc default_target_compile {source dest
     if [info exists F77_FOR_TARGET] {
        if { $compiler_type == "f77" } {
            set compiler $F77_FOR_TARGET
+       }
+    }
+
+    if [info exists GNATMAKE_FOR_TARGET] {
+       if { $compiler_type == "ada" } {
+           set compiler $GNATMAKE_FOR_TARGET
        }
     }
>> 

Then my new gdb_compile_ada function in gdb.exp simply becomes:

<<
proc gdb_compile_ada {source dest objdir type options} {

    append options " ada"
    append options " additional_flags=-P${objdir}/gnat_ada"

    set result [target_compile $source $dest $type $options]

    # Make sure that the dest file has been created.  Otherwise,
    # the build has failed.
    if ![file exists $dest] {
        verbose "Ada compilation failed: $result"
        return "Ada compilation failed."
    }
}
>>

And a simple testcase checking the null record problem is gone:

<<
if $tracelevel then {
    strace $tracelevel
}

load_lib "ada.exp"

set testfile "null_record"
set srcfile ${testfile}.adb
set binfile ${objdir}/${subdir}/${testfile}

if {[gdb_compile_ada "${srcfile}" "${binfile}" "${objdir}/${subdir}" executable [list debug ]] != "" } {
  return -1
}

gdb_exit
gdb_start
gdb_reinitialize_dir $srcdir/$subdir
gdb_load ${binfile}

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

gdb_test "ptype empty" \
         "type = record null; end record" \
         "ptype on null record"
>>

What do you think?

Thanks a lot for you help, Daniel,
-- 
Joel

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

Thank you very much for your very helpful comments, Daniel!

> OK; any interest in breaking out the language-independent bits of this
> feature for review and discussion?  While it's pretty uninteresting for
> C/C++, it should work there.  For Java and Fortran this could be
> useful, since they also have the concept of a main program.  At least
> GCJ does, I'm not sure about Java in general.

Sure. I'll make a note of starting a new thread about this. I think it
will be useful even in C. Using "begin" is shorter than doing "tbreak
main; run" (although one can use a user-defined function, true).

> By the way, there's a problem with gdb_begin: it can only be used once
> because it counts as a PASS/FAIL with a specific hardcoded name.  It
> should either not be a test, or more likely, should have a unique name.

True (but one could argue that runto_main has the same problem, right?  :-)
We can add an extra optional parameter (to be used only when this
function is used more than once in a given testcase), but...

> At that point, why have a procedure for it?  You're just passing its
> arguments to gdb_test.

... that would not be necessary if we decide that it's not worth
creating this new function. Indeed, it is just as simple to call
gdb_test directly. Except that I just remembered that there are cases
where we will need to pass an argument to the begin command [1].

I know of only one system (VxWorks) where this is extra parameter
is necessary. On this system, and with GNAT, the extra parameter is
identical to the name of the executable (ie we've decided that the entry
point name would be identical to the name of main procedure).  So I
think we eventually want gdb_begin to be intelligent enough to compute
the name of the entry-point, and then fill in the extra parameter
automatically. I haven't thought this through yet, but I see one way of
doing it:

proc gdb_begin {entry_point expected_output opt_id} {
   set begin_command "begin"

   if [is_remote host] {
       if [istarget "*-*-vxworks*"] {
           # The VxWorks debugger requires that we provide the name of
           # the entry-point in the module we want to debug.
           set begin_command "$begin_command $entry_point"
       }
   }

   gdb_test "begin $entry_point" "$expected_output" "begin command $opt_id"
}

As I don't see any supported platform where this would be necessary yet,
I simply suggest that we keep the original gdb_begin procedure,
but with an extra comment inside saying that we expect that this
function might eventually be upgraded to support certain more tricky
cases such as remote-debugging on VxWorks targets for instance (and with
an extra optional parameter to address the issue you raised above).
In the meantime, this function allows us to track all calls to the
"begin" command.

Sounds fair?

> > So far, I don't anticipate anything else in ada.exp, but my little
> > finger tells me that we will likely need something else one day which
> > will fit perfectly into that file. Perhaps even our new gdb_compile_ada
> > procedure should be placed into this file?  I am perfectly happy to put
> > this proc in gdb.exp, however, and drop the idea of a new ada.exp file.
> 
> I'm perfectly happy with it in ada.exp.  If we do that, let's put
> gdb_compile_ada there also.

OK, will move the function there if we agree on keeping gdb_begin.
Which will eventually have to be moved to gdb.exp if we later agree
on implementing the begin command for all languages :-).

> >   - In libgloss.exp, I need to add a new function "find_gnatmake"
> > 
> > <<
> > +proc find_gnatmake {} {
> > +    global tool_root_dir
> > +
> > +    set root "$tool_root_dir/gcc"
> > +    set GM ""
> > +
> > +    if ![is_remote host] {
> > +        set file [lookfor_file $root gnatmake]
> > +        if { $file != "" } {
> > +            set GM "$file -I$root/ada/rts --GCC=$root/xgcc --GNATBIND=$root/gnatbind --GNATLINK=$root/gnatlink -cargs -B$root -largs --GCC=$root/xgcc -margs";
> > +        }
> > +    }
> > +
> > +    if {$GM == ""} {
> > +        set GM [transform gnatmake]
> > +    }
> > +
> > +    return $GM
> > +}
> > +
> > >>
> 
> Looks plausible to me.  Note, we could also put this in ada.exp.  TCL
> doesn't much care.  But if you'll need changes to dejagnu anyway then
> libgloss.exp is probably the right place; I hadn't noticed this next
> bit:
> 
> >   - In target.exp (default_target_compile): I need to add handling of
> >     Ada sources via the "ada" option keyword:
> > 
> > <<
> > @@ -333,6 +333,19 @@ proc default_target_compile {source dest
> >      }
> >  
> >      foreach i $options {
> > +       if { $i == "ada" } {
> > +           set compiler_type "ada"
> > +           if [board_info $dest exists gnatmakeflags] {
> > +               append add_flags " [target_info gnatmakeflags]"
> > +           }
> > +           # append add_flags " [gnatmake_include_flags]";
> > +           if [board_info $dest exists gnatmakecompiler] {
> > +               set compiler [target_info gnatmakecompiler];
> > +           } else {
> > +               set compiler [find_gnatmake];
> > +           }
> > +       }
> > +
> >         if { $i == "c++" } {
> >             set compiler_type "c++"
> >             if [board_info $dest exists cxxflags] {
> 
> How would you feel about adaflags and adacompiler instead, for parallel
> with the other languages?  Maybe adaflags and gnatmake, since gnatmake
> isn't strictly speaking the "compiler".

I am happy with "adaflags", but as you have guessed, I'm a bit
relunctant with "adacompiler". I like "gnatmake" better than
"gnatmakecompiler" (yeeewww!). Maybe "adamake"?

> > @@ -412,6 +425,7 @@ proc default_target_compile {source dest
> >      global CC_FOR_TARGET
> >      global CXX_FOR_TARGET
> >      global F77_FOR_TARGET
> > +    global GNATMAKE_FOR_TARGET
> >      
> >      if [info exists CC_FOR_TARGET] {
> >         if { $compiler == "" } {
> > @@ -428,6 +442,12 @@ proc default_target_compile {source dest
> >      if [info exists F77_FOR_TARGET] {
> >         if { $compiler_type == "f77" } {
> >             set compiler $F77_FOR_TARGET
> > +       }
> > +    }
> > +
> > +    if [info exists GNATMAKE_FOR_TARGET] {
> > +       if { $compiler_type == "ada" } {
> > +           set compiler $GNATMAKE_FOR_TARGET
> >         }
> >      }
> > >> 
> 
> Looks good... these bits will of course have to go to dejagnu@gnu.org
> once you have something working.  I'd prefer to find a way to bail out
> gracefully if the host DejaGNU doesn't have them, too.  We can use
> [info proc find_gnatmake] for that, in gdb_compile_ada.

It sounded like a good idea, and I added the following check.

    if ![info proc find_gnatmake] {
        # If the version of dejagnu being used does not provide
        # procedure find_gnatmake, then we know the build will fail.
        # Better to bail out gracefully now rather than having
        # dejagnu abort the entire run later when it finds it needs
        # this procedure but can't find it.
        verbose "find_gnatmake procedure not found. Update dejagnu?"
        return "Ada compilation failed: find_gnatmake procedure not found."
    }

However, since find_gnatmake will only be called iff target_compile
(which is in dejagnu:target.exp) is upgraded to recognize the "ada"
option keyword. Otherwise, I've tried it, it defaults to using gcc.
And the gdb_compile_ada then fails without aborting the entire
testsuite run. So it looks like we can do without the extra check.

> > Then my new gdb_compile_ada function in gdb.exp simply becomes:
> > 
> > <<
> > proc gdb_compile_ada {source dest objdir type options} {
> > 
> >     append options " ada"
> >     append options " additional_flags=-P${objdir}/gnat_ada"
> > 
> >     set result [target_compile $source $dest $type $options]
> > 
> >     # Make sure that the dest file has been created.  Otherwise,
> >     # the build has failed.
> 
> Please mention explicitly that gnatmake produces output even if
> successful.

Good idea. I just addded:

    # The Ada build always produces some output, even when the build
    # succeeds. Thus, we can not use the output the same way we do in
    # gdb_compile to determine whether the build has succeeded or not.
    # We therefore simply check whether the dest file has been created
    # or not. Unless not present, the build has succeeded.


> The test itself looks sane.

Cool! :-)

Thanks again, Daniel.

-- 
Joel

[1] At least on VxWorks, the user needs to provide the name of the
    entry-point into the "executable" (aka "module") he wants to run.
    This allow GDB to tell the target where to start the execution of
    the inferior from. The extra argument is also necessary for the
    "run" command too.

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Daniel Jacobowitz]

On Thu, Mar 04, 2004 at 10:03:22PM -0800, Joel Brobecker wrote:
> Thank you very much for your very helpful comments, Daniel!
> 
> > OK; any interest in breaking out the language-independent bits of this
> > feature for review and discussion?  While it's pretty uninteresting for
> > C/C++, it should work there.  For Java and Fortran this could be
> > useful, since they also have the concept of a main program.  At least
> > GCJ does, I'm not sure about Java in general.
> 
> Sure. I'll make a note of starting a new thread about this. I think it
> will be useful even in C. Using "begin" is shorter than doing "tbreak
> main; run" (although one can use a user-defined function, true).
> 
> > By the way, there's a problem with gdb_begin: it can only be used once
> > because it counts as a PASS/FAIL with a specific hardcoded name.  It
> > should either not be a test, or more likely, should have a unique name.
> 
> True (but one could argue that runto_main has the same problem, right?  :-)

No.  Take a look at the implementation of runto; it does not issue a
PASS if it messes up.  It does issue a fixed fail message but the
expectation is that you'll bail out of the test script if that happens.

> We can add an extra optional parameter (to be used only when this
> function is used more than once in a given testcase), but...
> 
> > At that point, why have a procedure for it?  You're just passing its
> > arguments to gdb_test.
> 
> ... that would not be necessary if we decide that it's not worth
> creating this new function. Indeed, it is just as simple to call
> gdb_test directly. Except that I just remembered that there are cases
> where we will need to pass an argument to the begin command [1].
> 
> I know of only one system (VxWorks) where this is extra parameter
> is necessary. On this system, and with GNAT, the extra parameter is
> identical to the name of the executable (ie we've decided that the entry
> point name would be identical to the name of main procedure).  So I
> think we eventually want gdb_begin to be intelligent enough to compute
> the name of the entry-point, and then fill in the extra parameter
> automatically. I haven't thought this through yet, but I see one way of
> doing it:
> 
> proc gdb_begin {entry_point expected_output opt_id} {
>    set begin_command "begin"
> 
>    if [is_remote host] {
>        if [istarget "*-*-vxworks*"] {
>            # The VxWorks debugger requires that we provide the name of
>            # the entry-point in the module we want to debug.
>            set begin_command "$begin_command $entry_point"
>        }
>    }
> 
>    gdb_test "begin $entry_point" "$expected_output" "begin command $opt_id"
> }
> 
> As I don't see any supported platform where this would be necessary yet,
> I simply suggest that we keep the original gdb_begin procedure,
> but with an extra comment inside saying that we expect that this
> function might eventually be upgraded to support certain more tricky
> cases such as remote-debugging on VxWorks targets for instance (and with
> an extra optional parameter to address the issue you raised above).
> In the meantime, this function allows us to track all calls to the
> "begin" command.
> 
> Sounds fair?

I would like to discuss the meaning of begin separately.  You haven't
told me what the parameter is; what GDB uses it for; or why providing
something other than the name of the entry point would be useful. 
Since if it isn't useful, GDB should take care of this itself on
vxworks for a uniform command syntax.

> I am happy with "adaflags", but as you have guessed, I'm a bit
> relunctant with "adacompiler". I like "gnatmake" better than
> "gnatmakecompiler" (yeeewww!). Maybe "adamake"?

Let's stick to gnatmake.  If someday (unlikely, but hey...) DejaGNU is
used to test some other Ada compiler, I bet it won't have a foomake
that takes gnatmake arguments.

> It sounded like a good idea, and I added the following check.
> 
>     if ![info proc find_gnatmake] {
>         # If the version of dejagnu being used does not provide
>         # procedure find_gnatmake, then we know the build will fail.
>         # Better to bail out gracefully now rather than having
>         # dejagnu abort the entire run later when it finds it needs
>         # this procedure but can't find it.
>         verbose "find_gnatmake procedure not found. Update dejagnu?"
>         return "Ada compilation failed: find_gnatmake procedure not found."
>     }
> 
> However, since find_gnatmake will only be called iff target_compile
> (which is in dejagnu:target.exp) is upgraded to recognize the "ada"
> option keyword. Otherwise, I've tried it, it defaults to using gcc.
> And the gdb_compile_ada then fails without aborting the entire
> testsuite run. So it looks like we can do without the extra check.

But it will fail messily after trying to use GCC to compile Ada source,
right?  That's what I want to avoid.

> [1] At least on VxWorks, the user needs to provide the name of the
>     entry-point into the "executable" (aka "module") he wants to run.
>     This allow GDB to tell the target where to start the execution of
>     the inferior from. The extra argument is also necessary for the
>     "run" command too.

Ooh, an explanatory footnote.  I missed that.  I understand why this
might be, but is it ever useful to the user to provide something other
than the normal, debug-info-specified entry point?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

Hello Daniel,

I am finally taking the time to come back to this discussion. Sorry
about the long delay, I imagine that things have become a bit foggy
for you.

I re-read the entire thread, and I think I can say this:
  - you said that the changes to dejagnu itself looked reasonable to you.
    So I'll submit them to the dejagnu maintainers.
  - There was only one remaining issue with the "begin" command
    (Ada-only for now, but might become available in all languages
    sometime in the future - I will take care of that). I will
    start a new thread with a summary of what has been said and
    try to answer your questions.
  - The first Ada test looked sane :-). So I suggest we work on adding
    a first version of the test without the currently-under-discussion
    gdb_begin function.

Cheers,
-- 
Joel

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Daniel Jacobowitz]

On Fri, Mar 26, 2004 at 03:42:55PM -0800, Joel Brobecker wrote:
> Hello Daniel,
> 
> I am finally taking the time to come back to this discussion. Sorry
> about the long delay, I imagine that things have become a bit foggy
> for you.
> 
> I re-read the entire thread, and I think I can say this:
>   - you said that the changes to dejagnu itself looked reasonable to you.
>     So I'll submit them to the dejagnu maintainers.

You may want to put them in both DejaGNU and somewhere under
gdb/testsuite/lib for now, once you get some feedback from the DejaGNU
maintainers; we don't want to unnecessarily bump the DejaGNU version
requirement.

>   - There was only one remaining issue with the "begin" command
>     (Ada-only for now, but might become available in all languages
>     sometime in the future - I will take care of that). I will
>     start a new thread with a summary of what has been said and
>     try to answer your questions.
>   - The first Ada test looked sane :-). So I suggest we work on adding
>     a first version of the test without the currently-under-discussion
>     gdb_begin function.

Sounds good!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada

[Joel Brobecker]

> >   - you said that the changes to dejagnu itself looked reasonable to you.
> >     So I'll submit them to the dejagnu maintainers.
> 
> You may want to put them in both DejaGNU and somewhere under
> gdb/testsuite/lib for now, once you get some feedback from the DejaGNU
> maintainers; we don't want to unnecessarily bump the DejaGNU version
> requirement.

I am discovering the wonderful properties of TCL everyday :-).
How about I put the modified version of default_target_compile and
also the new find_gnatmake functions in lib/ada.exp with a comment
explaining that we're trying to get them integrated into dejagnu.
Putting them in ada.exp allows us to shield all the other tests from
this hack.

-- 
Joel