[PATCH] Powerpc fix for gdb.base/ending-run.exp

[PATCH] Powerpc fix for gdb.base/ending-run.exp

[Carl Love]

GCC maintainers:

The following patch fixes two Powerpc testsuite errors in
gdb.base/ending-run.exp.  As stated below, the last two tests fail.  It
seems the standard output on Powerpc is different then other platforms
as described below.

Please let me know if the following patch is acceptable for gdb
mainline.   Thanks.

                       Carl Love

--------------------------------------------------------------
Powerpc fix for gdb.base/ending-run.exp

The last two tests in this test case fail.  The next to the
last test does a next command when the program is stopped at
the closing bracket for main.  On Powerpc, the message printed
is:

0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6

which fails to match any of the test_multiple options.

The test then does another next command.  On Powerpc, the
message printed it:

Cannot find bounds of current function

which again is not any of the options in the test_multiple.

I checked the behavior on Powerpc to see if this is typical.
I ran gdb on the following simple program as shown below.

#include <stdio.h>
int
main(void)
{
  printf("Hello, world!\n");
  return 0;
}

gdb ./hello_world
<snip the gdb start info>

Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello_world...
(No debugging symbols found in ./hello_world)
(gdb) break main
Breakpoint 1 at 0x818
(gdb) r

Starting program: /home/carll/hello_world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x0000000100000818 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Hello, world!
0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
(gdb) n
Cannot find bounds of current function

So it would seem that the messages seen from the test case are
"normal" output for Powerpc.

The following patch adds the output from Powerpc as an option
to the test_multiple, identifying them as the expected output
on Powerpc.

The patch has been tested on a Power 10 system and an Intel
64-bit system.  No additional regression failures were seen on
either platform.
---
 gdb/testsuite/gdb.base/ending-run.exp | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
index 32435b2b509..d00a002928e 100644
--- a/gdb/testsuite/gdb.base/ending-run.exp
+++ b/gdb/testsuite/gdb.base/ending-run.exp
@@ -202,6 +202,11 @@ gdb_test_multiple "next" "step out of main" {
 	# This is what happens on system using uClibc.
 	pass "step out of main"
     }
+    -re ".*from /lib/powerpc.*$gdb_prompt $" {
+	# Powerpc output for step out of main
+	pass "step out of main"
+	set program_exited_normally 1
+    }
 }
 
 # When we're talking to a program running on a real stand-alone board,
@@ -238,13 +243,18 @@ if {!$use_gdb_stub
 		pass "step to end of run" 
 		set program_in_exit 1
 	    }
+	    -re ".*Cannot find bounds of current function.*$gdb_prompt $" {
+		# Powerpc output for step to end of run
+		pass "step to end of run"
+		set program_in_exit 1
+	    }
 	    -re ".*Single.*_int_reset.*$gdb_prompt $" {
 	        pass "step to end of run"
 		if {![istarget "xstormy16-*-*"]} {
 		    set program_exited_normally 1
 		}
 	    }
-	}   
+	}
     }
 
     if {$program_in_exit} {
-- 
2.32.0

Re: [PING PATCH] Powerpc fix for gdb.base/ending-run.exp

[Carl Love]

GDB maintainers:

Just a ping on the patch.  I noticed I did miss address the patch
initially. This is a patch for GDB.

                Carl 

On Wed, 2022-02-23 at 15:18 -0800, Carl Love wrote:
> GCC maintainers:
> 
> The following patch fixes two Powerpc testsuite errors in
> gdb.base/ending-run.exp.  As stated below, the last two tests
> fail.  It
> seems the standard output on Powerpc is different then other
> platforms
> as described below.
> 
> Please let me know if the following patch is acceptable for gdb
> mainline.   Thanks.
> 
>                        Carl Love
> 
> --------------------------------------------------------------
> Powerpc fix for gdb.base/ending-run.exp
> 
> The last two tests in this test case fail.  The next to the
> last test does a next command when the program is stopped at
> the closing bracket for main.  On Powerpc, the message printed
> is:
> 
> 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
> 
> which fails to match any of the test_multiple options.
> 
> The test then does another next command.  On Powerpc, the
> message printed it:
> 
> Cannot find bounds of current function
> 
> which again is not any of the options in the test_multiple.
> 
> I checked the behavior on Powerpc to see if this is typical.
> I ran gdb on the following simple program as shown below.
> 
> #include <stdio.h>
> int
> main(void)
> {
>   printf("Hello, world!\n");
>   return 0;
> }
> 
> gdb ./hello_world
> <snip the gdb start info>
> 
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./hello_world...
> (No debugging symbols found in ./hello_world)
> (gdb) break main
> Breakpoint 1 at 0x818
> (gdb) r
> 
> Starting program: /home/carll/hello_world
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/powerpc64le-linux-
> gnu/libthread_db.so.1".
> 
> Breakpoint 1, 0x0000000100000818 in main ()
> (gdb) n
> Single stepping until exit from function main,
> which has no line number information.
> Hello, world!
> 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
> (gdb) n
> Cannot find bounds of current function
> 
> So it would seem that the messages seen from the test case are
> "normal" output for Powerpc.
> 
> The following patch adds the output from Powerpc as an option
> to the test_multiple, identifying them as the expected output
> on Powerpc.
> 
> The patch has been tested on a Power 10 system and an Intel
> 64-bit system.  No additional regression failures were seen on
> either platform.
> ---
>  gdb/testsuite/gdb.base/ending-run.exp | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/ending-run.exp
> b/gdb/testsuite/gdb.base/ending-run.exp
> index 32435b2b509..d00a002928e 100644
> --- a/gdb/testsuite/gdb.base/ending-run.exp
> +++ b/gdb/testsuite/gdb.base/ending-run.exp
> @@ -202,6 +202,11 @@ gdb_test_multiple "next" "step out of main" {
>  	# This is what happens on system using uClibc.
>  	pass "step out of main"
>      }
> +    -re ".*from /lib/powerpc.*$gdb_prompt $" {
> +	# Powerpc output for step out of main
> +	pass "step out of main"
> +	set program_exited_normally 1
> +    }
>  }
> 
>  # When we're talking to a program running on a real stand-alone
> board,
> @@ -238,13 +243,18 @@ if {!$use_gdb_stub
>  		pass "step to end of run" 
>  		set program_in_exit 1
>  	    }
> +	    -re ".*Cannot find bounds of current function.*$gdb_prompt
> $" {
> +		# Powerpc output for step to end of run
> +		pass "step to end of run"
> +		set program_in_exit 1
> +	    }
>  	    -re ".*Single.*_int_reset.*$gdb_prompt $" {
>  	        pass "step to end of run"
>  		if {![istarget "xstormy16-*-*"]} {
>  		    set program_exited_normally 1
>  		}
>  	    }
> -	}   
> +	}
>      }
> 
>      if {$program_in_exit} {

Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Joel Brobecker]

