From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 67072 invoked by alias); 21 Oct 2015 17:47:39 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 65450 invoked by uid 89); 21 Oct 2015 17:47:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 21 Oct 2015 17:47:37 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id CA3F291341; Wed, 21 Oct 2015 17:47:36 +0000 (UTC) Received: from bigtime.twiddle.net (ovpn-113-171.phx2.redhat.com [10.3.113.171]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t9LHlalZ016632; Wed, 21 Oct 2015 13:47:36 -0400 Subject: Re: Changes required for x86 address spaces To: Gary Benson , "H.J. Lu" References: <5626BF4A.2080600@redhat.com> <20151021081610.GA13381@blade.nx> Cc: GDB From: Richard Henderson Message-ID: <5627CFB6.1050809@redhat.com> Date: Wed, 21 Oct 2015 17:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <20151021081610.GA13381@blade.nx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00089.txt.bz2 On 10/20/2015 10:16 PM, Gary Benson wrote: > H.J. Lu wrote: >> On Tue, Oct 20, 2015 at 3:25 PM, Richard Henderson wrote: >>> Here are some notes regarding gdb changes required in order to support >>> >>> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01972.html >>> >>> In my opinion, DW_AT_address_class is best when the alternate >>> address space is truely disjoint, or has a different pointer >>> width. That certainly matches up with the language in the dwarf4 >>> doc, and existing usage in the embedded targets. >>> >>> Thus I've arranged for these x86 address spaces to use >>> DW_AT_segment, a dwarf location containing an offset from the flat >>> address space. For the purposes of the debug info, I map >>> __seg_tls to __seg_fs or __seg_gs. >>> >>> The x86-64 abi already has dwarf register numbers allocated for >>> fs_base and gs_base. Thus the location is simply the trivial >>> DW_OP_regx 58 or 59 respectively. The i386 abi does not yet have >>> the same register number pre-allocated; the latest version I see >>> in HJL's github document has dwarf registers 58-59 within a block >>> of reserved values, so for now I'm using the same values for both >>> x86-64 and i386. >> >> Table 2.14: DWARF Register Number Mapping in Intel386 psABI: >> >> https://github.com/hjl-tools/x86-psABI/wiki/X86-psABI >> >> defines >> >> Segment Register ES 40 %es >> Segment Register CS 41 %cs >> Segment Register SS 42 %ss >> Segment Register DS 43 %ds >> Segment Register FS 44 %fs >> Segment Register GS 45 %gs >> >> Why not use them? > > x86 has %fs and %fs_base, and %gs and %gs_base. I don't understand > the difference but I do know that when libthread_db asks GDB to look > in FS or GS (in ps_get_thread_area) what GDB actually returns is the > contents of FS_BASE or GS_BASE. Exactly. The segment register contains a "descriptor", which in 32-bit land is a 16-bit quantity that indexes a table that describes the segment -- base, length, permissions, etc. In 64-bit land they've pretty much done away with the table and left two quantities, fs_base and gs_base, that are applied when using the appropriate segment overrides. But even for 32-bit, I need the segment base, not the descriptor. GDB ought to be able to pull this value out via ptrace, at least for specific descriptors between linux's GDT_ENTRY_TLS_MIN and GDT_ENTRY_TLS_MAX. Sadly, there's no way for gdb to read arbitrary segment descriptors. > (If GDB could directly access FS_BASE and GS_BASE through regcache or > whatever then thread debugging could be done without the ptrace hacks > in ps_get_thread_area (so presumably faster) but I don't know how to > add this support so I haven't done it.) I was thinking the same thing. Presumably all one needs to do is define new architecture registers and fill in the blanks. But I've lost track of how to do that these days; it seems to be scattered across 19 different files... r~