From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by ozlabs.org (Postfix) with ESMTP id 0E2A2DDECD for ; Wed, 30 May 2007 17:41:12 +1000 (EST) Received: by ug-out-1314.google.com with SMTP id c2so138357ugf for ; Wed, 30 May 2007 00:41:10 -0700 (PDT) Message-ID: Date: Wed, 30 May 2007 16:34:31 +0900 From: "Hiroyuki Machida" Sender: zseries9@gmail.com To: "Steve Munroe" Subject: Re: Saving to 32 bits of GPRs in signal context In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed References: <1180475055.19517.206.camel@localhost.localdomain> Cc: linuxppc-dev list Reply-To: Hiroyuki.Mach@gmail.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Steve, 2007/5/30, Steve Munroe : > > Benjamin Herrenschmidt wrote on 05/29/2007 > 04:44:15 PM: : : > > > > > > Also if you want to debug this code (see long long variables correctly > from > > > GDB or even see the upper 32-bits of GPRs) you will need an ABI change > so > > > that GDB/DWARF knows what to do. As already mentioned, ABI (calling convetion and relocations) wont't change, so there's no exteion to DWARF required, I think. Do you have any concern ? > > > > I personally don't care about gdb seeing those or anything like that, > > those would be strictly local asm optimisations, at least that's my > > point of view on the matter. > > > Well others do. If gcc supports code gen for this they will expect GDB > support. Even now, gcc -m32 -mpowerpc64 produces 64 bit insns. I've cheked with gcc version 4.1.1 20070105 (Red Hat 4.1.1-51). But in most case, developers would use these options to some specific files which are critical to performance. I think GDB support is not critical, but would be expected. --- Hiroyuki Machida