Hello,

On Wed, Feb 23, 2022 at 03:18:55PM -0800, Carl Love via Gdb-patches wrote:
> GCC maintainers:
> 
> The following patch fixes two Powerpc testsuite errors in
> gdb.base/ending-run.exp.  As stated below, the last two tests fail.  It
> seems the standard output on Powerpc is different then other platforms
> as described below.
> 
> Please let me know if the following patch is acceptable for gdb
> mainline.   Thanks.

Sorry for the delay in reviewing this.

> --------------------------------------------------------------
> Powerpc fix for gdb.base/ending-run.exp
> 
> The last two tests in this test case fail.  The next to the
> last test does a next command when the program is stopped at
> the closing bracket for main.  On Powerpc, the message printed
> is:
> 
> 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
> 
> which fails to match any of the test_multiple options.
> 
> The test then does another next command.  On Powerpc, the
> message printed it:
> 
> Cannot find bounds of current function
> 
> which again is not any of the options in the test_multiple.
> 
> I checked the behavior on Powerpc to see if this is typical.
> I ran gdb on the following simple program as shown below.
> 
> #include <stdio.h>
> int
> main(void)
> {
>   printf("Hello, world!\n");
>   return 0;
> }
> 
> gdb ./hello_world
> <snip the gdb start info>
> 
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./hello_world...
> (No debugging symbols found in ./hello_world)
> (gdb) break main
> Breakpoint 1 at 0x818
> (gdb) r
> 
> Starting program: /home/carll/hello_world
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
> 
> Breakpoint 1, 0x0000000100000818 in main ()
> (gdb) n
> Single stepping until exit from function main,
> which has no line number information.
> Hello, world!
> 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6

Do you know what code we're inside of, by any chance?
In particular, can you confirm that it is normal that we don't
even have a minimal symbol for this code?

> (gdb) n
> Cannot find bounds of current function

Yeah, expected behavior based on the above.

> 
> So it would seem that the messages seen from the test case are
> "normal" output for Powerpc.
> 
> The following patch adds the output from Powerpc as an option
> to the test_multiple, identifying them as the expected output
> on Powerpc.
> 
> The patch has been tested on a Power 10 system and an Intel
> 64-bit system.  No additional regression failures were seen on
> either platform.

So, if I recap, the testcase ending-run.exp is there to verify that
we can "next" our program's "main" all the way to the program's
exit.

The problem is that, on your platform, this is clearly not something
that we can do. We can see that it's having no problem "next"-ing
up until the program exits "main", but after that, it lands in
a section of code where GDB can't seem to determine what function
it belongs to. As a result of that, trying to do a "next" is not
possible.

If this recap is correct, and we are able to confirm that
the code calling "main" does indeed not have a minimal symbol
associated to it, then I think a high-level view of what
the testcase should do in this case is do "next" operations
until landing inside the unknown function in your libc function.
And from there, determine that there is no point in continuing
further.

If I understand the architecture of this testcase correctly...

> ---
>  gdb/testsuite/gdb.base/ending-run.exp | 12 +++++++++++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
> index 32435b2b509..d00a002928e 100644
> --- a/gdb/testsuite/gdb.base/ending-run.exp
> +++ b/gdb/testsuite/gdb.base/ending-run.exp
> @@ -202,6 +202,11 @@ gdb_test_multiple "next" "step out of main" {
>  	# This is what happens on system using uClibc.
>  	pass "step out of main"
>      }
> +    -re ".*from /lib/powerpc.*$gdb_prompt $" {
> +	# Powerpc output for step out of main
> +	pass "step out of main"
> +	set program_exited_normally 1

... I would set program_exited instead of program_exited_normally.
In fact, I think there was a confusion about this, since
program_exited_normally gets unconditionally set just a few
lines below.

Also, I think it is important in this case that we verify that
no only are we inside a powerpc library, but also that we landed
inside some code for which there is no entrin the symbol table.
For there, we should expand the comment to clearly explain under
which circumstances this has been seen, and what that means
for the rest of the testcase, thus explaining why we mark this
as a pass, *and* we set program_exited to 1.

... meanwhile, setting program_exited should also lead to
the next block of the testcase to skip the next wave of "next"
commands. And a result, program_exited_normally doesn't get
set, and we end up reporting an "unsuported" via...

    if {$program_exited_normally} {
        gdb_test "n" ".*The program is not being run.*" "don't step after run"
    } elseif {$program_not_exited} {
        unresolved "don't step after run"
    } else {
        unsupported "don't step after run"
    }

>  # When we're talking to a program running on a real stand-alone board,
> @@ -238,13 +243,18 @@ if {!$use_gdb_stub
>  		pass "step to end of run" 
>  		set program_in_exit 1
>  	    }
> +	    -re ".*Cannot find bounds of current function.*$gdb_prompt $" {
> +		# Powerpc output for step to end of run
> +		pass "step to end of run"
> +		set program_in_exit 1
> +	    }

... which, to me, means that this shouldn't be need.

What do you think?

-- 
Joel

RE: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Carl Love]

On Sun, 2022-03-06 at 15:12 +0400, Joel Brobecker wrote:
> 
<snip>


> > Starting program: /home/carll/hello_world
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib/powerpc64le-linux-
> > gnu/libthread_db.so.1".
> > 
> > Breakpoint 1, 0x0000000100000818 in main ()
> > (gdb) n
> > Single stepping until exit from function main,
> > which has no line number information.
> > Hello, world!
> > 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-
> > gnu/libc.so.6
> 
> Do you know what code we're inside of, by any chance?
> In particular, can you confirm that it is normal that we don't
> even have a minimal symbol for this code?
> 
> > (gdb) n
> > Cannot find bounds of current function
> 
> Yeah, expected behavior based on the above.

I reached out to the the team that works on the libraries to see if
they could help.  His first thought was that the system was missing
some of the debug libraries.  One thing we found was that the distro
version of gdb gives a different result.  For the hello world test
program using /usr/bin/gdb (Ubuntu distro) gives the following results.

  /usr/bin/gdb ~/hello_world

<snip>

Reading symbols from /home/carll/hello_world...
(No debugging symbols found in /home/carll/hello_world)
(gdb) break main
Breakpoint 1 at 0x818
(gdb) r
Starting program: /home/carll/hello_world 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-
gnu/libthread_db.so.1".

Breakpoint 1, 0x0000000100000818 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Hello, world!
__libc_start_call_main (main=main@entry=0x1000007fc <main>, 
argc=argc@entry=1, argv=argv@entry=0x7ffffffff778, auxvec=auxvec@entry=
0x7ffffffff8b0) at ../sysdeps/nptl/libc_start_call_main.h:74
74	../sysdeps/nptl/libc_start_call_main.h: No such file or
directory.
(gdb) n
[Inferior 1 (process 4143747) exited normally]

