Re: The 'cold' function attribute and GDB

[Eli Zaretskii <eliz@gnu.org>]

> Cc: gdb-patches@sourceware.org
> From: Simon Marchi <simark@simark.ca>
> Date: Thu, 2 May 2019 14:08:02 -0400
> 
> In my case, the second range, the cold one, is one instruction long, just the call to emacs_abort:
> 
> 00000000004173b1 <print_vectorlike.cold>:
>   4173b1:       e8 77 ce ff ff          callq  41422d <emacs_abort>

Probably because yours is a 64-bit build.  Mine is a 32-bit one.

> Can you give the steps to reproduce the bug that leads us there?

It's a bit tricky (my reproduction recipe is based on a bug, but it
only rears its head on Windows, we will need to simulate on your
system).

In a nutshell, you need to put a breakpoint in this routine, run Emacs
as usual, and when it breaks, make the PSEUDOVECTOR_TYPE macro to
return something that doesn't match any of the cases in the switch.
For example, make it return PVEC_FREE (whose numerical value is 1).  I
think the easiest will be to use nexti through the code that invokes
PSEUDOVECTOR_TYPE, then assign 1 to the register that gets the result.
You should see the code then fall through to emacs_abort.

To force Emacs to call this function, type this after starting Emacs:

  C-h v char-script-table RET

(I assume you are familiar with the notation like C-h and RET.)

> In the mean time, I tried to do "start", followed by "set $pc = 0x4173b1", and this is what I get as my
> first frame:
> 
> #0  0x00000000004173b1 in print_vectorlike (obj=0x1, printcharfun=0x7fffffffdd18, escapeflag=<optimized out>, buf=0xa0 <error: Cannot access memory at address 0xa0>) at /home/smarchi/src/emacs/src/print.c:1824
> 
> The parameter values are bogus, and the rest of the frames are corrupted, because I don't have
> the stack I would normally have when executing this code.  But we can see that the full symbol
> was found: the arguments are printed, and the function name is correct (doesn't include .cold).
> 
> So it looks like some debugging of this problem on Windows will be needed :(

Why am I not surprised?

So some description of how GDB finds its way back from $pc to
print_vectorlike using the DW ranges, with pointers to relevant code,
will be appreciated.

Thanks.