Re: The 'cold' function attribute and GDB

Kevin Buettner
2019-05-06T16:24:43Z

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