public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
* Ada compile with -fvar-tracking
@ 2023-11-14 19:24 Carl Love
  2023-11-14 19:40 ` Tom Tromey
  0 siblings, 1 reply; 15+ messages in thread
From: Carl Love @ 2023-11-14 19:24 UTC (permalink / raw)
  To: Tom Tromey, cel, gdb-patches

Tom:

Per our conversation on HexChat about using -fvar-tracking when
compiling Ada programs.

I tried adding the -fvar-tracking option based on the examples we
talked about.  Here are the changes I used:


gdb/testsuite/gdb.ada/finish-large.exp | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.ada/finish-large.exp b/gdb/testsuite/gdb.ada/finish-large.exp
index 5661d132a18..affb2a497fa 100644
--- a/gdb/testsuite/gdb.ada/finish-large.exp
+++ b/gdb/testsuite/gdb.ada/finish-large.exp
@@ -19,7 +19,12 @@ require allow_ada_tests
 
 standard_ada_testfile p
 
-if {[gdb_compile_ada "${srcfile}" "${binfile}" executable debug] != ""} {
+set additional_flags {}
+
+set flags [list debug additional_flags=-fvar-tracking]
+
+if {[gdb_compile_ada "${srcfile}" "${binfile} " executable $flags] != ""} {
+
   return -1
 }

When I try to run the test with:

   make check RUNTESTFLAGS='GDB=/home/carll/bin/gdb gdb.ada/finish-large.exp ' > out

I get the following, edited a little to make it easier to read, in 
gdb/testsuite/gdb.log:

   Executing on host: gnatmake  p.adb  -largs  -margs  -fvar-tracking -f 
   -I/home/.../gdb/testsuite/gdb.ada/finish-large -g -largs  -lm  -margs -o /.../gdb/testsuite

   compilation failed: gcc -c -I./ -fvar-tracking -I/.../gdb/testsuite/gdb.ada/finish-large -g 
   -I- /.../testsuite/gdb.ada/finish-large/p.adb

   gcc -c -I./ -fvar-tracking -I/..../gdb/testsuite/gdb.ada/finish-large -g -I- 
   /.../gdb/testsuite/gdb.ada/finish-large/pck.adb

   gnatbind -I/..../gdb/testsuite/gdb.ada/finish-large -x p.ali

   gnatlink p.ali -fvar-tracking -g -lm -o /..../gdb/testsuite/outputs/gdb.ada/finish-large/p

   FAIL: gdb.ada/finish-large.exp: compilation p.adb

If I remove the "additional_flags=-fvar-tracking" from the flags line,
i.e.

     set flags [list debug additional_flags=""]

Then the test compiles and runs as before.  So, I still don't seem to
be able to get Ada to take the -fvar-tracking option.  I just seem to
get a compilation error which I guess is due to the compiler not
recognizing "-fvar-tracking".  Thoughts?

Thanks for the time and effort on this.

                          Carl 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-14 19:24 Ada compile with -fvar-tracking Carl Love
@ 2023-11-14 19:40 ` Tom Tromey
  2023-11-14 21:17   ` Carl Love
  0 siblings, 1 reply; 15+ messages in thread
From: Tom Tromey @ 2023-11-14 19:40 UTC (permalink / raw)
  To: Carl Love; +Cc: Tom Tromey, gdb-patches

>>>>> "Carl" == Carl Love <cel@linux.ibm.com> writes:

Carl> Per our conversation on HexChat about using -fvar-tracking when
Carl> compiling Ada programs.

Carl> I tried adding the -fvar-tracking option based on the examples we
Carl> talked about.  Here are the changes I used:

Carl> +set flags [list debug additional_flags=-fvar-tracking]

Yeah, I played with it a bit and came up with the non-obvious:

set flags {debug additional_flags=-cargs additional_flags=-fvar-tracking additional_flags=-margs}

which I guess would be prettier wrapped in a proc or some kind of
mapping thing.

Tom

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-14 19:40 ` Tom Tromey
@ 2023-11-14 21:17   ` Carl Love
  2023-11-14 22:03     ` Tom Tromey
  2023-11-16 14:02     ` Luis Machado
  0 siblings, 2 replies; 15+ messages in thread
From: Carl Love @ 2023-11-14 21:17 UTC (permalink / raw)
  To: Tom Tromey; +Cc: gdb-patches, cel

Tom:

On Tue, 2023-11-14 at 12:40 -0700, Tom Tromey wrote:
> set flags {debug additional_flags=-cargs additional_flags=-fvar-
> tracking additional_flags=-margs}

So I put that in as follows:

   set flags {debug additional_flags=-cargs additional_flags=-fvar-tracking additional_flags=-margs}

   if {[gdb_compile_ada "${srcfile}" "${binfile} " executable $flags] != ""} {

     return -1
   }

I still get: 

   compilation failed: gcc -c -I./ -fvar-tracking -I/..../testsuite/gdb.ada/finish-large -g -I- 
   /..../testsuite/gdb.ada/finish-large/p.adb

Unfortunately "compilation failed" doesn't tell me much.  So I tried
cutting and pasting each of the compile lines out of the log file and
doing them by hand to see if I could get any more info or figure out
exactly where it fails.  It looks like there are four commands that get
issued:

   gcc -c -I./ -fvar-tracking -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -g -I- /home/carll/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large/p.adb

   gcc -c -I./ -fvar-tracking -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -g -I- /home/carll/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large/pck.adb

   gnatbind -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -x p.ali

   gnatlink p.ali -g -lm -o /home/carll/GDB/build-ada/gdb/testsuite/outputs/gdb.ada/finish-large/p

Well, I can issue each one by hand and don't get any errors.

So then I ran "readelf -wi on /home/carll/GDB/build-
ada/gdb/testsuite/outputs/gdb.ada/finish-large/p.  When I look at the
dwarf output, I see the DW_TAG_call_site tags that are needed and were
not there without the -fvar-tracking stuff. 

So, there is something in the environment or ??? that is causing the
compilation to fail???  It does look like it is theoretically possible
to get Ada to generate the DW_TAG_call_site tags.  Maybe something in
dejagnu?  No clue.  If you have any thoughts or suggestions on
debugging dejagnu that would be great.  

Thanks again.

                          Carl




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-14 21:17   ` Carl Love
@ 2023-11-14 22:03     ` Tom Tromey
  2023-11-14 22:23       ` Carl Love
  2023-11-16 14:02     ` Luis Machado
  1 sibling, 1 reply; 15+ messages in thread
From: Tom Tromey @ 2023-11-14 22:03 UTC (permalink / raw)
  To: Carl Love; +Cc: Tom Tromey, gdb-patches

>>>>> "Carl" == Carl Love <cel@linux.ibm.com> writes:

Carl> I still get: 

Carl>    compilation failed: gcc -c -I./ -fvar-tracking -I/..../testsuite/gdb.ada/finish-large -g -I- 
Carl>    /..../testsuite/gdb.ada/finish-large/p.adb

Carl> Unfortunately "compilation failed" doesn't tell me much.

Yeah... I don't know what's happening.  This worked for me.

Can you send the relevant text from gdb.log?  Or even the whole thing
(from just that one .exp)?  Maybe there's something in there.

Carl> So, there is something in the environment or ??? that is causing the
Carl> compilation to fail???

Really shouldn't be AFAIK.

Tom

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-14 22:03     ` Tom Tromey
@ 2023-11-14 22:23       ` Carl Love
  2023-11-15 15:04         ` Tom Tromey
  0 siblings, 1 reply; 15+ messages in thread