Running the test case, with out my patch applied, with make check using
the distro gdb:

make check RUNTESTFLAGS='GDB=/usr/bin/gdb  gdb.base/ending-run.exp '  >
output  results in the test case passing.  The summary from file
output:


                === gdb Summary ===

# of expected passes            19
# of unsupported tests          1

To summarize, the test passes using the distro gdb but fails on my
build of gdb which I have been using to fix the Power gdb support.

I spent a fair bit of time installing various -dev packages so I could
configure my build of gdb the same as the Ubuntu build.  But still have
not been able to get my version of gdb to behave the same as the distro
version.  I don't know what the difference is?

Anyway, it does appear that once you step off of the test program you
end up in function __libc_start_call_main.  



> > So it would seem that the messages seen from the test case are
> > "normal" output for Powerpc.
> > 
> > The following patch adds the output from Powerpc as an option
> > to the test_multiple, identifying them as the expected output
> > on Powerpc.
> > 
> > The patch has been tested on a Power 10 system and an Intel
> > 64-bit system.  No additional regression failures were seen on
> > either platform.
> 
> So, if I recap, the testcase ending-run.exp is there to verify that
> we can "next" our program's "main" all the way to the program's
> exit.
> 
> The problem is that, on your platform, this is clearly not something
> that we can do. We can see that it's having no problem "next"-ing
> up until the program exits "main", but after that, it lands in
> a section of code where GDB can't seem to determine what function
> it belongs to. As a result of that, trying to do a "next" is not
> possible.
> 
> If this recap is correct, and we are able to confirm that
> the code calling "main" does indeed not have a minimal symbol
> associated to it, then I think a high-level view of what
> the testcase should do in this case is do "next" operations
> until landing inside the unknown function in your libc function.
> And from there, determine that there is no point in continuing
> further.
> 
> If I understand the architecture of this testcase correctly...
> 
> > ---
> >  gdb/testsuite/gdb.base/ending-run.exp | 12 +++++++++++-
> >  1 file changed, 11 insertions(+), 1 deletion(-)
> > 
> > diff --git a/gdb/testsuite/gdb.base/ending-run.exp
> > b/gdb/testsuite/gdb.base/ending-run.exp
> > index 32435b2b509..d00a002928e 100644
> > --- a/gdb/testsuite/gdb.base/ending-run.exp
> > +++ b/gdb/testsuite/gdb.base/ending-run.exp
> > @@ -202,6 +202,11 @@ gdb_test_multiple "next" "step out of main" {
> >  	# This is what happens on system using uClibc.
> >  	pass "step out of main"
> >      }
> > +    -re ".*from /lib/powerpc.*$gdb_prompt $" {
> > +	# Powerpc output for step out of main
> > +	pass "step out of main"
> > +	set program_exited_normally 1
> 
> ... I would set program_exited instead of program_exited_normally.
> In fact, I think there was a confusion about this, since
> program_exited_normally gets unconditionally set just a few
> lines below.

I made the change you mentioned above and removed the additional
power gdb_test_multiple clause below.  The test also passes with these
changes.


> 
> Also, I think it is important in this case that we verify that
> no only are we inside a powerpc library, but also that we landed
> inside some code for which there is no entrin the symbol table.
> For there, we should expand the comment to clearly explain under
> which circumstances this has been seen, and what that means
> for the rest of the testcase, thus explaining why we mark this
> as a pass, *and* we set program_exited to 1.
> 
> ... meanwhile, setting program_exited should also lead to
> the next block of the testcase to skip the next wave of "next"
> commands. And a result, program_exited_normally doesn't get
> set, and we end up reporting an "unsuported" via...
> 
>     if {$program_exited_normally} {
>         gdb_test "n" ".*The program is not being run.*" "don't step
> after run"
>     } elseif {$program_not_exited} {
>         unresolved "don't step after run"
>     } else {
>         unsupported "don't step after run"
>     }
> 
> >  # When we're talking to a program running on a real stand-alone
> > board,
> > @@ -238,13 +243,18 @@ if {!$use_gdb_stub
> >  		pass "step to end of run" 
> >  		set program_in_exit 1
> >  	    }
> > +	    -re ".*Cannot find bounds of current function.*$gdb_prompt
> > $" {
> > +		# Powerpc output for step to end of run
> > +		pass "step to end of run"
> > +		set program_in_exit 1
> > +	    }
> 
> ... which, to me, means that this shouldn't be need.

Agreed as mentioned above.

> 
> What do you think?
> 

Per above, the second change does appear to be unecessary.   What to do
about the first change?  I haven't been able to sort out why I can't
compile gdb to match the distro behaviour.  Maybe this patch really
isn't needed but it would be really nice to understand how to reproduce
the distro behaviour.  If you have any thoughts as to how to configure
my build of gdb to achieve this that would be interesting.

Thanks for your time looking at the patch.

                     Carl

RE: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Carl Love]

Joel:

On Mon, 2022-03-07 at 15:59 -0800, Carl Love wrote:
> Per above, the second change does appear to be unecessary.   What to
> do
> about the first change?  I haven't been able to sort out why I can't
> compile gdb to match the distro behaviour.  Maybe this patch really
> isn't needed but it would be really nice to understand how to
> reproduce
> the distro behaviour.  If you have any thoughts as to how to
> configure
> my build of gdb to achieve this that would be interesting.
> 
> Thanks for your time looking at the patch.

The error occurs on Ubuntu on Power 10.  Per a suggestion, I tested the
patch on a Red Hat distro.  The test passes fine there.  Ubuntu puts
the debug info symbols in separate packages from the development
packages.  I have been thru the list of available packages and tried
installing all the relavent packages to no avail.

The guess is with the proper symbols available on Ubuntu, the test will
pass without my patch.  Just don't know what the missing package is.

              Carl 

Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Joel Brobecker]

Hi Carl,

> > > Starting program: /home/carll/hello_world
> > > [Thread debugging using libthread_db enabled]
> > > Using host libthread_db library "/lib/powerpc64le-linux-
> > > gnu/libthread_db.so.1".
> > > 
> > > Breakpoint 1, 0x0000000100000818 in main ()
> > > (gdb) n
> > > Single stepping until exit from function main,
> > > which has no line number information.
> > > Hello, world!
> > > 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-
> > > gnu/libc.so.6
> > 
> > Do you know what code we're inside of, by any chance?
> > In particular, can you confirm that it is normal that we don't
> > even have a minimal symbol for this code?
[...]
> Anyway, it does appear that once you step off of the test program you
> end up in function __libc_start_call_main.  

Good to know. Perhaps you could mention that in a comment inside
the block handling this scenario.

