From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29355 invoked by alias); 28 Mar 2010 01:39:57 -0000 Received: (qmail 29346 invoked by uid 22791); 28 Mar 2010 01:39:56 -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-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 28 Mar 2010 01:39:52 +0000 Received: by vws20 with SMTP id 20so5188598vws.0 for ; Sat, 27 Mar 2010 18:39:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.90.201 with HTTP; Sat, 27 Mar 2010 18:39:50 -0700 (PDT) In-Reply-To: <201003271609.o2RG9KrM007013@glazunov.sibelius.xs4all.nl> References: <20100304180219.GA10826@intel.com> <20100304180408.GA10869@intel.com> <20100304180643.GB10869@intel.com> <20100306222037.GD21133@intel.com> <20100307213153.GA7170@intel.com> <201003112237.o2BMb4XR024283@glazunov.sibelius.xs4all.nl> <6dc9ffc81003111600k66be499cqf6639a07d20f5cce@mail.gmail.com> <201003271454.o2REsujU007688@glazunov.sibelius.xs4all.nl> <6dc9ffc81003270833ha338c40pf9aece3d4f902ac6@mail.gmail.com> <201003271609.o2RG9KrM007013@glazunov.sibelius.xs4all.nl> Date: Sun, 28 Mar 2010 01:39:00 -0000 Received: by 10.220.107.158 with SMTP id b30mr1719321vcp.225.1269740390984; Sat, 27 Mar 2010 18:39:50 -0700 (PDT) Message-ID: <6dc9ffc81003271839i1d0281dfiabd8750aaf964076@mail.gmail.com> Subject: Re: PATCH: 3/6 [2nd try]: Add AVX support (i386 changes) From: "H.J. Lu" To: Mark Kettenis Cc: 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-03/txt/msg00938.txt.bz2 On Sat, Mar 27, 2010 at 9:09 AM, Mark Kettenis wr= ote: >> >> >> + =A0 =A0perror_with_name (_("Couldn't read extended state status"= )); >> >> >> + >> >> >> + =A0i387_supply_xsave (regcache, -1, xstateregs); >> >> >> + =A0return 1; >> >> >> +} >> >> >> + >> >> >> +/* Store all valid registers in GDB's register array covered by t= he >> >> >> + =A0 PTRACE_SETREGSET request into the process/thread specified b= y TID. >> >> >> + =A0 Return non-zero if successful, zero otherwise. =A0*/ >> >> >> + >> >> >> +static int >> >> >> +store_xstateregs (const struct regcache *regcache, int tid, int r= egno) >> >> >> +{ >> >> >> + =A0unsigned long long xstateregs[xstate_size_n_of_int64]; >> >> > >> >> > I think it is better to use I386_XSTATE_MAX_SIZE here. >> >> >> >> That is how the kernel interface works. =A0Whatever value >> >> I386_XSTATE_MAX_SIZE is today won't be the same tomorrow. We will >> >> increase it in the coming years. But the same gdb binary will work >> >> fine since kernel will only copy number of bytes specified in >> >> iov.iov_len, which is all gdb cares/needs. >> > >> > Yes, you'll need to raise I386_XSTATE_MAX_SIZE whenever the kernel >> > gains support for different/larger xstates. =A0But I don't see a probl= em >> > with that, since you'll have to make changes to GDB to support those >> > variants anyway. =A0That reminds me: >> >> I will remove I386_XSTATE_MAX_SIZE since it isn't needed by kernel. > > Huh? =A0You're missing the point here. =A0GDB is supposed to be written in > C90, which doesn't support variable-length arrays. =A0So you need a > compile-time constant to size the xstateregs array. =A0And > I386_XSTATE_MAX_SIZE fits the bill there perfectly. > I will make the change. Thanks. --=20 H.J.