From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38658 invoked by alias); 2 May 2019 19:45:24 -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 38581 invoked by uid 89); 2 May 2019 19:45:15 -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= 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; Thu, 02 May 2019 19:45:13 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6C2B770D67; Thu, 2 May 2019 19:45:10 +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 3739F5D70A; Thu, 2 May 2019 19:45:10 +0000 (UTC) Date: Thu, 02 May 2019 19:45: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: <20190502124509.0d2c546c@f29-4.lan> In-Reply-To: <83y33oodv2.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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00055.txt.bz2 On Thu, 02 May 2019 22:28:17 +0300 Eli Zaretskii wrote: > > Date: Thu, 2 May 2019 12:13:05 -0700 > > From: Kevin Buettner > > Cc: gdb-patches@sourceware.org, simark@simark.ca > > > > I hadn't checked before, but I do see .cold symbols... > > > > emacs:000000000058cab0 t print_vectorlike > > emacs:000000000041fed1 t print_vectorlike.cold > > > > The address for print_vectorlike.cold is exactly the address for the > > second address range for print_vectorlike: > > > > Address range 0x41fed1 to 0x41fed6: > > 0x000000000041fed1 <+-1493983>: callq 0x41cca5 > > > > It's interesting that this _doesn't_ show up when doing the following: > > > > (gdb) x/i 0x000000000041fed1 > > 0x41fed1 : callq 0x41cca5 > > > > > > What do you see when you issue a similar command for your build > > of emacs on Windows? (Apologies if you've already shown this to > > me.) > > "nm -A" shows this: > > 011d6521 t _print_vectorlike > 012e1ce5 t _print_vectorlike.cold.65 > > And GDB shows this: > > (gdb) x/i 0x012e1ce5 > 0x12e1ce5 : movl $0xf5,0x8(%esp) What I (think I) actually want to see is "x/i 0x012e1f36". This is the address corresponding to the call of emacs_abort in the second address range. What I want to see is whether print_vectorlike.cold.65 is used to print the address. If so, it should be possible to debug this problem without needing to actually run it. Looking back at your earlier email where you provided me with the output of the disassemble command, i just noticed something odd: > Address range 0x12e1ce5 to 0x12e1f3b: > 1824 emacs_abort (); > 0x012e1f36 <+593>: call 0x12e7b40 The address range includes more addresses than are shown. I would have expected the range to be something like "0x012e1f36 to 0x12e1f3b" instead of starting at 0x12e1ce5 as shown. Kevin