> > ... I would set program_exited instead of program_exited_normally.
> > In fact, I think there was a confusion about this, since
> > program_exited_normally gets unconditionally set just a few
> > lines below.
> 
> I made the change you mentioned above and removed the additional
> power gdb_test_multiple clause below.  The test also passes with these
> changes.

OK, good.

> The error occurs on Ubuntu on Power 10.  Per a suggestion, I tested the
> patch on a Red Hat distro.  The test passes fine there.  Ubuntu puts
> the debug info symbols in separate packages from the development
> packages.  I have been thru the list of available packages and tried
> installing all the relavent packages to no avail.
> 
> The guess is with the proper symbols available on Ubuntu, the test will
> pass without my patch.  Just don't know what the missing package is.

I don't think this is a problem. For me, the testcase should be
able to be adapt to the distro it is running on, and if it is
running on a distro that doesn't allow the testcase to run properly,
then it should handle it gracefully (ideally).

> Per above, the second change does appear to be unecessary.   What to do
> about the first change?  I haven't been able to sort out why I can't
> compile gdb to match the distro behaviour.  Maybe this patch really
> isn't needed but it would be really nice to understand how to reproduce
> the distro behaviour.  If you have any thoughts as to how to configure
> my build of gdb to achieve this that would be interesting.

Let's go with the modified version of the first change. If you send
it in for approval, and Cc: me on the email, I will try to review it
quickly.

-- 
Joel

RE: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Carl Love]

Joel, GDB maintainers:

On Fri, 2022-03-11 at 06:28 +0400, Joel Brobecker wrote:
> 
> [...]
> > Anyway, it does appear that once you step off of the test program
> > you
> > end up in function __libc_start_call_main.  
> 
> Good to know. Perhaps you could mention that in a comment inside
> the block handling this scenario.

I added comments as requested to the gdb_test_multiple statement to
handle the case for Power when the needed debug info files are not
installed.
> 
> > > ... I would set program_exited instead of
> > > program_exited_normally.
> > > In fact, I think there was a confusion about this, since
> > > program_exited_normally gets unconditionally set just a few
> > > lines below.
> > 
> > I made the change you mentioned above and removed the additional
> > power gdb_test_multiple clause below.  The test also passes with
> > these
> > changes.
> 
> OK, good.
> 
> > The error occurs on Ubuntu on Power 10.  Per a suggestion, I tested
> > the
> > patch on a Red Hat distro.  The test passes fine there.  Ubuntu
> > puts
> > the debug info symbols in separate packages from the development
> > packages.  I have been thru the list of available packages and
> > tried
> > installing all the relavent packages to no avail.
> > 
> > The guess is with the proper symbols available on Ubuntu, the test
> > will
> > pass without my patch.  Just don't know what the missing package
> > is.
> 
> I don't think this is a problem. For me, the testcase should be
> able to be adapt to the distro it is running on, and if it is
> running on a distro that doesn't allow the testcase to run properly,
> then it should handle it gracefully (ideally).

I also updated the commit message to say the output is normal on
Powerpc when the debug info files are not installed.

The patch was tested on a refreshed copy of the latest mainline git
tree.  The two test failures were fixed with no additional regression
failures. 

Please let me know if the patch is acceptable with the above fixes.  
Thanks for your time and help with the patch.

                          Carl Love

------------------------------------------------
Powerpc fix for gdb.base/ending-run.exp

The last two tests in this test case fail.  The next to the
last test does a next command when the program is stopped at
the closing bracket for main.  On Powerpc, the message printed
is:

0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6

which fails to match any of the test_multiple options.

The test then does another next command.  On Powerpc, the
message printed it:

Cannot find bounds of current function

which again is not any of the options in the test_multiple.

I checked the behavior on Powerpc to see if this is typical.
I ran gdb on the following simple program as shown below.

#include <stdio.h>
int
main(void)
{
  printf("Hello, world!\n");
  return 0;
}

gdb ./hello_world
<snip the gdb start info>

Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello_world...
(No debugging symbols found in ./hello_world)
(gdb) break main
Breakpoint 1 at 0x818
(gdb) r

Starting program: /home/carll/hello_world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x0000000100000818 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Hello, world!
0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
(gdb) n
Cannot find bounds of current function

So it would seem that the messages seen from the test case are
"normal" output for Powerpc.  Further investigation revealed that this
behavior is the result of the system not having all the needed debug info
files installed.  With the debug info files installed on the system the
test passes without this patch.

The following patch adds the output from Powerpc as an option
to the test_multiple, identifying the output as the expected output
on Powerpc when the debug info files are not installed.

The patch has been tested on a Power 10 system and an Intel
64-bit system.  No additional regression failures were seen on
either platform.
---
 gdb/testsuite/gdb.base/ending-run.exp | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
index 32435b2b509..38a52b91e9c 100644
--- a/gdb/testsuite/gdb.base/ending-run.exp
+++ b/gdb/testsuite/gdb.base/ending-run.exp
@@ -202,6 +202,13 @@ gdb_test_multiple "next" "step out of main" {
 	# This is what happens on system using uClibc.
 	pass "step out of main"
     }
+    -re ".*from /lib/powerpc.*$gdb_prompt $" {
+	# This case occurs on Powerpc when gdb steps out of main and the
+	# needed debug info files are not loaded on the system so gdb can
+	# see it stepped to function into __libc_start_call_main.
+	pass "step out of main"
+	set program_exited 1
+    }
 }
 
 # When we're talking to a program running on a real stand-alone board,
-- 
2.32.0

Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Joel Brobecker]

Hi Carl,

> diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
> index 32435b2b509..38a52b91e9c 100644
> --- a/gdb/testsuite/gdb.base/ending-run.exp
> +++ b/gdb/testsuite/gdb.base/ending-run.exp
> @@ -202,6 +202,13 @@ gdb_test_multiple "next" "step out of main" {
>  	# This is what happens on system using uClibc.
>  	pass "step out of main"
>      }
> +    -re ".*from /lib/powerpc.*$gdb_prompt $" {

I really think we should try to match the fact that we were unable
to determine the name of the function in the frame information.
Wouldn't otherwise the regexp above also match when your system
does have the debugging information, incorrectly leading us to
stop the testing when we should be able to continue?

> +	# This case occurs on Powerpc when gdb steps out of main and the
> +	# needed debug info files are not loaded on the system so gdb can
> +	# see it stepped to function into __libc_start_call_main.

"stepped to function into xxx" seems odd.

I'd like to also add an explanation as to why we set program_exited,
and in particular why the situation we just detected makes us unable
to continue the testing.

What about...

	# This case occurs on Powerpc when gdb steps out of main and the
	# needed debug info files are not loaded on the system, preventing
	# GDB to determine which function it reached (__libc_start_call_main).
        # Ideally, the target system would have the necessary debugging
        # information, but in its absence, GDB's behavior is as expected.
        #
        # Another consequence of this missing information is that GDB
        # can no longer continue to perform "next" operations, as doing
        # so requires GDB to know the bounds of the current function.
        # Not know what the current function it, it cannot determine
        # its bounds. So we also set program_exited to 1 to indicate
        # that we need to stop this testcase at this stage of the testing.

?
> +	pass "step out of main"
> +	set program_exited 1
> +    }
>  }
>  
>  # When we're talking to a program running on a real stand-alone board,
> -- 
> 2.32.0
> 
> 

