The 'cold' function attribute and GDB

Kevin Buettner kevinb@redhat.com
Mon May 6 16:24:00 GMT 2019


On Mon, 06 May 2019 18:33:37 +0300
Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 5 May 2019 13:04:03 -0700
> > From: Kevin Buettner <kevinb@redhat.com>
> > Cc: Eli Zaretskii <eliz@gnu.org>, simark@simark.ca
> > 
> > My patch is below.  If it works for you and the approach seems sound,
> > I'll work on a test case which doesn't depend on gcc placing the
> > .cold section after the entry pc.  
> 
> The patch fixes the backtrace, thanks.

Thanks for testing it.  I'll begin working on a test case.

> The output from "info line" still references the .cold symbol,
> though.  I think this was not so on GNU/Linux?  Is it also by sheer
> luck, because of the order of the 'cold' symbols in the executable?

The address printed by "info line" is constructed by
build_address_symbolic in printcmd.c.  It contains code similar
to that in find_frame_funname.

You recall correctly - GNU/Linux did not display the .cold symbol when
using the "info line" command.  The GNU/Linux executable that I
examined does have .cold symbols, but (at least at the examples I saw)
placed them at addresses lower than the corresponding function.

[ .cold symbols at lower addresses is also an interesting case, causing
all sorts of problems when I first started looking at the non-contiguous
range problem.  GDB had assumed that the lowest address might also
be a start address. ]

I'll amend my patch to also  address the "info line" problem too.
(Though for that one, it doesn't bother my quite as much to see the
minimal symbol.)

Kevin



More information about the Gdb-patches mailing list