From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21503 invoked by alias); 1 May 2019 20:17:09 -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 21495 invoked by uid 89); 1 May 2019 20:17:09 -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=fell, UD:p.m, p.m, pm 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; Wed, 01 May 2019 20:17:07 +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 3F6F41E47D; Wed, 1 May 2019 16:17:05 -0400 (EDT) Subject: Re: The 'cold' function attribute and GDB To: Eli Zaretskii , gdb-patches@sourceware.org References: <83wojaovbp.fsf@gnu.org> From: Simon Marchi Message-ID: <077aee8c-7bef-bad6-a6a1-e69f116cc18b@simark.ca> Date: Wed, 01 May 2019 20:17: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: <83wojaovbp.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00020.txt.bz2 On 2019-05-01 2:58 p.m., Eli Zaretskii wrote: > If some functions in your program are declared with > __attribute__((cold)), GCC generates local symbols of the form > FOO.cold, where FOO is a function that has a code path which > eventually calls one of the 'cold' functions. When GDB needs to show > a backtrace or a stack frame inside one of these code paths, it shows > FOO.cold as the name of the function. Here's a real-life example: > > Thread 1 received signal SIGTRAP, Trace/breakpoint trap. > 0x76a63227 in KERNELBASE!DebugBreak () from C:\Windows\syswow64\KernelBase.dll > (gdb) thread 1 > [Switching to thread 1 (Thread 7552.0x172c)] > #0 0x76a63227 in KERNELBASE!DebugBreak () > from C:\Windows\syswow64\KernelBase.dll > (gdb) up > #1 0x012e7b89 in emacs_abort () at w32fns.c:10768 > 10768 DebugBreak (); > (gdb) > #2 0x012e1f3b in print_vectorlike.cold () at print.c:1824 <<<<<<<<<<<<<<<< > 1824 emacs_abort (); > (gdb) bt > #0 0x76a63227 in KERNELBASE!DebugBreak () > from C:\Windows\syswow64\KernelBase.dll > #1 0x012e7b89 in emacs_abort () at w32fns.c:10768 > #2 0x012e1f3b in print_vectorlike.cold () at print.c:1824 <<<<<<<<<<<<<<<< > #3 0x011d2dec in print_object (obj=, printcharfun=XIL(0), > escapeflag=true) at print.c:2150 The way this is written: print_vectorlike.cold () makes me thing that GDB didn't find a full symbol (DWARF symbol) for this address, so fell back on the nearest preceding minimal symbol (ELF symbol). I say this because it lacks the arguments here, but it does accept some parameter in the code. If GDB had found the full symbol, it should show the arguments, and the function name, print_vectorlike. So I would inspect the DWARF info generated by gcc for the print_vectorlike function to see what GDB is working with, it will be easier to know where to search. In particular, how does the DWARF info describe the address range or ranges taken by the print_vectorlike function? In an ideal world, if gcc generates two separate ranges of instruction for this function (the hot path and the cold path), it should describe it as two ranges in the entry for print_vectorlike. If so, it should be described with a DW_AT_ranges attribute. If you are not sure what to look for, try to find the debug info entry for print_vectorlike and paste it here. Also, which commit of GDB is this with? I recall some patches related to non-contiguous address ranges not too long ago. > There's a print_vectorlike function in Emacs, and it calls > emacs_abort, which is declared 'cold' (because it is called in case of > fatal errors and doesn't return). > > Since the 'cold' functions tend to be those that are called in case of > some calamity, and since GDB is likely to be used to debug such > calamities, and the user is likely to put breakpoint in such 'cold' > functions precisely to catch these calamities, the above is not such a > rare use case as far as real-life use of GDB goes. > > I think this display is confusing, but is there any reasonable way for > GDB not to expose these symbols to the user? I guess that it would be possible to handle specially minimal symbols named something.cold, but it should not be necessary if we have good debug info and use it correctly, so I would prefer not to go that route. Simon