-- 
Joel

RE: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Carl Love]

Joel:

My comment was rather minimalistic.  Your comment is a much better more
verbose statement.  It looks good to me.  Thanks.  

I updated the patch, attached below.

               Carl 

On Sun, 2022-03-13 at 09:21 +0400, Joel Brobecker wrote:
> Hi Carl,
> 
> > diff --git a/gdb/testsuite/gdb.base/ending-run.exp
> > b/gdb/testsuite/gdb.base/ending-run.exp
> > index 32435b2b509..38a52b91e9c 100644
> > --- a/gdb/testsuite/gdb.base/ending-run.exp
> > +++ b/gdb/testsuite/gdb.base/ending-run.exp
> > @@ -202,6 +202,13 @@ gdb_test_multiple "next" "step out of main" {
> >  	# This is what happens on system using uClibc.
> >  	pass "step out of main"
> >      }
> > +    -re ".*from /lib/powerpc.*$gdb_prompt $" {
> 
> I really think we should try to match the fact that we were unable
> to determine the name of the function in the frame information.
> Wouldn't otherwise the regexp above also match when your system
> does have the debugging information, incorrectly leading us to
> stop the testing when we should be able to continue?
> 
> > +	# This case occurs on Powerpc when gdb steps out of main and
> > the
> > +	# needed debug info files are not loaded on the system so gdb
> > can
> > +	# see it stepped to function into __libc_start_call_main.
> 
> "stepped to function into xxx" seems odd.
> 
> I'd like to also add an explanation as to why we set program_exited,
> and in particular why the situation we just detected makes us unable
> to continue the testing.
> 
> What about...
> 
> 	# This case occurs on Powerpc when gdb steps out of main and
> the
> 	# needed debug info files are not loaded on the system,
> preventing
> 	# GDB to determine which function it reached
> (__libc_start_call_main).
>         # Ideally, the target system would have the necessary
> debugging
>         # information, but in its absence, GDB's behavior is as
> expected.
>         #
>         # Another consequence of this missing information is that GDB
>         # can no longer continue to perform "next" operations, as
> doing
>         # so requires GDB to know the bounds of the current function.
>         # Not know what the current function it, it cannot determine
>         # its bounds. So we also set program_exited to 1 to indicate
>         # that we need to stop this testcase at this stage of the
> testing.
> 
---------------------------------------------------

Powerpc fix for gdb.base/ending-run.exp

The last two tests in this test case fail.  The next to the
last test does a next command when the program is stopped at
the closing bracket for main.  On Powerpc, the message printed
is:

0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6

which fails to match any of the test_multiple options.

The test then does another next command.  On Powerpc, the
message printed it:

Cannot find bounds of current function

which again is not any of the options in the test_multiple.

I checked the behavior on Powerpc to see if this is typical.
I ran gdb on the following simple program as shown below.

#include <stdio.h>
int
main(void)
{
  printf("Hello, world!\n");
  return 0;
}

gdb ./hello_world
<snip the gdb start info>

Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello_world...
(No debugging symbols found in ./hello_world)
(gdb) break main
Breakpoint 1 at 0x818
(gdb) r

Starting program: /home/carll/hello_world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x0000000100000818 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Hello, world!
0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
(gdb) n
Cannot find bounds of current function

So it would seem that the messages seen from the test case are
"normal" output for Powerpc.

The following patch adds the output from Powerpc as an option
to the test_multiple, identifying them as the expected output
on Powerpc.

The patch has been tested on a Power 10 system and an Intel
64-bit system.  No additional regression failures were seen on
either platform.
---
 gdb/testsuite/gdb.base/ending-run.exp | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
index 32435b2b509..7e2134556de 100644
--- a/gdb/testsuite/gdb.base/ending-run.exp
+++ b/gdb/testsuite/gdb.base/ending-run.exp
@@ -202,6 +202,22 @@ gdb_test_multiple "next" "step out of main" {
 	# This is what happens on system using uClibc.
 	pass "step out of main"
     }
+    -re ".*from /lib/powerpc.*$gdb_prompt $" {
+	# This case occurs on Powerpc when gdb steps out of main and the
+	# needed debug info files are not loaded on the system, preventing
+	# GDB to determine which function it reached (__libc_start_call_main).
+	# Ideally, the target system would have the necessary debugging
+	# information, but in its absence, GDB's behavior is as expected.
+	#
+	# Another consequence of this missing information is that GDB
+	# can no longer continue to perform "next" operations, as doing
+	# so requires GDB to know the bounds of the current function.
+	# Not know what the current function it, it cannot determine
+	# its bounds. So we also set program_exited to 1 to indicate
+	# that we need to stop this testcase at this stage of the testing.
+	pass "step out of main"
+	set program_exited 1
+    }
 }
 
 # When we're talking to a program running on a real stand-alone board,
-- 
2.32.0

Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[will schmidt]

