From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9560 invoked by alias); 22 Feb 2010 21:06:40 -0000 Received: (qmail 9543 invoked by uid 22791); 22 Feb 2010 21:06:39 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40 X-Spam-Check-By: sourceware.org Received: from mail-ww0-f41.google.com (HELO mail-ww0-f41.google.com) (74.125.82.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 22 Feb 2010 21:06:35 +0000 Received: by wwb24 with SMTP id 24so465433wwb.0 for ; Mon, 22 Feb 2010 13:06:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.179.201 with SMTP id h51mr46829wem.224.1266872792119; Mon, 22 Feb 2010 13:06:32 -0800 (PST) In-Reply-To: <201002221950.o1MJoomn007989@glazunov.sibelius.xs4all.nl> References: <20100218054312.GA9022@lucon.org> <201002221342.o1MDgSZA029705@glazunov.sibelius.xs4all.nl> <20100222144141.GA30100@caradoc.them.org> <6dc9ffc81002220734i15bd1279mb54cb0b64a37f3dc@mail.gmail.com> <20100222155243.GC30100@caradoc.them.org> <6dc9ffc81002220757v5e9b48bdnba56a260f0f3c0a8@mail.gmail.com> <20100222161040.GD30100@caradoc.them.org> <201002221656.o1MGuw5q009795@glazunov.sibelius.xs4all.nl> <20100222170303.GG9493@caradoc.them.org> <201002221950.o1MJoomn007989@glazunov.sibelius.xs4all.nl> Date: Mon, 22 Feb 2010 21:06:00 -0000 Message-ID: <6dc9ffc81002221306y6287491dv5aaac541ba303199@mail.gmail.com> Subject: Re: PATCH: Enable x86 XML target descriptions From: "H.J. Lu" To: Mark Kettenis Cc: dan@codesourcery.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes 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 X-SW-Source: 2010-02/txt/msg00557.txt.bz2 On Mon, Feb 22, 2010 at 11:50 AM, Mark Kettenis w= rote: >> Date: Mon, 22 Feb 2010 12:03:03 -0500 >> From: Daniel Jacobowitz >> >> On Mon, Feb 22, 2010 at 05:56:58PM +0100, Mark Kettenis wrote: >> > I've looked at the Linux kernel sources for the kernel on my >> > workstation (2.6.27 in its OpenSUSE incarnation), and the only way to >> > distinguish between a 32-bit and a 64-bit process seems to be to >> > attempt to write one of the debug address registers with a value >> > that's larger than 0xffffffff. =A0If that fails, you have a 32-bit >> > process, otherwise it's a 64-bit process. >> >> Yuck :-( =A0But I didn't see anything else either. > > Indeed. > >> Is there an eflags bit for this? =A0Even if so, IIRC, we may not want to >> use it; it's possible to run 32-bit code in a 64-bit process and some >> overly clever programs may do so. > > Nope, there is no %eflags/%rflags bit for this. =A0Not quite sure what > running 32-bit code in a 64-bit process actually means. =A0But I'd guess > you want the 64-bit view on the registers in that case. > > Anyway, I think it's probably best if HJ leaves this bit out of this > diff for now. =A0We can revisit the issue when AVX support is > introduced. > Please see if my latest patch is OK: --- /* Get CS register. */ errno =3D 0; cs =3D ptrace (PTRACE_PEEKUSER, tid, offsetof (struct user_regs_struct, cs), 0); if (errno !=3D 0) perror_with_name (_("Couldn't get CS register")); /* Value of CS register: 1. 64bit: 0x33. 2. 32bit: 0x23. */ if (cs =3D=3D 0x33) return tdesc_amd64_linux; else return tdesc_i386_linux; --- In kernel, there is regs->cs =3D test_thread_flag(TIF_64BIT_ILP32) ? __USER_CS : __USER32_CS; Thanks. --=20 H.J.