From: Carl Love @ 2023-11-14 22:23 UTC (permalink / raw)
  To: Tom Tromey, gdb-patches; +Cc: cel

Tom:

I have attached the patch, followed by the entire log file.  Hopefully
you can see something I am missing.  Thanks for the help.

                     Carl 
---------------------------------------------
[PATCH] tom suggestion

Gives compile failed
---
 gdb/testsuite/gdb.ada/finish-large.exp | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.ada/finish-large.exp b/gdb/testsuite/gdb.ada/finish-large.exp
index 5661d132a18..d15697042a8 100644
--- 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
 }
 
-- 
2.41.0

-------------------------------------------------------------
Test run by carll on Tue Nov 14 17:17:50 2023
Native configuration is powerpc64le-unknown-linux-gnu

		=== gdb tests ===

Schedule of variations:
    unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using /home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file.
Running /home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large.exp ...
Executing on build: rm -rf /home/carll/GDB/build-ada/gdb/testsuite/outputs/gdb.ada/finish-large    (timeout = 300)
builtin_spawn -ignore SIGHUP rm -rf /home/carll/GDB/build-ada/gdb/testsuite/outputs/gdb.ada/finish-large
Switching to directory /home/carll/GDB/build-ada/gdb/testsuite/outputs/gdb.ada/finish-large (saved CWD: /home/carll/GDB/build-ada/gdb/testsuite).
Executing on host: gnatmake  p.adb  -largs  -margs  -cargs -fvar-tracking -margs -f -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -g -largs  -lm  -margs -o /home/carll/GDB/build-ada/gdb/testsuite/outputs/gdb.ada/finish-large/p     (timeout = 300)
builtin_spawn -ignore SIGHUP gnatmake p.adb -largs -margs -cargs -fvar-tracking -margs -f -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -g -largs -lm -margs -o /home/carll/GDB/build-ada/gdb/testsuite/outputs/gdb.ada/finish-large/p
gcc -c -I./ -fvar-tracking -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -g -I- /home/carll/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large/p.adb
gcc -c -I./ -fvar-tracking -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -g -I- /home/carll/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large/pck.adb
gnatbind -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -x p.ali
gnatlink p.ali -g -lm -o /home/carll/GDB/build-ada/gdb/testsuite/outputs/gdb.ada/finish-large/p
Switching back to /home/carll/GDB/build-ada/gdb/testsuite.
compilation failed: gcc -c -I./ -fvar-tracking -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -g -I- /home/carll/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large/p.adb
gcc -c -I./ -fvar-tracking -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -g -I- /home/carll/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large/pck.adb
gnatbind -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -x p.ali
gnatlink p.ali -g -lm -o /home/carll/GDB/build-ada/gdb/testsuite/outputs/gdb.ada/finish-large/p