On Mon, 2022-03-14 at 08:54 -0700, Carl Love via Gdb-patches wrote:
> Joel:
> 
> My comment was rather minimalistic.  Your comment is a much better
> more
> verbose statement.  It looks good to me.  Thanks.  
> 
> I updated the patch, attached below.
> 
>                Carl 
> 
> On Sun, 2022-03-13 at 09:21 +0400, Joel Brobecker wrote:
> > Hi Carl,
> > 
> > > diff --git a/gdb/testsuite/gdb.base/ending-run.exp
> > > b/gdb/testsuite/gdb.base/ending-run.exp
> > > index 32435b2b509..38a52b91e9c 100644
> > > --- a/gdb/testsuite/gdb.base/ending-run.exp
> > > +++ b/gdb/testsuite/gdb.base/ending-run.exp
> > > @@ -202,6 +202,13 @@ gdb_test_multiple "next" "step out of main"
> > > {
> > >  	# This is what happens on system using uClibc.
> > >  	pass "step out of main"
> > >      }
> > > +    -re ".*from /lib/powerpc.*$gdb_prompt $" {
> > 
> > I really think we should try to match the fact that we were unable
> > to determine the name of the function in the frame information.
> > Wouldn't otherwise the regexp above also match when your system
> > does have the debugging information, incorrectly leading us to
> > stop the testing when we should be able to continue?
> > 
> > > +	# This case occurs on Powerpc when gdb steps out of main and
> > > the
> > > +	# needed debug info files are not loaded on the system so gdb
> > > can
> > > +	# see it stepped to function into __libc_start_call_main.
> > 
> > "stepped to function into xxx" seems odd.
> > 
> > I'd like to also add an explanation as to why we set
> > program_exited,
> > and in particular why the situation we just detected makes us
> > unable
> > to continue the testing.
> > 
> > What about...
> > 
> > 	# This case occurs on Powerpc when gdb steps out of main and
> > the
> > 	# needed debug info files are not loaded on the system,
> > preventing
> > 	# GDB to determine which function it reached
> > (__libc_start_call_main).
> >         # Ideally, the target system would have the necessary
> > debugging
> >         # information, but in its absence, GDB's behavior is as
> > expected.
> >         #
> >         # Another consequence of this missing information is that
> > GDB
> >         # can no longer continue to perform "next" operations, as
> > doing
> >         # so requires GDB to know the bounds of the current
> > function.
> >         # Not know what the current function it, it cannot
> > determine
> >         # its bounds. So we also set program_exited to 1 to
> > indicate
> >         # that we need to stop this testcase at this stage of the
> > testing.
> > 
> ---------------------------------------------------
> 
> Powerpc fix for gdb.base/ending-run.exp
> 
> The last two tests in this test case fail.  The next to the
> last test does a next command when the program is stopped at
> the closing bracket for main.  On Powerpc, the message printed
> is:

Now that the situation is understood, i'd suggest updating the lead-in
description to clarify that these tests fail when debuginfo is not
found by GDB.   That could be clarified further to indicate (... for
glibc) or somesuch. 

The story could also be inverted a bit to clarify the situation.
When debuginfo can not be found for glibc, this test will fail once the
test program passes exit(), since it's stack/location in glibc space
can not be determined. 


> 
> 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
> 
> which fails to match any of the test_multiple options.
> 
> The test then does another next command.  On Powerpc, the
> message printed it:
> 
> Cannot find bounds of current function
> 
> which again is not any of the options in the test_multiple.
> 
> I checked the behavior on Powerpc to see if this is typical.
> I ran gdb on the following simple program as shown below.
> 
> #include <stdio.h>
> int
> main(void)
> {
>   printf("Hello, world!\n");
>   return 0;
> }
> 
> gdb ./hello_world
> <snip the gdb start info>
> 
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./hello_world...
> (No debugging symbols found in ./hello_world)
> (gdb) break main
> Breakpoint 1 at 0x818
> (gdb) r
> 
> Starting program: /home/carll/hello_world
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/powerpc64le-linux-
> gnu/libthread_db.so.1".
> 
> Breakpoint 1, 0x0000000100000818 in main ()
> (gdb) n
> Single stepping until exit from function main,
> which has no line number information.
> Hello, world!
> 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
> (gdb) n
> Cannot find bounds of current function
> 
> So it would seem that the messages seen from the test case are
> "normal" output for Powerpc.
> 
> The following patch adds the output from Powerpc as an option
> to the test_multiple, identifying them as the expected output
> on Powerpc.
> 
> The patch has been tested on a Power 10 system and an Intel
> 64-bit system.  No additional regression failures were seen on
> either platform.
> ---
>  gdb/testsuite/gdb.base/ending-run.exp | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.base/ending-run.exp
> b/gdb/testsuite/gdb.base/ending-run.exp
> index 32435b2b509..7e2134556de 100644
> --- a/gdb/testsuite/gdb.base/ending-run.exp
> +++ b/gdb/testsuite/gdb.base/ending-run.exp
> @@ -202,6 +202,22 @@ gdb_test_multiple "next" "step out of main" {
>  	# This is what happens on system using uClibc.
>  	pass "step out of main"
>      }
> +    -re ".*from /lib/powerpc.*$gdb_prompt $" {
> +	# This case occurs on Powerpc when gdb steps out of main and
> the
> +	# needed debug info files are not loaded on the system,
> preventing
> +	# GDB to determine which function it reached
> (__libc_start_call_main).
> +	# Ideally, the target system would have the necessary debugging
> +	# information, but in its absence, GDB's behavior is as
> expected.
> +	#
> +	# Another consequence of this missing information is that GDB
> +	# can no longer continue to perform "next" operations, as doing
> +	# so requires GDB to know the bounds of the current function.
> +	# Not know what the current function it, it cannot determine
> +	# its bounds. So we also set program_exited to 1 to indicate
> +	# that we need to stop this testcase at this stage of the
> testing.
> +	pass "step out of main"
 
Should this pass statement add a hint about missing debuginfo?  i.e. 
	pass "step out of main, (missing libc debuginfo)"


> +	set program_exited 1
> +    }
>  }
> 
>  # When we're talking to a program running on a real stand-alone
> board,

Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Carl Love]

Will, Joel:

> 
> Now that the situation is understood, i'd suggest updating the lead-
> in
> description to clarify that these tests fail when debuginfo is not
> found by GDB.   That could be clarified further to indicate (... for
> glibc) or somesuch. 
> 
> The story could also be inverted a bit to clarify the situation.
> When debuginfo can not be found for glibc, this test will fail once
> the
> test program passes exit(), since it's stack/location in glibc space
> can not be determined. 

Yes, the description was written before the key issue of the dbug-info
files was understood.  That information was added after the fact but
you have to read fairly far into this rather long commit message to
find that.  I agree, it should be brought to the top as it is the key
issue here.  I re-worked the commite message per your comments.  

The patch with the updated commit message is below.

                           Carl Love

----------------------------------------------------------

Powerpc fix for gdb.base/ending-run.exp

The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the
system does not have the needed glibc debug-info files loaded.  In this
case, gdb is not able to determine where execution stopped.  This behavior
looks as follows for the test case:

The next to the last test does a next command when the program is stopped
at the closing bracket for main.  The message printed is:

0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6

which fails to match any of the test_multiple options.

The test then does another next command.  On Powerpc, the
message printed it:

Cannot find bounds of current function

The test fails as the output does not match any of the options for the
gdb_test_multiple.

I checked the behavior on Powerpc to see if this is typical.
I ran gdb on the following simple program as shown below.

#include <stdio.h>
int
main(void)
{
  printf("Hello, world!\n");
  return 0;
}

gdb ./hello_world
<snip the gdb start info>

Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello_world...
(No debugging symbols found in ./hello_world)
(gdb) break main
Breakpoint 1 at 0x818
(gdb) r

Starting program: /home/carll/hello_world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x0000000100000818 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Hello, world!
0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
(gdb) n
Cannot find bounds of current function

So it would seem that the messages seen from the test case are
"normal" output for Powerpc when the debug-info is not available.

The following patch adds the output from Powerpc as an option
to the gdb_test_multiple statement, identifying the output as the expected
output on Powerpc without the needed debug-info files installed.

