From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31268 invoked by alias); 29 Feb 2020 04:49:55 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 31260 invoked by uid 89); 29 Feb 2020 04:49:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy= X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 29 Feb 2020 04:49:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582951792; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=q0A3O0ok+tYsutzJJk/zWgk/KH0ooo9r4/54XcN7Acw=; b=a4sX+gzg4G8ckJZ4Yio4P81akh5RXa/mdS8genE4Zi2LGKgjK9Kp0BXosm/VWTwrGoheqg wfbx+RMCAav1aUusY+nyNmy8ZB1C14dniPYYEforYbJLSXHutFrP7sc44I+7hUAADqEtOU k1WzY2fqa0xMza+3j1FWBkPTW4QZU1s= 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-224-xxmb8Qt1Mta2FxNzoSTYyQ-1; Fri, 28 Feb 2020 23:49:50 -0500 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 ACC578017CC; Sat, 29 Feb 2020 04:49:49 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-61.ams2.redhat.com [10.36.116.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E1E2E19E9C; Sat, 29 Feb 2020 04:49:48 +0000 (UTC) From: Florian Weimer To: "J.W. Jagersma" Cc: gcc-help Subject: Re: unwind tables for asm blocks References: <102f4894-2d4f-6a26-2055-eea2f9473fb2@gmail.com> <87o8tictjp.fsf@oldenburg2.str.redhat.com> <0dbd374f-4c0d-6b24-9501-518ad7391746@gmail.com> <871rqetn2r.fsf@oldenburg2.str.redhat.com> Date: Sat, 29 Feb 2020 14:36:00 -0000 In-Reply-To: (J. W. Jagersma's message of "Fri, 28 Feb 2020 23:03:08 +0100") Message-ID: <87eeuero9h.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00168.txt.bz2 * J. W. Jagersma: > On 2020-02-28 22:32, Florian Weimer wrote: >> * J. W. Jagersma: >>=20 >>> The call instruction is just a practical example. The problem I want to >>> address is that no exception handling information is generated at all >>> for asm statements. Other operations, eg. memory access, division, etc >>> could trap and throw an exception. The unwind tables should cover this. >>=20 >> I think permitted uses of asm cannot do anything that would make the >> tables invalid, at least for DWARF unwinding information. > > I don't see how a trapping instruction in asm would invalidate the > unwind table. An explicit call, maybe, but as I said that was only an > example. The problem is that there is no unwind table at all. > >> DWARF does not need to annotate any instruction that might throw (which >> would be every instruction in case of asynchronous unwind tables). > > But it should, if the instruction appears in a try block. Without that > it is impossible to catch the exception. I don't think this is true. DWARF unwind information is range-based, after all. The asm statement will be covered by the unwinding information for the surrounding code. Thanks, Florian