From: Carl Love <cel@linux.ibm.com>
To: Keith Seitz <keiths@redhat.com>, tromey@adacore.com, cel@us.ibm.com
Cc: gdb-patches@sourceware.org
Subject: Re: Ada compile with -fvar-tracking
Date: Wed, 15 Nov 2023 14:59:56 -0800 [thread overview]
Message-ID: <d9c8c4bd7c49755fcc570db39f209a9ff81f3169.camel@linux.ibm.com> (raw)
In-Reply-To: <6eed52fac162f4082974fb71580a938059bdc4ef.camel@linux.ibm.com>
Keith, Tom:
Well, fortunately debugging the expect script went fairly fast. I did
find the error. There are a million ways to shoot yourself in the foot
and I found yet another way... :-)
This is actually rather educational.
Starting with the patch...
--- a/gdb/testsuite/gdb.ada/finish-large.exp
+++ b/gdb/testsuite/gdb.ada/finish-large.exp
@@ -19,7 +19,9 @@ require allow_ada_tests
standard_ada_testfile p
-if {[gdb_compile_ada "${srcfile}" "${binfile}" executable debug] !=
""} {
+set flags {debug additional_flags=-cargs additional_flags=-fvar-
tracking additional_flags=-margs}
+
+if {[gdb_compile_ada "${srcfile}" "${binfile} " executable $flags] !=
""} {
return -1
}
If you notice in the new line we have "${binfile} ", notice the space
before the closing quote. That is the root cause of the compilation
failing!!
So looking at gdb/testsuite/lib/ada.exp we have
proc gdb_compile_ada {source dest type options} {
set result [gdb_compile_ada_1 $source $dest $type $options]
gdb_compile_test $source $result
return $result
}
Note, gdb_compile_test expects $result to be empty. If not it will be
interpreted as a compile failure.
So the second argument "${binfile} " is passed in as dest which is
passed to gdb_compile_ada_1. There is a very interesting comment at
the bottom of proc gdb_compile_ada_1.
proc gdb_compile_ada_1 {source dest type options} {
set srcdir [file dirname $source]
set gprdir [file dirname $srcdir]
set objdir [file dirname $dest]
file delete $dest
# Although strictly not necessary, we force the recompilation
# of all units (additional_flags=-f). This is what is done
# when using GCC to build programs in the other languages,
# and it avoids using a stray objfile file from a long-past
# run, for instance.
append options " ada"
if {[lsearch -exact $options no-force] == -1} {
append options " additional_flags=-f"
}
append options " additional_flags=-I$srcdir"
set result [target_compile_ada_from_dir \
$objdir [file tail $source] $dest $type $options]
# 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.
puts "CARLL, dest = $dest.\n" ##Carl added this for debugging
if [file exists $dest] { set result "" }
return $result
}
So we have a test to see if file $dest exists or not. Well initially
with out my patch the value of $dest is printed by my debugging
statemet as
CARLL, dest = /home/carll/GDB/build-ada/gdb/testsuite/outputs/gdb.ada/finish-large/p.
The file exists so $result is cleared and gdb_compile_test sees and
empty and thus the compile succeeds.
However, that extra space in my patch file argument "${binfile} "
results in the value of $dest being:
CARLL, dest = /home/carll/GDB/build-ada/gdb/testsuite/outputs/gdb.ada/finish-large/p .
Again, note the space after p and before the period. Well the if [file
exists $dest] fails for this file name. Apparently it thinks the extra
space is a valid file name character so result is not cleared and
gdb_compile_test reports the compile failed.
So by removing that extra space in my original patch, the test now
compiles and passes since the DW_TAG_call_site information is available
so gdb can determine what the value of r3 was on entry to the test
program function.
Thanks to Tom for helping get the correct options passed to the ada
compiler to get the -fvar-tracking option to work. I am sure I didn't
have the additional arguments when I initially worked on this.
So, with the fixed patch test finish-large.exp works. There are a
couple other tests that I think will need the same fix to enable the
-fvar-tracking since the functions return a structure. Will have to
look at them next.
Thanks to both of you for your help with this.
Carl
next prev parent reply other threads:[~2023-11-15 23:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-14 19:24 Carl Love
2023-11-14 19:40 ` Tom Tromey
2023-11-14 21:17 ` Carl Love
2023-11-14 22:03 ` Tom Tromey
2023-11-14 22:23 ` Carl Love
2023-11-15 15:04 ` Tom Tromey
2023-11-15 16:42 ` Carl Love
2023-11-15 17:02 ` Tom Tromey
2023-11-15 17:12 ` Carl Love
2023-11-15 17:23 ` Keith Seitz
2023-11-15 17:29 ` Carl Love
2023-11-15 22:59 ` Carl Love [this message]
2023-11-16 14:02 ` Luis Machado
2023-11-16 16:11 ` Carl Love
2023-11-16 21:07 ` Tom Tromey
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=d9c8c4bd7c49755fcc570db39f209a9ff81f3169.camel@linux.ibm.com \
--to=cel@linux.ibm.com \
--cc=cel@us.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=keiths@redhat.com \
--cc=tromey@adacore.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