From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8809 invoked by alias); 1 May 2019 18:59:32 -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 8699 invoked by uid 89); 1 May 2019 18:59:32 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=UD:cold, Switching X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (209.51.188.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 May 2019 18:59:31 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hLuS1-00035h-7B for gdb-patches@sourceware.org; Wed, 01 May 2019 14:59:29 -0400 Received: from [176.228.60.248] (port=2536 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hLuRu-0006JE-7O for gdb-patches@sourceware.org; Wed, 01 May 2019 14:59:25 -0400 Date: Wed, 01 May 2019 18:59:00 -0000 Message-Id: <83wojaovbp.fsf@gnu.org> From: Eli Zaretskii To: gdb-patches@sourceware.org Subject: The 'cold' function attribute and GDB X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00018.txt.bz2 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 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?