FAIL: gdb.ada/finish-large.exp: compilation p.adb
testcase /home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large.exp completed in 0 seconds

		=== gdb Summary ===

# of unexpected failures	1
Executing on host: /home/carll/bin/gdb -nw -nx -q -iex "set height 0" -iex "set width 0" --version    (timeout = 300)
builtin_spawn -ignore SIGHUP /home/carll/bin/gdb -nw -nx -q -iex set height 0 -iex set width 0 --version
GNU gdb (GDB) 15.0.50.20231114-git
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
/home/carll/bin/gdb version  15.0.50.20231114-git -nw -nx -q -iex "set height 0" -iex "set width 0" 

runtest completed at Tue Nov 14 17:17:50 2023



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-14 22:23       ` Carl Love
@ 2023-11-15 15:04         ` Tom Tromey
  2023-11-15 16:42           ` Carl Love
  0 siblings, 1 reply; 15+ messages in thread
From: Tom Tromey @ 2023-11-15 15:04 UTC (permalink / raw)
  To: Carl Love; +Cc: Tom Tromey, gdb-patches

>>>>> "Carl" == Carl Love <cel@linux.ibm.com> writes:

Carl> I have attached the patch, followed by the entire log file.  Hopefully
Carl> you can see something I am missing.  Thanks for the help.

Well, it is definitely a mystery to me.

A pretty normal failure mode is that the compiler emits some warning or
something, and dejagnu thinks this is an error.  This doesn't seem to be
happening in your case.

Carl> compilation failed: gcc -c -I./ -fvar-tracking -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large -g -I- /home/carll/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large/p.adb

I wonder if this is exiting with a non-zero status.

It's hard to imagine what else it could be.  Like could there be a
message but dejagnu isn't putting it into the log?

What happens if you 'cd' into the appropriate subdir in the source tree
and invoke gnatmake yourself?  I think earlier you said this worked, but
it's good to start with a clean build tree (hence srcdir -- you can 'git
clean .' to nuke the build artifacts)

Tom

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-15 15:04         ` Tom Tromey
@ 2023-11-15 16:42           ` Carl Love
  2023-11-15 17:02             ` Tom Tromey
  0 siblings, 1 reply; 15+ messages in thread
From: Carl Love @ 2023-11-15 16:42 UTC (permalink / raw)
  To: Tom Tromey, cel; +Cc: gdb-patches

Tom:

