From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68945 invoked by alias); 12 Jul 2017 13:51:09 -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 68913 invoked by uid 89); 12 Jul 2017 13:51:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 spammy=Phil, Muldoon, muldoon, phil X-HELO: smtp.polymtl.ca Received: from smtp.polymtl.ca (HELO smtp.polymtl.ca) (132.207.4.11) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 12 Jul 2017 13:51:07 +0000 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id v6CDp0mO015618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 12 Jul 2017 09:51:05 -0400 Received: by simark.ca (Postfix, from userid 112) id 4BB081F2A5; Wed, 12 Jul 2017 09:51:00 -0400 (EDT) Received: from simark.ca (localhost [127.0.0.1]) by simark.ca (Postfix) with ESMTP id 1F4891E627; Wed, 12 Jul 2017 09:50:58 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 12 Jul 2017 13:51:00 -0000 From: Simon Marchi To: Yao Qi Cc: Phil Muldoon , John Baldwin , gdb-patches@sourceware.org Subject: Re: [PATCH 1/2] Include the fs_base and gs_base registers in amd64 target descriptions. In-Reply-To: References: <20170627224948.99138-1-jhb@FreeBSD.org> <20170627224948.99138-2-jhb@FreeBSD.org> <86shi3qu5m.fsf@gmail.com> Message-ID: X-Sender: simon.marchi@polymtl.ca User-Agent: Roundcube Webmail/1.3.0 X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 12 Jul 2017 13:51:00 +0000 X-IsSubscribed: yes X-SW-Source: 2017-07/txt/msg00107.txt.bz2 On 2017-07-12 15:02, Yao Qi wrote: > On Wed, Jul 12, 2017 at 1:16 PM, Phil Muldoon > wrote: >> >> Does anyone else see this? >> > > I don't see the issue you posted here, but there are > some regressions shown in buildbot. > https://sourceware.org/ml/gdb-testers/2017-q3/msg00370.html > > John, could you take a look? I looked around, I don't know exactly what's wrong but I might have some pointers. From what I understand, tdesc_use_registers adds the registers listed in the target description to a hash table, and then removes some of those same registers that are also specified by the architecture, so it's left with the registers for which we need to assign a number. The hash table hash the pointer itself, it does not look at what it points to. I added some prints where we add and remove the registers from the htab. For rax, it looks good: ADDING 0x237a510 rax REMOVING 0x237a510 rax We add and remov the same pointer. For fs_base, the pointers are different: ADDING 0x237d840 fs_base REMOVING 0x23a5d70 fs_base It suggests that something is wrong here, I would expect those two pointers to be equal. I don't know enough about how the reg objects are created to know why it this happens. Despite that, a segfault happens when we are calling htab_remove_elt with an element that does not exist in the hash table. This case should be handled correctly, since this function allows that: 707 /* This function deletes an element with the given value from hash 708 table (the hash is computed from the element). If there is no matching 709 element in the hash table, this function does nothing. */ 710 711 void 712 htab_remove_elt (htab_t htab, PTR element) The problem seems to be in htab_remove_elt_with_hash: 727 slot = htab_find_slot_with_hash (htab, element, hash, NO_INSERT); 728 if (*slot == HTAB_EMPTY_ENTRY) 729 return; htab_find_slot_with_hash can return NULL if you pass NO_INSERT and the element is non-existent. So it looks like it's missing a slot != NULL on line 728. Hope that helps. Simon