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

[Tom de Vries <tdevries@suse.de>]

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,
- Tom