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

[Carl Love <cel@us.ibm.com>]

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