From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wYvzKt1PemL/bQUAWB0awg (envelope-from ) for ; Tue, 10 May 2022 07:43:25 -0400 Received: by simark.ca (Postfix, from userid 112) id A0BDB1E21F; Tue, 10 May 2022 07:43:25 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,MAILING_LIST_MULTI, NICE_REPLY_A,RDNS_DYNAMIC autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id E8F3A1E00D for ; Tue, 10 May 2022 07:43:24 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9BE483959E45 for ; Tue, 10 May 2022 11:43:24 +0000 (GMT) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) by sourceware.org (Postfix) with ESMTPS id 667683959C8D for ; Tue, 10 May 2022 11:43:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 667683959C8D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f41.google.com with SMTP id d5so23422664wrb.6 for ; Tue, 10 May 2022 04:43:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=UmdwkRP17DL93llAFH5ySlkU7X/294/HNdIDtkEvdno=; b=A3sJmEBqsmfWbC7VOLulqSA/Fi18YJ4UmUmQL4T/AK06w/9G1/+SZT4kK6PMorbgvP 8u3WWYYtT0LwMhHfbL2sxk9NBFu/N6xSP+PFqSyVvujgsZ+Yaqhrx1xIbfcGbjez94Ff UVlfP2FOsWnjYfddDPBiFblwd5Cuixql0PatOX3mY2q0pI8/GhX+0koeWp2ZfFLj9G56 op7J2ND383q4WY0kAKdGS8aarcC0RnrOG7S9Aa4onWQpTiTqcv9Nqe5UmtI8IZBwQHlE Kul6JH5rTayYJFLLWMBo0SWr32MrjIiNfmdCuKCf4wDo42dcHjpMGQGvOzhTl8QCHNgj EgsQ== X-Gm-Message-State: AOAM530mVyNw3GRCyiOe9Ld0Y6lpDxVBONRWs/r12igPRSfpCZhuQRop I/h4MG1rjrv1OkkGIxd8ylQ= X-Google-Smtp-Source: ABdhPJwFTs+nPC4HXo9hiO6petDlt75Nm+frPxt6zo5ajdbc/EDq2hAcMn4Mlh/zhOHWsF81rnhnMA== X-Received: by 2002:a5d:618f:0:b0:20c:4cfc:8d72 with SMTP id j15-20020a5d618f000000b0020c4cfc8d72mr18158332wru.14.1652182992086; Tue, 10 May 2022 04:43:12 -0700 (PDT) Received: from ?IPV6:2001:8a0:f924:2600:209d:85e2:409e:8726? ([2001:8a0:f924:2600:209d:85e2:409e:8726]) by smtp.gmail.com with ESMTPSA id x18-20020a5d4912000000b0020c5253d928sm13408815wrq.116.2022.05.10.04.43.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 May 2022 04:43:10 -0700 (PDT) Message-ID: <40d76dce-1331-3af5-f6f2-0de9d956d76c@palves.net> Date: Tue, 10 May 2022 12:43:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH V2] PowerPC: fix for gdb.base/eh_return.exp Content-Language: en-US To: will schmidt , Carl Love , Kevin Buettner , gdb-patches@sourceware.org References: <76bea9ad010a71ea5e2c7fd78f818bdb399810a6.camel@us.ibm.com> <20220506110826.5e16c8b6@f35-zws-1> <70a877cc-2f35-3924-6717-9d519c2730c5@palves.net> <099c8f8d8729a0051f83a034d62c18f03c789167.camel@vnet.ibm.com> <37d2a4b6a57b62662f0417f123bda6ba48066554.camel@vnet.ibm.com> From: Pedro Alves In-Reply-To: <37d2a4b6a57b62662f0417f123bda6ba48066554.camel@vnet.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: , Cc: Rogerio Alves Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 2022-05-09 21:57, will schmidt wrote: > On Mon, 2022-05-09 at 12:17 -0700, Carl Love wrote: >> Will, Pedro, Kevin, GDB maintainers: >> >> Sorry, resend, the first attempt was missing the mailing list. >> >> I have updated the patch per the comments from Will. The new version >> of the patch uses a PowerPC specific gcc option to suppress the >> generation of the Traceback Table information. The Traceback >> information is contained in the .long statements following the last >> instruction in the function. Now the existing test to locate the last >> instruction in the function works without any changes. > > > In this cases the disassembly is presenting the traceback table > contents as .long values, but with an (un)lucky combination of bits, it > may also represent parts of that table as instructions. Thats all > chance on which bits/fields are set. That can show up readily with the > "-mtraceback=full" option, probably unlikely with the default trace > table contents. (tldr; it won't always be represented as .long > 0xfoo...). OOC, does the ABI specify that the size of the function covers the Traceback information as well? I didn't find anything about that, and my initial reading of the wording used in the ABI "following the end of the code" would make me think that it should not. If it wasn't, then of course disassembling a function would not run into the table. Maybe it's done this way today to make it easier on the linker. Regardless, I was wondering whether there's any way for GDB to know that a given PC range is a traceback table, so that it wouldn't try to disassemble such a range as instructions? The ABI you pointed out says: "Compilers should generate a traceback table following the end of the code for every function. Debuggers and exception handlers can locate the traceback tables by scanning forward from the instruction address at the point of interruption. The beginning of the traceback table is marked by a word of zeroes, which is an illegal instruction. If read-only constants are compiled into the same section as the function code, they must follow the traceback table. A word of zeroes as read-only data must not be the first word following the code for a function. A traceback table is word-aligned." Naively, we could use the "word of zeroes" marker to see where the table starts, but it wouldn't work when you're disassembling a PC range instead of the whole function. Is there perhaps some symbol that points to the start of the table, or some section with the list of traceback tables in the program or some such?