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

[Kevin Buettner <kevinb@redhat.com>]

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) 

I'm guessing that _exit looks different in your environment?

Kevin