From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 100731 invoked by alias); 28 Aug 2018 15:35:41 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 100713 invoked by uid 89); 28 Aug 2018 15:35:40 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=facto X-HELO: gateway22.websitewelcome.com Received: from gateway22.websitewelcome.com (HELO gateway22.websitewelcome.com) (192.185.47.79) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 28 Aug 2018 15:35:39 +0000 Received: from cm14.websitewelcome.com (cm14.websitewelcome.com [100.42.49.7]) by gateway22.websitewelcome.com (Postfix) with ESMTP id A306F135B0 for ; Tue, 28 Aug 2018 10:35:37 -0500 (CDT) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id ug1pfGeRMkBj6ug1pfUcJD; Tue, 28 Aug 2018 10:35:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=nm2WXy+s16AQxKnO7fqkdtKoO3mXGsywBfKt6tNNPU8=; b=tR7+g9xVrjHRLmBb3eEB8MwmsY 2rb1p1S4kkj31Jq/i3Z9ao/Q5YjQVem5c2dmw8MqZCpbDbKz0f6Fp5+AmmRqCuNE466KWyVR8yPwH luEIzqgs6m8hBMf5Jt6+lLsWl; Received: from 75-166-85-72.hlrn.qwest.net ([75.166.85.72]:46892 helo=pokyo) by box5379.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fug1p-001TsT-Bf; Tue, 28 Aug 2018 10:35:37 -0500 From: Tom Tromey To: Simon Marchi Cc: John Darrington , gdb-patches@sourceware.org Subject: Re: [PATCH 3/3] GDB: New target s12z References: <20180823173526.26144-1-john@darrington.wattle.id.au> <20180823173526.26144-3-john@darrington.wattle.id.au> <20180826174127.g2qht4j3tqtpxfmz@jocasta.intra> <510acbee-2338-0c20-8e32-8d6ef83be3e1@simark.ca> Date: Tue, 28 Aug 2018 15:35:00 -0000 In-Reply-To: <510acbee-2338-0c20-8e32-8d6ef83be3e1@simark.ca> (Simon Marchi's message of "Sun, 26 Aug 2018 14:15:03 -0400") Message-ID: <87pny27bcn.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-08/txt/msg00684.txt.bz2 >>>>> "Simon" == Simon Marchi writes: Simon> The usual thing to do (I looked at a few other arches) is to use the same value as the Simon> canonical frame address as defined by DWARF (Section 6.4 in DWARF5.pdf), which is the Simon> value of the stack pointer just before that frame was created. Simon> This is of course not mandatory, but I suppose that adhering to this de facto rule could Simon> make things clearer. ISTR there was one obscure case where it was necessary -- I think some architectures have a special epilogue unwinder, and it was important that this unwinder agree with the DWARF unwinder about the CFA in some case. This was many years ago so as you can tell I don't really recall the details. Anyway, I think using the current frame's SP will fail if the function uses alloca -- the frame id will change across a step. The CFA is usually used in order to make the frame id invariant. There may be a comment in one of the frame*.h files explaining this. Tom