The patch has been tested on a Power 10 system and an Intel
64-bit system.  No additional regression failures were seen on
either platform.
---
 gdb/testsuite/gdb.base/ending-run.exp | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
index 32435b2b509..7e2134556de 100644
--- a/gdb/testsuite/gdb.base/ending-run.exp
+++ b/gdb/testsuite/gdb.base/ending-run.exp
@@ -202,6 +202,22 @@ gdb_test_multiple "next" "step out of main" {
 	# This is what happens on system using uClibc.
 	pass "step out of main"
     }
+    -re ".*from /lib/powerpc.*$gdb_prompt $" {
+	# This case occurs on Powerpc when gdb steps out of main and the
+	# needed debug info files are not loaded on the system, preventing
+	# GDB to determine which function it reached (__libc_start_call_main).
+	# Ideally, the target system would have the necessary debugging
+	# information, but in its absence, GDB's behavior is as expected.
+	#
+	# Another consequence of this missing information is that GDB
+	# can no longer continue to perform "next" operations, as doing
+	# so requires GDB to know the bounds of the current function.
+	# Not know what the current function it, it cannot determine
+	# its bounds. So we also set program_exited to 1 to indicate
+	# that we need to stop this testcase at this stage of the testing.
+	pass "step out of main"
+	set program_exited 1
+    }
 }
 
 # When we're talking to a program running on a real stand-alone board,
-- 
2.32.0

Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Joel Brobecker]

Hi Carl,

[off list]

> > Now that the situation is understood, i'd suggest updating the lead-
> > in
> > description to clarify that these tests fail when debuginfo is not
> > found by GDB.   That could be clarified further to indicate (... for
> > glibc) or somesuch. 
> > 
> > The story could also be inverted a bit to clarify the situation.
> > When debuginfo can not be found for glibc, this test will fail once
> > the
> > test program passes exit(), since it's stack/location in glibc space
> > can not be determined. 
> 
> Yes, the description was written before the key issue of the dbug-info
> files was understood.  That information was added after the fact but
> you have to read fairly far into this rather long commit message to
> find that.  I agree, it should be brought to the top as it is the key
> issue here.  I re-worked the commite message per your comments.  
> 
> The patch with the updated commit message is below.
> 
>                            Carl Love
> 
> ----------------------------------------------------------
> 
> Powerpc fix for gdb.base/ending-run.exp
> 
> The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the
> system does not have the needed glibc debug-info files loaded.  In this
> case, gdb is not able to determine where execution stopped.  This behavior
> looks as follows for the test case:
> 
> The next to the last test does a next command when the program is stopped
> at the closing bracket for main.  The message printed is:
> 
> 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
> 
> which fails to match any of the test_multiple options.
> 
> The test then does another next command.  On Powerpc, the
> message printed it:
> 
> Cannot find bounds of current function
> 
> The test fails as the output does not match any of the options for the
> gdb_test_multiple.
> 
> I checked the behavior on Powerpc to see if this is typical.
> I ran gdb on the following simple program as shown below.
> 
> #include <stdio.h>
> int
> main(void)
> {
>   printf("Hello, world!\n");
>   return 0;
> }
> 
> gdb ./hello_world
> <snip the gdb start info>
> 
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./hello_world...
> (No debugging symbols found in ./hello_world)
> (gdb) break main
> Breakpoint 1 at 0x818
> (gdb) r
> 
> Starting program: /home/carll/hello_world
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
> 
> Breakpoint 1, 0x0000000100000818 in main ()
> (gdb) n
> Single stepping until exit from function main,
> which has no line number information.
> Hello, world!
> 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
> (gdb) n
> Cannot find bounds of current function
> 
> So it would seem that the messages seen from the test case are
> "normal" output for Powerpc when the debug-info is not available.
> 
> The following patch adds the output from Powerpc as an option
> to the gdb_test_multiple statement, identifying the output as the expected
> output on Powerpc without the needed debug-info files installed.
> 
> The patch has been tested on a Power 10 system and an Intel
> 64-bit system.  No additional regression failures were seen on
> either platform.
> ---
>  gdb/testsuite/gdb.base/ending-run.exp | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
> index 32435b2b509..7e2134556de 100644
> --- a/gdb/testsuite/gdb.base/ending-run.exp
> +++ b/gdb/testsuite/gdb.base/ending-run.exp
> @@ -202,6 +202,22 @@ gdb_test_multiple "next" "step out of main" {
>  	# This is what happens on system using uClibc.
>  	pass "step out of main"
>      }
> +    -re ".*from /lib/powerpc.*$gdb_prompt $" {

Did you see the following comment I made?

    | I really think we should try to match the fact that we were unable
    | to determine the name of the function in the frame information.
    | Wouldn't otherwise the regexp above also match when your system
    | does have the debugging information, incorrectly leading us to
    | stop the testing when we should be able to continue?

I hope this is understandable. I'm a little worried, because this is
my third time asking this.

Said differently, I think the regexp above should be enhanced to
verify that landed at an address for which there is no symbolic
information at all (i.e. "in ?? ()").

> +	# This case occurs on Powerpc when gdb steps out of main and the
> +	# needed debug info files are not loaded on the system, preventing
> +	# GDB to determine which function it reached (__libc_start_call_main).
> +	# Ideally, the target system would have the necessary debugging
> +	# information, but in its absence, GDB's behavior is as expected.
> +	#
> +	# Another consequence of this missing information is that GDB
> +	# can no longer continue to perform "next" operations, as doing
> +	# so requires GDB to know the bounds of the current function.
> +	# Not know what the current function it, it cannot determine
> +	# its bounds. So we also set program_exited to 1 to indicate
> +	# that we need to stop this testcase at this stage of the testing.
> +	pass "step out of main"
> +	set program_exited 1
> +    }
>  }
>  
>  # When we're talking to a program running on a real stand-alone board,
> -- 
> 2.32.0
> 
> 

-- 
Joel

Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Carl Love]

Joel, GDB maintainers:

Per the convesation I had with Joel, there is an issue with the regexp.
The regexp for the missing debug info case on Power needs to include
the "?? ()" in the regular expression to match the case where gdb can't
find the name and prints ?? rather then the actual name.  Otherwise,
the new gdb_test_multiple could match the case where a function name
was printed.

I tested the updated patch on a Power 10 system that does not have the
debug info installed and on a system that does have the debug info to
verify the new test entry is only hit when the debug info is missing.

Hopefully, this addresses all of the issues with the patch.

                     Carl Love

------------------------------------------
Powerpc fix for gdb.base/ending-run.exp

The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the
system does not have the needed glibc debug-info files loaded.  In this
case, gdb is not able to determine where execution stopped.  This behavior
looks as follows for the test case:

The next to the last test does a next command when the program is stopped
at the closing bracket for main.  The message printed is:

0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6

which fails to match any of the test_multiple options.

The test then does another next command.  On Powerpc, the
message printed it:

