From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 7E2B23858404 for ; Tue, 9 Nov 2021 17:29:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7E2B23858404 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-460-ewVv_lHjOqy0SPUMWXZEqw-1; Tue, 09 Nov 2021 12:29:08 -0500 X-MC-Unique: ewVv_lHjOqy0SPUMWXZEqw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 733741023F4E; Tue, 9 Nov 2021 17:29:07 +0000 (UTC) Received: from f35-m3 (ovpn-112-180.phx2.redhat.com [10.3.112.180]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4E4A760843; Tue, 9 Nov 2021 17:29:07 +0000 (UTC) Date: Tue, 9 Nov 2021 10:29:06 -0700 From: Kevin Buettner To: Tom de Vries Cc: gdb-patches@sourceware.org Subject: Re: [PATCH][gdb/testsuite] Add gdb.opt/break-on-_exit.exp Message-ID: <20211109102906.6d2b6e78@f35-m3> In-Reply-To: <88bedd77-01f5-a5d3-694e-aa8410113f49@suse.de> References: <20211029192419.GA26416@delia> <2cc5e63d-5be1-a5c7-b1cd-6058223a5a19@suse.de> <20211102101329.565a324b@f35-m1> <33a30d8d-247e-fba8-c9f1-b8ff0bd001b2@suse.de> <20211109093517.2d6f07d3@f35-m3> <88bedd77-01f5-a5d3-694e-aa8410113f49@suse.de> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2021 17:29:15 -0000 On Tue, 9 Nov 2021 17:58:17 +0100 Tom de Vries wrote: > On 11/9/21 5:35 PM, Kevin Buettner wrote: > > On Thu, 4 Nov 2021 12:20:14 +0100 > > Tom de Vries 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 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 > > > > 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 > > 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: > > . > > Find the GDB manual and other documentation resources online at: > > . > > > > 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 > > 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