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

On 11/9/21 6:29 PM, Kevin Buettner wrote:
> 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.

Well, how about this one?  Does it reproduce for you, also in source
file mode ("if { 1 }" -> "if { 0 }" in the case-case) ?

[ I think there is some standard way of choosing between source and
assembly mode rather than using 1 or 0, but I can't find it. ]

Thanks,
- Tom