From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111351 invoked by alias); 13 Jul 2017 17:04:34 -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 111334 invoked by uid 89); 13 Jul 2017 17:04:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL autolearn=no version=3.3.2 spammy=ancient, Hx-languages-length:1820, yours, among X-HELO: mail.baldwin.cx Received: from bigwig.baldwin.cx (HELO mail.baldwin.cx) (96.47.65.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Jul 2017 17:04:29 +0000 Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id 22E2D10AB01; Thu, 13 Jul 2017 13:04:28 -0400 (EDT) From: John Baldwin To: Yao Qi Cc: gdb-patches@sourceware.org, Simon Marchi , Phil Muldoon Subject: Re: [PATCH 1/2] Include the fs_base and gs_base registers in amd64 target descriptions. Date: Thu, 13 Jul 2017 17:04:00 -0000 Message-ID: <1672448.MbJjpSIYpP@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <86y3rsp991.fsf@gmail.com> References: <20170627224948.99138-1-jhb@FreeBSD.org> <2907792.3mtlvelY3m@ralph.baldwin.cx> <86y3rsp991.fsf@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00158.txt.bz2 On Thursday, July 13, 2017 05:55:06 PM Yao Qi wrote: > John Baldwin writes: > Your patch fixes the crash, but I can't see fs_base and gs_base on my > machine either. Ok. I assume yours is newer than my (ancient) VM and thus this patch doesn't work. > > struct user_reg). What I don't really understand though is why this > > works. I also don't fully understand why 'data->arch_regs' is supposed > > to always hold the same pointer values as in 'target_desc' in > > tdesc_use_registers(). > > because each tdesc_reg is a singleton among the target description. The > reason Simon observed that we have different "fs_base" tdesc_reg added > and removed from the hash table is that they are from different target > descriptions. GDB crashes in tdesc_use_registers. The arguments tdesc > and tdesc_data are not consistent, tdesc is amd64 linux target > description, but tdesc_data was got when tdesc is amd64 target > description, so the tdesc_reg in tdesc_data are from amd64 target > description as well. So, we push a "fs_base" from one target > description and want to remove a "fs_base" from another target > description. > > Does this answer your question? I think maybe there is some "better" > fix that is to keep tdesc and tdes_data consistent. However, I don't > think it further. Since current GDB trunk is unusable on x86_64-linux, > it is better get a fix soon. Ok. I think then that the hash table in tdesc_use_registers shouldn't be using the 'tdesc_reg' as the key but instead use the register name? This should be fairly simple to implement via a std::unordered_map<>. I'll try that in a bit, but if that doesn't resolve it we should revert the commits until we have a real fix. -- John Baldwin