From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 37238 invoked by alias); 2 May 2019 18:47:30 -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 37228 invoked by uid 89); 2 May 2019 18:47:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=ch, simulate 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; Thu, 02 May 2019 18:47:28 +0000 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49576) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hMGju-0001Mc-3m; Thu, 02 May 2019 14:47:26 -0400 Received: from [176.228.60.248] (port=2666 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hMGjp-0004EG-2I; Thu, 02 May 2019 14:47:23 -0400 Date: Thu, 02 May 2019 18:47:00 -0000 Message-Id: <831s1gpuch.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi CC: kevinb@redhat.com, gdb-patches@sourceware.org In-reply-to: <54a14b11-3c1d-956c-916c-e8ecae85a78e@simark.ca> (message from Simon Marchi on Thu, 2 May 2019 14:08:02 -0400) 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> <20190502002644.5e40b489@f29-4.lan> <83lfzoq3ly.fsf@gnu.org> <20190502085919.63b2d520@f29-4.lan> <83bm0kpzy9.fsf@gnu.org> <54a14b11-3c1d-956c-916c-e8ecae85a78e@simark.ca> 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/msg00049.txt.bz2 > Cc: gdb-patches@sourceware.org > From: Simon Marchi > 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 : > 4173b1: e8 77 ce ff ff callq 41422d 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=, buf=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.