Re: [PATCH] Fix sizes and types of x86 segment and x87 registers

[John Baldwin <jhb at FreeBSD dot org>]

On 3/5/20 1:50 PM, Ruslan Kabatsayev wrote:
> On Fri, 6 Mar 2020 at 00:32, John Baldwin <jhb@freebsd.org> wrote:
>>
>> On 2/1/20 10:43 AM, Ruslan Kabatsayev wrote:
>>> Segment registers are actually 16-bit, and their upper bit doesn't have
>>> the meaning of sign. Currently GDB instead thinks they are signed
>>> 32-bit, which makes various debugger front-ends (e.g. QtCreator) display
>>> them in unnatural format like 00000023.
>>>
>>> Similar consideration applies to various x87 non-data registers. In
>>> addition, fioff and fooff on IA32 are conceptually pointers, so the
>>> command like "p $fioff" should show them as such, not as decimal
>>> integers. On x86-64 fioff and fooff are not as straightforward, being
>>> only the lower parts of the 48-bit offsets, upper part of which is in
>>> fiseg and foseg, respectively, so this easy type assignment can't be
>>> done.
>>>
>>> This patch fixes types and sizes of these 16-bit registers to unsigned
>>> 16-bit, and makes types of fioff and fooff on IA32 respectively code_ptr
>>> and data_ptr (on x86_64 both are made uint32).
>>
>> I'd be happy to see these fixed (segment regs in particular), but I had
>> worried that this might break any debug stubs that aren't using XML target
>> descriptions to describe the layout of 'g'?
> 
> I'm not sure what exactly debug stubs you mean and what "layout of
> 'g'" means (I guess it's about remote debugging?).

Yes the 'g' packet is the remote protocol request to fetch the base set of
general registers for a given architecture and has a fixed layout per
architecture.

> But since sending
> this patch I've discovered that it for some reason breaks debugging of
> some threaded(?) 32-bit apps, giving the following output:
> 
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/libthread_db.so.1".
> Cannot find user-level thread for LWP 9577: generic error
> 
> The culprit appears to be the size of GS register that this patch
> changes—the register which is used as TLS base. If I revert the change
> only to it, this breakage goes away.
> Do you have any idea where to look for the reason?

Hmm, not off the top of my head.  I think the libthread_db bits for
Linux are in linux-thread-db.c and you can single step gdb itself to
see why the call into td_ta_map_lwp2thr_p (which points into a function
in libthread_db.so) fails.

-- 
John Baldwin