The 'cold' function attribute and GDB

[Eli Zaretskii]

> Date: Thu, 2 May 2019 16:30:15 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 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 <function>; the
> 	     second instruction will be <function+2>, even though the
> 	     pointer is <function+3>.  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 <print_vectorlike+1096213>:	call   0x12e7b40 <emacs_abort>
> 
> 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?