From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57826 invoked by alias); 5 Mar 2020 23:57:13 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 56494 invoked by uid 89); 5 Mar 2020 23:57:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*f:sk:CAHEcG9, H*MI:sk:CAHEcG9, H*i:sk:CAHEcG9, D*freebsd.org X-HELO: mx2.freebsd.org Received: from mx2.freebsd.org (HELO mx2.freebsd.org) (96.47.72.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Mar 2020 23:57:11 +0000 Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 9431CA3B4C; Thu, 5 Mar 2020 23:57:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48YSN46CjRz4429; Thu, 5 Mar 2020 23:57:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-7.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 7B90630F7; Thu, 5 Mar 2020 23:57:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: [PATCH] Fix sizes and types of x86 segment and x87 registers To: Ruslan Kabatsayev Cc: GDB Patches References: <20200201184318.25049-1-b7.10110111@gmail.com> From: John Baldwin Message-ID: <18c3d2e6-643b-88e3-93e2-e24aca2af7a5@FreeBSD.org> Date: Thu, 05 Mar 2020 23:57:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2020-03/txt/msg00137.txt On 3/5/20 1:50 PM, Ruslan Kabatsayev wrote: > On Fri, 6 Mar 2020 at 00:32, John Baldwin 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