From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6541 invoked by alias); 26 Jul 2011 15:31:37 -0000 Received: (qmail 6532 invoked by uid 22791); 26 Jul 2011 15:31:36 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_AV X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Jul 2011 15:31:21 +0000 Received: (qmail 30666 invoked from network); 26 Jul 2011 15:31:21 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 26 Jul 2011 15:31:21 -0000 From: Pedro Alves To: Tom Tromey Subject: Re: RFC: partially available registers Date: Tue, 26 Jul 2011 17:08:00 -0000 User-Agent: KMail/1.13.6 (Linux/2.6.38-8-generic; KDE/4.6.2; x86_64; ; ) Cc: gdb-patches@sourceware.org, Daniel Jacobowitz , hjl@gnu.org References: <201107222010.23822.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107261631.18672.pedro@codesourcery.com> 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: 2011-07/txt/msg00723.txt.bz2 On Friday 22 July 2011 20:30:53, Tom Tromey wrote: > >>>>> "Pedro" == Pedro Alves writes: > Pedro> But before the stuff, it meant "supply the register > Pedro> as 0". I seem to remember discussing this AVX stuff with H.J., > Pedro> and coming to the conclusion that what want is really 0, but > Pedro> maybe not. > > I am far from being an expert in this area, Same here... > but from the Intel Architecture manual, section 13.5.1: Thanks. I finally took a bit to read that too. > Saving the x87 FPU/MMX/SSE/SSE2/SSE3/SSSE3/SSE4 state using FXSAVE > requires processor overhead. If the new task does not access x87 FPU, > MMX, XMM, and MXCSR registers, avoid overhead by not automatically > saving the state on a task switch. > > The TS flag in control register CR0 is provided to allow the operating > system to delay saving the x87 FPU/MMX/SSE/SSE2/SSE3/SSSE3/SSE4 state > until an instruction that actually accesses this state is encountered in > a new task. > > So I think what is going on here is that the upper bits of these > registers are truly unavailable, because the inferior has never executed > an instruction referencing them. My mental model of is: means the object exists, and its value exists, but we have no means to fetch it. This corresponds to trying to print the value of a register while inspecting a traceframe, while that register had not been collected by the corresponding tracepoint -- the register exists in the architecture/machine, but we can't know what value it had when the tracepoint hit. It also corresponds to a (trimmed/partial) core dump file not containing a dump of all the machine's registers, or a dump of all the process'es mapped memory (due to ulimit, perhaps). And corresponds to not being able to get at some register's current value because the debug API exposes no means to get at the current value. Along with other similar scenarios. Let me brain dump what I think is happening in this avx case, to make sure we're on the same page: In this case, IIUC, with the delayed xsave mechanism active, if a task has already accessed the x87 states, but hasn't triggered a delayed x87 states' save/restore since the last context switch, the current value of the x87 states of that task should be in the save area (and valie), which is what ptrace gives us when we read registers. For a task that did access (and change) the x87 state since the last x87 state save, (I hope!) a ptrace stopped task's save area is up to date with the real x87 states. That is, at runtime, the from ptrace's perpective, the delay/lazy scheme should be transparent, save for one case... ... that is the case of gdb/ptrace reading an x87 state before the program had first accessed the state itself for the first time. H.J.Lu wrote: > Values in vector registers are invalid, not unavailable. OS > initializes them to zero when they are set the firs time in > a program. I prefer *value not valid". That is, in between the program starting, and the program acessing the vector registers, the register's values are invalid. But, given that the kernel will fill them in with zero's on first access (meaning, from userspace's perspective, it's the same as if the registers have always been zero from the start of the program), I think it's best that a debugger provides the same illusion to the user. As H.J. wrote: > GDB may update vector registers before they are set by program. > GDB sets proper bits in XSAVE area to tell OS/hardware that vector > registers now have valid values. ... and indeed this is what i387-tdep.c:i387_collect_xsave appears to be doing. Am I making sense? > Pedro> Whatever the answer, we need to fix one of native > Pedro> gdb or gdbserver for consistency. > > If you agree with what I have checked in, I will update gdbserver. I think your patch implements the right interface for partial registers support. I like it... > Otherwise, let me know what you think would be correct and I will > implement that, instead, for both. ... but I think that we should go with 0, instead of , meaning changing x87-tdep.c:i387_supply_xsave to supply explicity zeroed buffer, instead of a NULL pointer, like gdbserver does. -- Pedro Alves