On Wed, 2023-11-15 at 08:04 -0700, Tom Tromey wrote:
> > > > > > "Carl" == Carl Love <cel@linux.ibm.com> writes:
> 
> Carl> I have attached the patch, followed by the entire log
> file.  Hopefully
> Carl> you can see something I am missing.  Thanks for the help.
> 
> Well, it is definitely a mystery to me.
> 
> A pretty normal failure mode is that the compiler emits some warning
> or
> something, and dejagnu thinks this is an error.  This doesn't seem to
> be
> happening in your case.
> 
> Carl> compilation failed: gcc -c -I./ -fvar-tracking
> -I/home/carll/GDB/build-ada/gdb/testsuite/../../../binutils-gdb-
> ada/gdb/testsuite/gdb.ada/finish-large -g -I-
> /home/carll/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-
> large/p.adb
> 
> I wonder if this is exiting with a non-zero status.
> 
> It's hard to imagine what else it could be.  Like could there be a
> message but dejagnu isn't putting it into the log?
> 
> What happens if you 'cd' into the appropriate subdir in the source
> tree
> and invoke gnatmake yourself?  I think earlier you said this worked,
> but
> it's good to start with a clean build tree (hence srcdir -- you can
> 'git
> clean .' to nuke the build artifacts)

Some good ideas.  So, I cloned a clean copy and cd to the source
directory and then took each of the commands from the log file and ran
them with the appropriate input directory paths putting the output in
the current directory.  I then ran echo $? to see the exit code for
each command.  I didn't see any errors or warnings from any of the
commands.  The exit code was 0 for each command.  I then dumped the
dwarf on the binary and again verified that it now contains the
DW_TAG_call_site entries that are needed.  Yea, I was hoping I would
see a bad exit code that would give me a clue.

carll@ltcd97-lp3:~/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large$ gcc -I./  -fvar-tracking -c -I . -g -I- p.adb
carll@ltcd97-lp3:~/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large$ echo $?
0
carll@ltcd97-lp3:~/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large$ gcc -c -I./ -fvar-tracking -I/. -g -I- ./pck.adb
carll@ltcd97-lp3:~/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large$ echo $?
0
carll@ltcd97-lp3:~/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large$ gnatbind  -I. -x p.ali
carll@ltcd97-lp3:~/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large$ echo $?
0
carll@ltcd97-lp3:~/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large$ gnatlink p.ali -g -lm -o p
carll@ltcd97-lp3:~/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large$ echo $?
0
carll@ltcd97-lp3:~/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large$ readelf -wi p > p.dump
carll@ltcd97-lp3:~/GDB/binutils-gdb-ada/gdb/testsuite/gdb.ada/finish-large$ emacs p.dump
 
So, per my thoughts last night, I guess I need to dig into the expect
gdb_compile_ada proceedure and see if I can find something there. 

Please let me know if you come up with any other ideas.  Appreciate all
the time and efforts from you on this.

                             Carl 



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-15 16:42           ` Carl Love
@ 2023-11-15 17:02             ` Tom Tromey
  2023-11-15 17:12               ` Carl Love
  0 siblings, 1 reply; 15+ messages in thread
From: Tom Tromey @ 2023-11-15 17:02 UTC (permalink / raw)
  To: Carl Love; +Cc: Tom Tromey, gdb-patches

>>>>> "Carl" == Carl Love <cel@linux.ibm.com> writes:

Carl> So, per my thoughts last night, I guess I need to dig into the expect
Carl> gdb_compile_ada proceedure and see if I can find something there. 

I've occasionally even hacked logging ("verbose -log" is an easy way)
into dejagnu code to try to figure out what is going on.  I guess in a
tricky case like this I'd try to find the exact bit of code that's
deciding the compilation failed.

Tom

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-15 17:02             ` Tom Tromey
@ 2023-11-15 17:12               ` Carl Love
  2023-11-15 17:23                 ` Keith Seitz
  0 siblings, 1 reply; 15+ messages in thread
From: Carl Love @ 2023-11-15 17:12 UTC (permalink / raw)
  To: Tom Tromey, cel; +Cc: gdb-patches

Tom:

