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.129.124]) by sourceware.org (Postfix) with ESMTPS id 946FD3858430 for ; Tue, 9 Nov 2021 16:35:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 946FD3858430 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-265-DPkIrN6JPsG-NgOwV-at2Q-1; Tue, 09 Nov 2021 11:35:19 -0500 X-MC-Unique: DPkIrN6JPsG-NgOwV-at2Q-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2A74A1922023; Tue, 9 Nov 2021 16:35:18 +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 E8D9F19C59; Tue, 9 Nov 2021 16:35:17 +0000 (UTC) Date: Tue, 9 Nov 2021 09:35:17 -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: <20211109093517.2d6f07d3@f35-m3> In-Reply-To: <33a30d8d-247e-fba8-c9f1-b8ff0bd001b2@suse.de> References: <20211029192419.GA26416@delia> <2cc5e63d-5be1-a5c7-b1cd-6058223a5a19@suse.de> <20211102101329.565a324b@f35-m1> <33a30d8d-247e-fba8-c9f1-b8ff0bd001b2@suse.de> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.6 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_H4, RCVD_IN_MSPIKE_WL, 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 16:35:36 -0000 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 ] >=20 > 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: > > =20 > >> On 10/29/21 9:24 PM, Tom de Vries via Gdb-patches wrote: =20 > >>> Hi, > >>> > >>> On powerpc64le-linux, I run into: > >>> ... > >>> [Inferior 1 (process 5156) exited normally]^M > >>> (gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-proc= ess: \ > >>> 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, i= t walks > >>> past the system call instruction "sc" which initiates the actual exit= . > >>> > >>> While this needs fixing, =20 > >> > >> Filed here: https://sourceware.org/bugzilla/show_bug.cgi?id=3D28527 . > >> > >> Submitted patch here: > >> https://sourceware.org/pipermail/gdb-patches/2021-November/183016.html= . > >> > >> Thanks, > >> - Tom > >> =20 > >>> we don't want to be testing this behaviour in this > >>> test-case. =20 > >=20 > > Since you've fixed the problem in skip_prologue(), I'd prefer that this > > testsuite patch not go in. =20 >=20 > One possible objection would be that otherwise we no longer excercise > the problem, so here's a test-case for that. >=20 > 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=20 #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=20 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=20 [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 =20 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>:=09addis r2,r12,21 0x7ffff7decbe4 <_exit+4>:=09addi r2,r2,-23776 0x7ffff7decbe8 <_exit+8>:=09mflr r0 0x7ffff7decbec <_exit+12>:=09nop 0x7ffff7decbf0 <_exit+16>:=09std r29,-24(r1) 0x7ffff7decbf4 <_exit+20>:=09std r31,-8(r1) 0x7ffff7decbf8 <_exit+24>:=09ld r9,-29160(r2) 0x7ffff7decbfc <_exit+28>:=09mr r31,r3 0x7ffff7decc00 <_exit+32>:=09std r30,-16(r1) 0x7ffff7decc04 <_exit+36>:=09add r29,r9,r13 0x7ffff7decc08 <_exit+40>:=09ld r9,-28776(r13) 0x7ffff7decc0c <_exit+44>:=09li r30,-4096 0x7ffff7decc10 <_exit+48>:=09mr r3,r31 0x7ffff7decc14 <_exit+52>:=09andis. r9,r9,16 0x7ffff7decc18 <_exit+56>:=09std r0,16(r1) =3D> 0x7ffff7decc1c <_exit+60>:=09li r0,234 0x7ffff7decc20 <_exit+64>:=09beq 0x7ffff7decc74 <_exit+148> 0x7ffff7decc24 <_exit+68>:=09nop 0x7ffff7decc28 <_exit+72>:=09nop 0x7ffff7decc2c <_exit+76>:=09ori r2,r2,0 (gdb)=20 I'm guessing that _exit looks different in your environment? Kevin