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: John Baldwin <jhb at freebsd dot org>
- To: Yao Qi <qiyaoltc at gmail dot com>
- Cc: gdb-patches at sourceware dot org, Simon Marchi <simon dot marchi at polymtl dot ca>, Phil Muldoon <pmuldoon at redhat dot com>
- Date: Thu, 13 Jul 2017 10:04:19 -0700
- 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> <2907792.3mtlvelY3m@ralph.baldwin.cx> <86y3rsp991.fsf@gmail.com>
On Thursday, July 13, 2017 05:55:06 PM Yao Qi wrote:
> John Baldwin <jhb@freebsd.org> 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