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 96EF4385842F for ; Thu, 16 Dec 2021 21:13:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 96EF4385842F Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-421-R7Z3fKW-O46HVveX-DBPew-1; Thu, 16 Dec 2021 16:12:58 -0500 X-MC-Unique: R7Z3fKW-O46HVveX-DBPew-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6BB7F9252C; Thu, 16 Dec 2021 21:12:57 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.17.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 256316EC4F; Thu, 16 Dec 2021 21:12:55 +0000 (UTC) From: Florian Weimer To: Mathieu Desnoyers Cc: libc-alpha , Simon Marchi , gdb@sourceware.org Subject: Re: rseq and gdb References: <1507387605.36435.1639688959308.JavaMail.zimbra@efficios.com> Date: Thu, 16 Dec 2021 22:12:54 +0100 In-Reply-To: <1507387605.36435.1639688959308.JavaMail.zimbra@efficios.com> (Mathieu Desnoyers's message of "Thu, 16 Dec 2021 16:09:19 -0500 (EST)") Message-ID: <87wnk4fe3t.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, 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@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Dec 2021 21:13:06 -0000 * Mathieu Desnoyers: > I suspect that gdb should ideally do something to allow it to > single-step through rseq critical sections. In librseq [1], we emit > the __rseq_cs_ptr_array and __rseq_exit_point_array sections to allow > gdb to know about rseq critical sections and skip over those critical > sections as needed. Otherwise single-stepping over each instruction of > a rseq critical section will loop forever. That's probably something that should be expressed in the DWARF data. > Now that glibc plans to enable rseq by default starting with glibc 2.35, > it appears to be a good timing to raise this topic with the gdb community. It's less of an issue than the CRIU problem that we discussed because it will only affect attempts to debug actually rseq-using applications. (The CRIU problem affects everything.) Not saying that debugging support isn't important, just trying to put it into perspective. 8-) Thanks, Florian