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 8C6FDDDE3E for ; Wed, 26 Sep 2007 23:21:45 +1000 (EST) In-Reply-To: <46FA3CDD.2070409@genesi-usa.com> References: <46F88896.50706@au1.ibm.com> <46F94CBA.2060901@genesi-usa.com> <1190758712.23457.0.camel@localhost.localdomain> <46FA3CDD.2070409@genesi-usa.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <997c015e13649d06e246d3d2c1369100@kernel.crashing.org> From: Segher Boessenkool Subject: Re: [PATCH] add Altivec/VMX state to coredumps Date: Wed, 26 Sep 2007 15:21:07 +0200 To: Matt Sealey Cc: linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , >>> 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 :-) Segher