From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29378 invoked by alias); 22 Jul 2011 19:10:43 -0000 Received: (qmail 29370 invoked by uid 22791); 22 Jul 2011 19:10:42 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD 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; Fri, 22 Jul 2011 19:10:28 +0000 Received: (qmail 5162 invoked from network); 22 Jul 2011 19:10:27 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Jul 2011 19:10:27 -0000 From: Pedro Alves To: Tom Tromey Subject: Re: RFC: partially available registers Date: Fri, 22 Jul 2011 19:31: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 References: <201107221940.32070.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201107222010.23822.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/msg00644.txt.bz2 On Friday 22 July 2011 19:55:31, Tom Tromey wrote: > >>>>> "Pedro" == Pedro Alves writes: > > Pedro> Ah, that's it then. I was curious to know why were the > Pedro> upper parts of the ymm unavailable. > > amd64_linux_fetch_inferior_registers calls ptrace(PTRACE_GETREGSET) > to fetch the registers. Then it passes this to amd64_supply_xsave, > which calls i387_supply_xsave. This function then decodes the "XCR0" > flag and determines that the upper parts were not supplied by the > kernel; that is, we take the true branch here: > > if ((clear_bv & I386_XSTATE_AVX)) > p = NULL; > else > p = regs; Ah, thanks. With a bit more context: case avxh: if ((clear_bv & I386_XSTATE_AVX)) p = NULL; else p = XSAVE_AVXH_ADDR (tdep, regs, regnum); regcache_raw_supply (regcache, regnum, p); return; regcache_raw_supply with p=NULL means the register is unavailable. But before the stuff, it meant "supply the register as 0". I seem to remember discussing this AVX stuff with H.J., and coming to the conclusion that what want is really 0, but maybe not. gdbserver is explicitly zeroing in this case, instead of returning unavailable, see gdbserver/i387-fp.c:i387_xsave_to_cache. What does it really mean when you have an AVX capable machine, but I386_XSTATE_AVX is clear? Whatever the answer, we need to fix one of native gdb or gdbserver for consistency. -- Pedro Alves