From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28409 invoked by alias); 6 May 2019 16:24:43 -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 28400 invoked by uid 89); 6 May 2019 16:24:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.8 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=HX-Languages-Length:1556, printcmdc, UD:printcmd.c, printcmd.c X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 06 May 2019 16:24:41 +0000 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 mx1.redhat.com (Postfix) with ESMTPS id B01C83092656; Mon, 6 May 2019 16:24:39 +0000 (UTC) Received: from f29-4.lan (ovpn-116-84.phx2.redhat.com [10.3.116.84]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6E4F817C4F; Mon, 6 May 2019 16:24:39 +0000 (UTC) Date: Mon, 06 May 2019 16:24:00 -0000 From: Kevin Buettner To: Eli Zaretskii Cc: gdb-patches@sourceware.org, simark@simark.ca Subject: Re: The 'cold' function attribute and GDB Message-ID: <20190506092438.18ce3772@f29-4.lan> In-Reply-To: <83imunk372.fsf@gnu.org> References: <83wojaovbp.fsf@gnu.org> <077aee8c-7bef-bad6-a6a1-e69f116cc18b@simark.ca> <20190501195113.69aea752@f30-4.lan> <20190502003849.6759d177@f29-4.lan> <83muk4q3rr.fsf@gnu.org> <20190502112517.64b6fa20@f29-4.lan> <83zho4ofkh.fsf@gnu.org> <20190502121305.111b5fdc@f29-4.lan> <83y33oodv2.fsf@gnu.org> <20190502124509.0d2c546c@f29-4.lan> <83sgtwock8.fsf@gnu.org> <20190502163015.507e652b@f29-4.lan> <835zqqmxk9.fsf@gnu.org> <20190505130403.56de7f08@f29-4.lan> <83imunk372.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00170.txt.bz2 On Mon, 06 May 2019 18:33:37 +0300 Eli Zaretskii wrote: > > Date: Sun, 5 May 2019 13:04:03 -0700 > > From: Kevin Buettner > > Cc: Eli Zaretskii , simark@simark.ca > > > > My patch is below. If it works for you and the approach seems sound, > > I'll work on a test case which doesn't depend on gcc placing the > > .cold section after the entry pc. > > The patch fixes the backtrace, thanks. Thanks for testing it. I'll begin working on a test case. > The output from "info line" still references the .cold symbol, > though. I think this was not so on GNU/Linux? Is it also by sheer > luck, because of the order of the 'cold' symbols in the executable? The address printed by "info line" is constructed by build_address_symbolic in printcmd.c. It contains code similar to that in find_frame_funname. You recall correctly - GNU/Linux did not display the .cold symbol when using the "info line" command. The GNU/Linux executable that I examined does have .cold symbols, but (at least at the examples I saw) placed them at addresses lower than the corresponding function. [ .cold symbols at lower addresses is also an interesting case, causing all sorts of problems when I first started looking at the non-contiguous range problem. GDB had assumed that the lowest address might also be a start address. ] I'll amend my patch to also address the "info line" problem too. (Though for that one, it doesn't bother my quite as much to see the minimal symbol.) Kevin