From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31910 invoked by alias); 22 Apr 2003 18:08:49 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31896 invoked from network); 22 Apr 2003 18:08:49 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 22 Apr 2003 18:08:49 -0000 Received: from smtp.ott.qnx.com (smtp.ott.qnx.com [10.0.2.158]) by hub.ott.qnx.com (8.9.3p2/8.9.3) with ESMTP id OAA02797; Tue, 22 Apr 2003 14:07:23 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id OAA02213; Tue, 22 Apr 2003 14:08:47 -0400 Message-ID: <079701c308fa$3c6d0610$0202040a@catdog> From: "Kris Warkentin" To: "Daniel Jacobowitz" Cc: References: <076701c308f6$2f017eb0$0202040a@catdog> <20030422174522.GA728@nevyn.them.org> Subject: Re: long long considered harmful? Date: Tue, 22 Apr 2003 18:08:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-SW-Source: 2003-04/txt/msg00251.txt.bz2 I didn't write this stuff - it's taken from our system headers and reflects the way that the kernel stores registers when you ask it to. > > typedef union > > { > > unsigned long long u64; > > double f; > > } mipsfloat; > > This is a target entity isn't it? You've got no business using > "double" for a target float. Use the gdb type mechanism instead. Can you point to an example of how this is done? > > typedef struct mips_cpu_registers > > { > > unsigned regs[74]; > > unsigned long long regs_alignment; > > } MIPS_CPU_REGISTERS; > > What's the purpose of the alignment entry? I doubt it does what you > want it to. I believe it's padding to handle whether we're dealing with a little or big endian target. I'll ask the kernel guys when I find them. Regardless of whether it does anything, the structure has to be the appropriate size for the kernel to fill in. "Mine is not to reason why, mine is just to do or die." > > #ifdef __BIGREGS__ > > Eh? Not sure about the origin of this. It's in our powerpc stuff but there doesn't ever seem to be a situation where it's defined. It might be future proofing but it probably doesn't belong here. I'll most likely take it out and if it ever comes up, fix it in the target backend. > I recommend something like 'typedef char qnx_reg64[8];'; then you can > still say 'qnx_reg64 gpr[32]' and get the right result. Really? I thought I knew C fairly well....I didn't think that was legal. If so, it handles my ugliness issues. cheers, Kris