Re: [PATCH][gdb/testsuite] Add gdb.opt/break-on-_exit.exp

[Kevin Buettner via Gdb-patches <gdb-patches@sourceware.org>]

On Tue, 9 Nov 2021 17:58:17 +0100
Tom de Vries <tdevries@suse.de> wrote:

> On 11/9/21 5:35 PM, Kevin Buettner wrote:
> > On Thu, 4 Nov 2021 12:20:14 +0100
> > Tom de Vries <tdevries@suse.de> wrote:
> >   
> >> [ was: Re: [PATCH][gdb/testsuite] Work around skip_prologue problems in
> >> gdb.threads/process-dies-while-detaching.exp ]
> >>
> >> On 11/2/21 6:13 PM, Kevin Buettner wrote:  
> >>> On Tue, 2 Nov 2021 12:38:26 +0100
> >>> Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> wrote:
> >>>     
> >>>> On 10/29/21 9:24 PM, Tom de Vries via Gdb-patches wrote:    
> >>>>> Hi,
> >>>>>
> >>>>> On powerpc64le-linux, I run into:
> >>>>> ...
> >>>>> [Inferior 1 (process 5156) exited normally]^M
> >>>>> (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: \
> >>>>>   detach: detach: continue to breakpoint: _exit (the program exited)
> >>>>> ...
> >>>>>
> >>>>> What happens is the following:
> >>>>> - a breakpoint is set on _exit,
> >>>>> - a continue is issued
> >>>>> - the continue is supposed to hit the breakpoint, but instead
> >>>>>   the program exits.
> >>>>>
> >>>>> I traced this down to the breakpoint on _exit being set too far from function
> >>>>> entry.  This is caused by the skip_prologue function (in rs6000-tdep.c)
> >>>>> optimistically ignoring insns it doesn't recognize.  In particular, it walks
> >>>>> past the system call instruction "sc" which initiates the actual exit.
> >>>>>
> >>>>> While this needs fixing,      
> >>>>
> >>>> Filed here: https://sourceware.org/bugzilla/show_bug.cgi?id=28527 .
> >>>>
> >>>> Submitted patch here:
> >>>> https://sourceware.org/pipermail/gdb-patches/2021-November/183016.html .
> >>>>
> >>>> Thanks,
> >>>> - Tom
> >>>>    
> >>>>> we don't want to be testing this behaviour in this
> >>>>> test-case.    
> >>>
> >>> Since you've fixed the problem in skip_prologue(), I'd prefer that this
> >>> testsuite patch not go in.    
> >>
> >> One possible objection would be that otherwise we no longer excercise
> >> the problem, so here's a test-case for that.
> >>
> >> Any comments?  
> > 
> > I've been trying (and failing) to reproduce this by hand on Fedora 35
> > ppc64le.   Here's what I'm doing...
> > 
> > [kev@f35-ppc64le-1 tmp]$ tail -9 break-on-_exit.c 
> > #include <unistd.h>
> > 
> > int
> > main (void)
> > {
> >   _exit (0);
> > 
> >   return 0;
> > }
> > [kev@f35-ppc64le-1 tmp]$ gcc -o break-on-_exit break-on-_exit.c
> > [kev@f35-ppc64le-1 tmp]$ gdb --readnever break-on-_exit 
> > GNU gdb (GDB) Fedora 11.1-2.fc35
> > Copyright (C) 2021 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.
> > Type "show copying" and "show warranty" for details.
> > This GDB was configured as "ppc64le-redhat-linux-gnu".
> > Type "show configuration" for configuration details.
> > For bug reporting instructions, please see:
> > <https://www.gnu.org/software/gdb/bugs/>.
> > Find the GDB manual and other documentation resources online at:
> >     <http://www.gnu.org/software/gdb/documentation/>.
> > 
> > For help, type "help".
> > Type "apropos word" to search for commands related to "word"...
> > Reading symbols from break-on-_exit...
> > (No debugging symbols found in break-on-_exit)
> > (gdb) start
> > Temporary breakpoint 1 at 0x10000708
> > Starting program: /mesquite2/tmp/break-on-_exit 
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib64/libthread_db.so.1".
> > 
> > Temporary breakpoint 1, 0x0000000010000708 in main ()
> > (gdb) b _exit
> > Breakpoint 2 at 0x7ffff7decc1c (2 locations)
> > (gdb) info breakpoints
> > Num     Type           Disp Enb Address            What
> > 2       breakpoint     keep y   <MULTIPLE>         
> > 2.1                         y   0x00007ffff7decc1c <_exit+60>
> > 2.2                         y   0x00007ffff7fc9970 <_exit+64>
> > (gdb) info shared
> > From                To                  Syms Read   Shared Object Library
> > 0x00007ffff7f91080  0x00007ffff7fcc224  Yes (*)     /lib64/ld64.so.2
> > 0x00007ffff7d00a80  0x00007ffff7eaebbc  Yes (*)     /lib64/libc.so.6
> > (*): Shared library is missing debugging information.
> > (gdb) c
> > Continuing.
> > 
> > Breakpoint 2, 0x00007ffff7decc1c in _exit () from /lib64/libc.so.6
> > (gdb) x/20i _exit
> >    0x7ffff7decbe0 <_exit>:	addis   r2,r12,21
> >    0x7ffff7decbe4 <_exit+4>:	addi    r2,r2,-23776
> >    0x7ffff7decbe8 <_exit+8>:	mflr    r0
> >    0x7ffff7decbec <_exit+12>:	nop
> >    0x7ffff7decbf0 <_exit+16>:	std     r29,-24(r1)
> >    0x7ffff7decbf4 <_exit+20>:	std     r31,-8(r1)
> >    0x7ffff7decbf8 <_exit+24>:	ld      r9,-29160(r2)
> >    0x7ffff7decbfc <_exit+28>:	mr      r31,r3
> >    0x7ffff7decc00 <_exit+32>:	std     r30,-16(r1)
> >    0x7ffff7decc04 <_exit+36>:	add     r29,r9,r13
> >    0x7ffff7decc08 <_exit+40>:	ld      r9,-28776(r13)
> >    0x7ffff7decc0c <_exit+44>:	li      r30,-4096
> >    0x7ffff7decc10 <_exit+48>:	mr      r3,r31
> >    0x7ffff7decc14 <_exit+52>:	andis.  r9,r9,16
> >    0x7ffff7decc18 <_exit+56>:	std     r0,16(r1)  
> > => 0x7ffff7decc1c <_exit+60>:	li      r0,234  
> >    0x7ffff7decc20 <_exit+64>:	beq     0x7ffff7decc74 <_exit+148>
> >    0x7ffff7decc24 <_exit+68>:	nop
> >    0x7ffff7decc28 <_exit+72>:	nop
> >    0x7ffff7decc2c <_exit+76>:	ori     r2,r2,0
> > (gdb) 
> >   
> 
> Hi Kevin, thanks for looking into this.
> 
> > I'm guessing that _exit looks different in your environment?  
> 
> Indeed, as show in the log message of commit
> a50bdb99afe3ce2374407cbe7ddc625c1a0b74f7:
> ...
>     Dump of assembler code for function _exit:
>        0x00007ffff7e42ea0 <+0>:     12 00 4c 3c     addis   r2,r12,18
>        0x00007ffff7e42ea4 <+4>:     60 43 42 38     addi    r2,r2,17248
>        0x00007ffff7e42ea8 <+8>:     00 00 00 60     nop
>        0x00007ffff7e42eac <+12>:    f8 ff e1 fb     std     r31,-8(r1)
>        0x00007ffff7e42eb0 <+16>:    78 1b 7f 7c     mr      r31,r3
>        0x00007ffff7e42eb4 <+20>:    f0 ff c1 fb     std     r30,-16(r1)
>        0x00007ffff7e42eb8 <+24>:    ea 00 00 38     li      r0,234
>        0x00007ffff7e42ebc <+28>:    a0 8b 22 e9     ld      r9,-29792(r2)
>        0x00007ffff7e42ec0 <+32>:    78 fb e3 7f     mr      r3,r31
>        0x00007ffff7e42ec4 <+36>:    14 6a c9 7f     add     r30,r9,r13
>        0x00007ffff7e42ec8 <+40>:    02 00 00 44     sc
>        0x00007ffff7e42ecc <+44>:    26 00 00 7c     mfcr    r0
>        0x00007ffff7e42ed0 <+48>:    00 10 09 74     andis.  r9,r0,4096
> ...
> 
> That's is why I put the test-case in the gdb.opt dir: it will excercise
> the code provided by glibc, which tends to be optimized, and different
> across os instances.
> 
> The fact that it's not necessarily reproducible across os instances is
> not great, but OTOH it means that we do exercise real life code (much
> like the original test-case setting a breakpoint on _exit does, but in a
> more minimal way).

Thanks for the clarifications.

I think your new test is okay, though (of course) it would have been
nice to have a test which doesn't depend on particular OS instances.

Kevin