On Wed, 2023-11-15 at 10:02 -0700, Tom Tromey wrote:
> > > > > > "Carl" == Carl Love <cel@linux.ibm.com> writes:
> 
> Carl> So, per my thoughts last night, I guess I need to dig into the
> expect
> Carl> gdb_compile_ada proceedure and see if I can find something
> there. 
> 
> I've occasionally even hacked logging ("verbose -log" is an easy way)
> into dejagnu code to try to figure out what is going on.  I guess in
> a
> tricky case like this I'd try to find the exact bit of code that's
> deciding the compilation failed.

Yup, my thoughts exactly. It looks to me like there are four commands
that get issued to compile the testcase.  We need to narrow it down to
what command fails and exactly where in the dejagnu code it is issued
from and where the error is "detected".  I haven't debugged dejagnu
code in the past so this could be interesting.  I will look to see
about turning on vebose -log to see what I can get from it.  Thanks for
mentioning that.

                    Carl 



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-15 17:12               ` Carl Love
@ 2023-11-15 17:23                 ` Keith Seitz
  2023-11-15 17:29                   ` Carl Love
  0 siblings, 1 reply; 15+ messages in thread
From: Keith Seitz @ 2023-11-15 17:23 UTC (permalink / raw)
  To: Carl Love; +Cc: gdb-patches

On 11/15/23 09:12, Carl Love wrote:
> On Wed, 2023-11-15 at 10:02 -0700, Tom Tromey wrote:
>>>>>>> "Carl" == Carl Love <cel@linux.ibm.com> writes:
>>
>> Carl> So, per my thoughts last night, I guess I need to dig into the
>> expect
>> Carl> gdb_compile_ada proceedure and see if I can find something
>> there.
>>
>> I've occasionally even hacked logging ("verbose -log" is an easy way)
>> into dejagnu code to try to figure out what is going on.  I guess in
>> a
>> tricky case like this I'd try to find the exact bit of code that's
>> deciding the compilation failed.
> 
> Yup, my thoughts exactly. It looks to me like there are four commands
> that get issued to compile the testcase.  We need to narrow it down to
> what command fails and exactly where in the dejagnu code it is issued
> from and where the error is "detected".  I haven't debugged dejagnu
> code in the past so this could be interesting.  I will look to see
> about turning on vebose -log to see what I can get from it.  Thanks for
> mentioning that.

When it comes to debugging what expect is up to, if you can narrow
the problem(s) to a proc or small area of commands,  you can surround 
that bit of code with "exp_internal 1" and "exp_internal 0". This will 
cause expect to output all of its pattern-matching data: buffer 
contents, attempted matches, actual matches, etc.

[You can also globally turn on exp_internal by passing a verbosity
level of 2+ to dejagnu. That will output "dbg.log" with ALL expect
pattern matching logging. Far too verbose (usually) to be useful.]

Keith


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-15 17:23                 ` Keith Seitz
@ 2023-11-15 17:29                   ` Carl Love
  2023-11-15 22:59                     ` Carl Love
  0 siblings, 1 reply; 15+ messages in thread
From: Carl Love @ 2023-11-15 17:29 UTC (permalink / raw)
  To: Keith Seitz; +Cc: gdb-patches

Keth:

On Wed, 2023-11-15 at 09:23 -0800, Keith Seitz wrote:
> When it comes to debugging what expect is up to, if you can narrow
> the problem(s) to a proc or small area of commands,  you can
> surround 
> that bit of code with "exp_internal 1" and "exp_internal 0". This
> will 
> cause expect to output all of its pattern-matching data: buffer 
> contents, attempted matches, actual matches, etc.
> 
> [You can also globally turn on exp_internal by passing a verbosity
> level of 2+ to dejagnu. That will output "dbg.log" with ALL expect
> pattern matching logging. Far too verbose (usually) to be useful.]

Thanks!!  I think that will be very helpful to be able to fine tune the
debugging.

                  Carl 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-15 17:29                   ` Carl Love
@ 2023-11-15 22:59                     ` Carl Love
  0 siblings, 0 replies; 15+ messages in thread
From: Carl Love @ 2023-11-15 22:59 UTC (permalink / raw)
  To: Keith Seitz, tromey, cel; +Cc: gdb-patches

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 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-14 21:17   ` Carl Love
  2023-11-14 22:03     ` Tom Tromey
@ 2023-11-16 14:02     ` Luis Machado
  2023-11-16 16:11       ` Carl Love
  1 sibling, 1 reply; 15+ messages in thread
