Re: [PATCH 1/2] Include the fs_base and gs_base registers in amd64 target descriptions.

[John Baldwin <jhb@freebsd.org>]

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