From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10149 invoked by alias); 22 Apr 2003 17:39:48 -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 10142 invoked from network); 22 Apr 2003 17:39:48 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 22 Apr 2003 17:39:48 -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 NAA01437 for ; Tue, 22 Apr 2003 13:38:23 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id NAA15085 for ; Tue, 22 Apr 2003 13:39:47 -0400 Message-ID: <076701c308f6$2f017eb0$0202040a@catdog> From: "Kris Warkentin" To: Subject: long long considered harmful? Date: Tue, 22 Apr 2003 17:39: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/msg00249.txt.bz2 Below is a clipping from our debug.h header which defines the register structures for QNX Neutrino. I've been in conversation with Mark Kettenis about our gdb submission and it looks like portability issues in this header are one of the few remaining stumbling blocks, at least from his perspective. I guess that conceivably some older systems might not be able to deal with a 64 bit int type. The question I want to ask is, "how do I deal with this in a portable way?" I don't believe that any of these structures are ever manipulated in any way other than to read/write bytes of data into and out of them. Would it be best just to define any long long members as arrays of char? It doesn't seem very pretty but it would certainly do the trick. ie. "char u64[8]" instead of "long long u64" is fine but "char gpr_hi[32 * 8]" instead of "long long gpr_hi[32]" seems a bit nasty. comments? Kris >>>>>>>>>>>>>debug.h clip<<<<<<<<<<<<<<<<<<<<< typedef union { unsigned long long u64; double f; } mipsfloat; typedef struct mips_cpu_registers { unsigned regs[74]; unsigned long long regs_alignment; } MIPS_CPU_REGISTERS; typedef struct mips_fpu_registers { mipsfloat fpr[32]; unsigned fpcr31; } MIPS_FPU_REGISTERS; typedef struct mips_alt_registers { union { struct mips_tx79 { unsigned long long gpr_hi[32]; unsigned long long lo1; unsigned long long hi1; unsigned sa; } tx79; } un; } MIPS_ALT_REGISTERS; #ifdef __BIGREGS__ typedef unsigned long long ppcint; #else typedef unsigned ppcint; #endif typedef union { unsigned long long u64; double f; } ppcfloat; typedef union { unsigned long long u64[2]; unsigned u32[4]; unsigned char u8[16]; float f32[4]; } ppcvmx; typedef struct ppc_cpu_registers { ppcint gpr[32]; ppcint ctr; ppcint lr; ppcint msr; ppcint iar; unsigned cr; unsigned xer; unsigned ear; /* Not present on all chips. */ unsigned mq; /* Only on the 601. */ unsigned vrsave; /* On Altivec CPU's, SPR256. */ } PPC_CPU_REGISTERS; typedef struct ppc_fpu_registers { ppcfloat fpr[32]; unsigned fpscr; unsigned fpscr_val; /* Load/store of fpscr is done through fprs, the real value is in [32,63] of a fpr. Fpscr is the address for lfd, stfd. fpscr_val is the real value of fpscr. */ } PPC_FPU_REGISTERS; typedef struct ppc_vmx_registers { ppcvmx vmxr[32]; ppcvmx vscr; } PPC_VMX_REGISTERS; typedef struct ppc_alt_registers { PPC_VMX_REGISTERS vmx; } PPC_ALT_REGISTERS;