From: Luis Machado @ 2023-11-16 14:02 UTC (permalink / raw)
  To: Carl Love, Tom Tromey; +Cc: gdb-patches

On 11/14/23 21:17, Carl Love wrote:
> Tom:
> 
> On Tue, 2023-11-14 at 12:40 -0700, Tom Tromey wrote:
>> set flags {debug additional_flags=-cargs additional_flags=-fvar-
>> tracking additional_flags=-margs}
> 
> So I put that in as follows:
> 
>    set flags {debug additional_flags=-cargs additional_flags=-fvar-tracking additional_flags=-margs}

I guess one way to make the above slightly cleaner (debatable) is to append the additional flags on different lines:

    set flags {"debug"}
    lappend flags "additional_flags=-cargs"
    lappend flags "additional_flags=-fvar-tracking"
    lappend flags "additional_flags=-margs"

Slightly more verbose, but may make the additional flags more explicit/easier to read.

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-16 14:02     ` Luis Machado
@ 2023-11-16 16:11       ` Carl Love
  2023-11-16 21:07         ` Tom Tromey
  0 siblings, 1 reply; 15+ messages in thread
From: Carl Love @ 2023-11-16 16:11 UTC (permalink / raw)
  To: Luis Machado, Tom Tromey, cel; +Cc: gdb-patches

Luis, Tom:


On Thu, 2023-11-16 at 14:02 +0000, Luis Machado wrote:
> On 11/14/23 21:17, Carl Love wrote:
> > Tom:
> > 
> > On Tue, 2023-11-14 at 12:40 -0700, Tom Tromey wrote:
> > > set flags {debug additional_flags=-cargs additional_flags=-fvar-
> > > tracking additional_flags=-margs}
> > 
> > So I put that in as follows:
> > 
> >    set flags {debug additional_flags=-cargs additional_flags=-fvar-
> > tracking additional_flags=-margs}
> 
> I guess one way to make the above slightly cleaner (debatable) is to
> append the additional flags on different lines:
> 
>     set flags {"debug"}
>     lappend flags "additional_flags=-cargs"
>     lappend flags "additional_flags=-fvar-tracking"
>     lappend flags "additional_flags=-margs"
> 
> Slightly more verbose, but may make the additional flags more
> explicit/easier to read.

Yes, I do think that is easier to read.

So I worked on the patch some more once I got it to compile to see if I
need all three options on PowerPC.  On Power, I only seem to need the
-fvar-tracking option.  The -cargs and -margs don't seem to have any
effect on PowerPC.  It looks like the following is all that I need on
Power:

--- a/gdb/testsuite/gdb.ada/finish-large.exp
+++ b/gdb/testsuite/gdb.ada/finish-large.exp
@@ -19,7 +19,13 @@ require allow_ada_tests
 
 standard_ada_testfile p
 
-if {[gdb_compile_ada "${srcfile}" "${binfile}" executable debug] != ""} {
+if {[have_fvar_tracking]} {
+    set flags {debug additional_flags=-fvar-tracking}
+} else {
+    set flags {debug}
+}
+
+if {[gdb_compile_ada "${srcfile}" "${binfile}" executable $flags] != ""} {
   return -1
 
I think Power is the only platform that needs -fvar-tracking for this
test so I was inclined to leave off the other two options.   But if not
having the other two options with -fvar-tracking causes issues on other
platforms then I should include them.  

Tom, for your platform do you have to have all three options or not?

I tested the above patch on PowerPC and X86-64.  It seems to work fine
on both systems.

                       Carl 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: Ada compile with -fvar-tracking
  2023-11-16 16:11       ` Carl Love
@ 2023-11-16 21:07         ` Tom Tromey
  0 siblings, 0 replies; 15+ messages in thread
From: Tom Tromey @ 2023-11-16 21:07 UTC (permalink / raw)
  To: Carl Love; +Cc: Luis Machado, Tom Tromey, gdb-patches

Carl> Tom, for your platform do you have to have all three options or not?

It seems that I don't.
I thought I did need them but I tried your patch just now and it seems fine.

Tom

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2023-11-16 21:07 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-11-14 19:24 Ada compile with -fvar-tracking 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
2023-11-16 14:02     ` Luis Machado
2023-11-16 16:11       ` Carl Love
2023-11-16 21:07         ` Tom Tromey

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).