This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/2] Include the fs_base and gs_base registers in amd64 target descriptions.
- From: Simon Marchi <simon dot marchi at polymtl dot ca>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: Phil Muldoon <pmuldoon at redhat dot com>, John Baldwin <jhb at freebsd dot org>, gdb-patches at sourceware dot org
- Date: Wed, 12 Jul 2017 15:50:58 +0200
- Subject: Re: [PATCH 1/2] Include the fs_base and gs_base registers in amd64 target descriptions.
- Authentication-results: sourceware.org; auth=none
- References: <20170627224948.99138-1-jhb@FreeBSD.org> <20170627224948.99138-2-jhb@FreeBSD.org> <86shi3qu5m.fsf@gmail.com> <af880ea9-5184-a6d8-97e4-09aa1a014761@redhat.com> <CAH=s-PPM7u=f=_4k+=wLvv4z822VJRqbkxrsSv9C0eKqX-tMCA@mail.gmail.com>
On 2017-07-12 15:02, Yao Qi wrote:
On Wed, Jul 12, 2017 at 1:16 PM, Phil Muldoon <pmuldoon@redhat.com>
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