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

John Baldwin
2017-07-13T17:04:34Z

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