From: Daniel Jacobowitz <drow@false.org>
To: Joel Brobecker <brobecker@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada
Date: Fri, 05 Mar 2004 04:18:00 -0000 [thread overview]
Message-ID: <20040305041814.GI5320@nevyn.them.org> (raw)
In-Reply-To: <20040303042107.GB1146@gnat.com>
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
WARNING: multiple messages have this Message-ID
From: Daniel Jacobowitz <drow@false.org>
To: Joel Brobecker <brobecker@gnat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFC/RFA] (testsuite/Ada) Add gdb_compile_ada
Date: Fri, 19 Mar 2004 00:09:00 -0000 [thread overview]
Message-ID: <20040305041814.GI5320@nevyn.them.org> (raw)
Message-ID: <20040319000900.NsUZOKh_phixwZrE62fvqca1D_LoRlT-8RQf9Yh8kJQ@z> (raw)
In-Reply-To: <20040303042107.GB1146@gnat.com>
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
next prev parent reply other threads:[~2004-03-05 4:18 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-02-24 19:56 Joel Brobecker
2004-02-24 22:40 ` Joel Brobecker
2004-02-24 23:08 ` Joel Brobecker
2004-02-25 18:32 ` Joel Brobecker
2004-02-25 20:17 ` Daniel Jacobowitz
2004-02-26 22:37 ` Joel Brobecker
2004-02-26 23:02 ` Daniel Jacobowitz
2004-03-19 0:09 ` Joel Brobecker
2004-03-03 4:21 ` Joel Brobecker
2004-03-05 4:18 ` Daniel Jacobowitz [this message]
2004-03-05 6:03 ` Joel Brobecker
2004-03-05 16:48 ` Daniel Jacobowitz
2004-03-19 0:09 ` Daniel Jacobowitz
2004-03-26 23:42 ` Joel Brobecker
2004-03-26 23:46 ` Daniel Jacobowitz
2004-03-27 0:07 ` Joel Brobecker
2004-03-19 0:09 ` Joel Brobecker
2004-03-19 0:09 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040305041814.GI5320@nevyn.them.org \
--to=drow@false.org \
--cc=brobecker@gnat.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox