From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72867 invoked by alias); 4 May 2019 08:30:44 -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 72778 invoked by uid 89); 4 May 2019 08:30:35 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=AWL,BAYES_50,KAM_STOCKGEN,SPF_PASS,T_FILL_THIS_FORM_SHORT autolearn=no version=3.3.1 spammy=1824, H*f:sk:83muk4q, 0x12e1f36, H*f:sk:83zho4o 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; Sat, 04 May 2019 08:30:34 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47354) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMq3y-0005q8-6I; Sat, 04 May 2019 04:30:30 -0400 Received: from [176.228.60.248] (port=3042 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hMq3x-0001AJ-8b; Sat, 04 May 2019 04:30:30 -0400 Date: Sat, 04 May 2019 08:30:00 -0000 Message-Id: <835zqqmxk9.fsf@gnu.org> From: Eli Zaretskii To: Kevin Buettner CC: gdb-patches@sourceware.org, simark@simark.ca In-reply-to: <20190502163015.507e652b@f29-4.lan> (message from Kevin Buettner on Thu, 2 May 2019 16:30:15 -0700) Subject: Re: The 'cold' function attribute and GDB 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> 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/msg00125.txt.bz2 > Date: Thu, 2 May 2019 16:30:15 -0700 > From: Kevin Buettner > Cc: Eli Zaretskii , simark@simark.ca > > #2 0x012e1f3b in print_vectorlike.cold () at print.c:1824 > > This behavior is, apparently, intentional. The function > build_address_symbolic in printcmd.c contains the following > statements; in particular note the second comment: > > if (msymbol.minsym != NULL) > { > if (BMSYMBOL_VALUE_ADDRESS (msymbol) > name_location || symbol == NULL) > { > /* If this is a function (i.e. a code address), strip out any > non-address bits. For instance, display a pointer to the > first instruction of a Thumb function as ; the > second instruction will be , even though the > pointer is . This matches the ISA behavior. */ > if (MSYMBOL_TYPE (msymbol.minsym) == mst_text > || MSYMBOL_TYPE (msymbol.minsym) == mst_text_gnu_ifunc > || MSYMBOL_TYPE (msymbol.minsym) == mst_file_text > || MSYMBOL_TYPE (msymbol.minsym) == mst_solib_trampoline) > addr = gdbarch_addr_bits_remove (gdbarch, addr); > > /* The msymbol is closer to the address than the symbol; > use the msymbol instead. */ > symbol = 0; > name_location = BMSYMBOL_VALUE_ADDRESS (msymbol); > if (do_demangle || asm_demangle) > name_temp = MSYMBOL_PRINT_NAME (msymbol.minsym); > else > name_temp = MSYMBOL_LINKAGE_NAME (msymbol.minsym); > } > } > > When I traced it, prior to getting to the outer if statement, > name_location contained the address of 'print_vectorlike' and > name_temp was set to "print_vectorlike". So, if we were to > *not* execute this code, we wouldn't use the minimal symbol. > > To test this, I disabled the code above via #if 0 ... #endif. Here's > what I see when I do this: > > (gdb) x/i 0x12e1f36 > 0x12e1f36 : call 0x12e7b40 > > I didn't see this behavior on my Linux build of emacs due to the fact > that the .cold symbol was placed at an address that's lower than that > of the non-cold symbol. > > With all of that said, I don't think it actually helps with the > backtrace problem. It appears that build_address_symbolic is only > used for disassembly. After poking around, however, I think the > equivalent bit of code may be found in find_frame_funname in stack.c. > The hunk of code which you'll want to disable is: > > if (msymbol.minsym != NULL > && (BMSYMBOL_VALUE_ADDRESS (msymbol) > > BLOCK_ENTRY_PC (SYMBOL_BLOCK_VALUE (func)))) > { > /* We also don't know anything about the function besides > its address and name. */ > func = 0; > funname.reset (xstrdup (MSYMBOL_PRINT_NAME (msymbol.minsym))); > *funlang = MSYMBOL_LANGUAGE (msymbol.minsym); > } > > Doing this sort of thing - preferring the minimal symbol over the > the symbol might make sense for displaying assembly addresses - but > I'm not convinced that it makes sense for printing frame functions. > > It would be possible to disable that code only when the frame pc > is in a block which is in discontiguous block. If someone thinks > this is a good idea, I can provide a patch, but someone else will > need to test it. Thanks for the analysis. Do you want me to test some patch? And why doesn't the GNU/Linux executable have this minimal symbol in the first place, btw?