Cannot find bounds of current function

The test fails as the output does not match any of the options for the
gdb_test_multiple.

I checked the behavior on Powerpc to see if this is typical.
I ran gdb on the following simple program as shown below.

#include <stdio.h>
int
main(void)
{
  printf("Hello, world!\n");
  return 0;
}

gdb ./hello_world
<snip the gdb start info>

Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello_world...
(No debugging symbols found in ./hello_world)
(gdb) break main
Breakpoint 1 at 0x818
(gdb) r

Starting program: /home/carll/hello_world
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".

Breakpoint 1, 0x0000000100000818 in main ()
(gdb) n
Single stepping until exit from function main,
which has no line number information.
Hello, world!
0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
(gdb) n
Cannot find bounds of current function

So it would seem that the messages seen from the test case are
"normal" output for Powerpc when the debug-info is not available.

The following patch adds the output from Powerpc as an option
to the gdb_test_multiple statement, identifying the output as the expected
output on Powerpc without the needed debug-info files installed.

The patch has been tested on a Power 10 system and an Intel
64-bit system.  No additional regression failures were seen on
either platform.
---
 gdb/testsuite/gdb.base/ending-run.exp | 16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
index 32435b2b509..906f1ac40ca 100644
--- a/gdb/testsuite/gdb.base/ending-run.exp
+++ b/gdb/testsuite/gdb.base/ending-run.exp
@@ -202,6 +202,22 @@ gdb_test_multiple "next" "step out of main" {
 	# This is what happens on system using uClibc.
 	pass "step out of main"
     }
+    -re "0x.*\\?\\? \\(\\) from /lib/powerpc.*$gdb_prompt $" {
+	# This case occurs on Powerpc when gdb steps out of main and the
+	# needed debug info files are not loaded on the system, preventing
+	# GDB to determine which function it reached (__libc_start_call_main).
+	# Ideally, the target system would have the necessary debugging
+	# information, but in its absence, GDB's behavior is as expected.
+	#
+	# Another consequence of this missing information is that GDB
+	# can no longer continue to perform "next" operations, as doing
+	# so requires GDB to know the bounds of the current function.
+	# Not know what the current function it, it cannot determine
+	# its bounds. So we also set program_exited to 1 to indicate
+	# that we need to stop this testcase at this stage of the testing.
+	pass "step out of main"
+	set program_exited 1
+    }
 }
 
 # When we're talking to a program running on a real stand-alone board,
-- 
2.32.0

Re: [PATCH] Powerpc fix for gdb.base/ending-run.exp

[Joel Brobecker]

Hi Carl,

On Tue, Mar 15, 2022 at 08:51:06AM -0700, Carl Love wrote:
> 
> Joel, GDB maintainers:
> 
> Per the convesation I had with Joel, there is an issue with the regexp.
> The regexp for the missing debug info case on Power needs to include
> the "?? ()" in the regular expression to match the case where gdb can't
> find the name and prints ?? rather then the actual name.  Otherwise,
> the new gdb_test_multiple could match the case where a function name
> was printed.
> 
> I tested the updated patch on a Power 10 system that does not have the
> debug info installed and on a system that does have the debug info to
> verify the new test entry is only hit when the debug info is missing.
> 
> Hopefully, this addresses all of the issues with the patch.

Yes. The patch looks good to me, now.

Thank you!

> ------------------------------------------
> Powerpc fix for gdb.base/ending-run.exp
> 
> The last two tests in gdb.base/ending-run.exp case fail on Powerpc when the
> system does not have the needed glibc debug-info files loaded.  In this
> case, gdb is not able to determine where execution stopped.  This behavior
> looks as follows for the test case:
> 
> The next to the last test does a next command when the program is stopped
> at the closing bracket for main.  The message printed is:
> 
> 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
> 
> which fails to match any of the test_multiple options.
> 
> The test then does another next command.  On Powerpc, the
> message printed it:
> 
> Cannot find bounds of current function
> 
> The test fails as the output does not match any of the options for the
> gdb_test_multiple.
> 
> I checked the behavior on Powerpc to see if this is typical.
> I ran gdb on the following simple program as shown below.
> 
> #include <stdio.h>
> int
> main(void)
> {
>   printf("Hello, world!\n");
>   return 0;
> }
> 
> gdb ./hello_world
> <snip the gdb start info>
> 
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from ./hello_world...
> (No debugging symbols found in ./hello_world)
> (gdb) break main
> Breakpoint 1 at 0x818
> (gdb) r
> 
> Starting program: /home/carll/hello_world
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
> 
> Breakpoint 1, 0x0000000100000818 in main ()
> (gdb) n
> Single stepping until exit from function main,
> which has no line number information.
> Hello, world!
> 0x00007ffff7d01524 in ?? () from /lib/powerpc64le-linux-gnu/libc.so.6
> (gdb) n
> Cannot find bounds of current function
> 
> So it would seem that the messages seen from the test case are
> "normal" output for Powerpc when the debug-info is not available.
> 
> The following patch adds the output from Powerpc as an option
> to the gdb_test_multiple statement, identifying the output as the expected
> output on Powerpc without the needed debug-info files installed.
> 
> The patch has been tested on a Power 10 system and an Intel
> 64-bit system.  No additional regression failures were seen on
> either platform.
> ---
>  gdb/testsuite/gdb.base/ending-run.exp | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/gdb/testsuite/gdb.base/ending-run.exp b/gdb/testsuite/gdb.base/ending-run.exp
> index 32435b2b509..906f1ac40ca 100644
> --- a/gdb/testsuite/gdb.base/ending-run.exp
> +++ b/gdb/testsuite/gdb.base/ending-run.exp
> @@ -202,6 +202,22 @@ gdb_test_multiple "next" "step out of main" {
>  	# This is what happens on system using uClibc.
>  	pass "step out of main"
>      }
> +    -re "0x.*\\?\\? \\(\\) from /lib/powerpc.*$gdb_prompt $" {
> +	# This case occurs on Powerpc when gdb steps out of main and the
> +	# needed debug info files are not loaded on the system, preventing
> +	# GDB to determine which function it reached (__libc_start_call_main).
> +	# Ideally, the target system would have the necessary debugging
> +	# information, but in its absence, GDB's behavior is as expected.
> +	#
> +	# Another consequence of this missing information is that GDB
> +	# can no longer continue to perform "next" operations, as doing
> +	# so requires GDB to know the bounds of the current function.
> +	# Not know what the current function it, it cannot determine
> +	# its bounds. So we also set program_exited to 1 to indicate
> +	# that we need to stop this testcase at this stage of the testing.
> +	pass "step out of main"
> +	set program_exited 1
> +    }
>  }
>  
>  # When we're talking to a program running on a real stand-alone board,
> -- 
> 2.32.0
> 
> 

-- 
Joel