From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTP id 26F0FDDE05 for ; Wed, 26 Sep 2007 23:32:11 +1000 (EST) In-Reply-To: <997c015e13649d06e246d3d2c1369100@kernel.crashing.org> References: <46F88896.50706@au1.ibm.com> <46F94CBA.2060901@genesi-usa.com> <1190758712.23457.0.camel@localhost.localdomain> <46FA3CDD.2070409@genesi-usa.com> <997c015e13649d06e246d3d2c1369100@kernel.crashing.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: From: Kumar Gala Subject: Re: [PATCH] add Altivec/VMX state to coredumps Date: Wed, 26 Sep 2007 08:32:01 -0500 To: Segher Boessenkool Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Sep 26, 2007, at 8:21 AM, Segher Boessenkool wrote: >>>> Why not put the PVR in core dumps that'd make it all easier.. >>> >>> PVR wouldn't be very useful... What if you have altivec disabled ? >>> Also >>> that would mean your gdb has to know about all new processors... >> >> Is that such a big deal? :D >> >> Hypothetically it would be impossible to determine if you were >> running >> on a G5 with the FPU and AltiVec turned off or an e500 core with SPE, >> given the data saved. > > And that is exactly as should be: a core dump represents the execution > state of a user program, it has nothing to do with the machine it was > generated on; it even is possible to restart a core dump generated on > e.g. an e500 on a 970, as long as it doesn't use facilities (e.g., > SPE) > that the latter processor / execution environment doesn't provide. > >> Is that a misfeature of GDB that we even have to >> worry about this, or some noble plus point of a unified ISA? You >> decide :) > > We don't have to worry about it :-) We should worry about it. If one misinterprets the core file you will get unexpected behavior. I see no reason not to do this properly and mark the sections such that its clear if its AltiVec or SPE state, rather than overloading the x86 XFPU type. - k