From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45135 invoked by alias); 2 May 2019 18:08:06 -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 44903 invoked by uid 89); 2 May 2019 18:08:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 02 May 2019 18:08:04 +0000 Received: from [172.16.0.120] (192-222-157-41.qc.cable.ebox.net [192.222.157.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id C0E481E47D; Thu, 2 May 2019 14:08:02 -0400 (EDT) Subject: Re: The 'cold' function attribute and GDB To: Eli Zaretskii , Kevin Buettner Cc: gdb-patches@sourceware.org References: <83wojaovbp.fsf@gnu.org> <077aee8c-7bef-bad6-a6a1-e69f116cc18b@simark.ca> <20190501195113.69aea752@f30-4.lan> <20190502002644.5e40b489@f29-4.lan> <83lfzoq3ly.fsf@gnu.org> <20190502085919.63b2d520@f29-4.lan> <83bm0kpzy9.fsf@gnu.org> From: Simon Marchi Message-ID: <54a14b11-3c1d-956c-916c-e8ecae85a78e@simark.ca> Date: Thu, 02 May 2019 18:08:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <83bm0kpzy9.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00046.txt.bz2 On 2019-05-02 12:45 p.m., Eli Zaretskii wrote: >> Date: Thu, 2 May 2019 08:59:19 -0700 >> From: Kevin Buettner >> Cc: gdb-patches@sourceware.org, simark@simark.ca >> >>> This is with GCC 8.2.0, btw. >> >> I'll give this a try. >> >> I have GCC 8.3.1 and 9.0.1 readily available. Do you think it's >> important to use 8.2.0 ? I just built gcc from git, and built emacs with it, and I get pretty much the same ranges as you: <1><66a91b>: Abbrev Number: 141 (DW_TAG_subprogram) <66a91d> DW_AT_name : (indirect string, offset: 0xf3fe3): print_vectorlike <66a921> DW_AT_decl_file : 1 <66a922> DW_AT_decl_line : 1365 <66a924> DW_AT_decl_column : 1 <66a925> DW_AT_prototyped : 1 <66a925> DW_AT_type : <0x65a0ff> <66a929> DW_AT_ranges : 0x234cf0 <66a92d> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) <66a92f> DW_AT_GNU_all_call_sites: 1 <66a92f> DW_AT_sibling : <0x66cf15> And the ranges: 00234cf0 000000000057da80 000000000057e88f 00234cf0 00000000004173b1 00000000004173b6 00234cf0 In my case, the second range, the cold one, is one instruction long, just the call to emacs_abort: 00000000004173b1 : 4173b1: e8 77 ce ff ff callq 41422d Can you give the steps to reproduce the bug that leads us there? In the mean time, I tried to do "start", followed by "set $pc = 0x4173b1", and this is what I get as my first frame: #0 0x00000000004173b1 in print_vectorlike (obj=0x1, printcharfun=0x7fffffffdd18, escapeflag=, buf=0xa0 ) at /home/smarchi/src/emacs/src/print.c:1824 The parameter values are bogus, and the rest of the frames are corrupted, because I don't have the stack I would normally have when executing this code. But we can see that the full symbol was found: the arguments are printed, and the function name is correct (doesn't include .cold). So it looks like some debugging of this problem on Windows will be needed :( Simon