From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15173 invoked by alias); 23 Apr 2003 22:11:40 -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 15163 invoked from network); 23 Apr 2003 22:11:40 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 23 Apr 2003 22:11:40 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 198ST5-0007P8-00; Wed, 23 Apr 2003 17:11:55 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 198SSn-0001eD-00; Wed, 23 Apr 2003 18:11:37 -0400 Date: Wed, 23 Apr 2003 22:11:00 -0000 From: Daniel Jacobowitz To: Kris Warkentin Cc: gdb@sources.redhat.com Subject: Re: long long considered harmful? Message-ID: <20030423221137.GA6244@nevyn.them.org> Mail-Followup-To: Kris Warkentin , gdb@sources.redhat.com References: <20030422174522.GA728@nevyn.them.org> <080801c30903$2dc0ae60$0202040a@catdog> <081f01c30904$ea5b7f90$0202040a@catdog> <20030422193013.GA25488@nevyn.them.org> <096e01c3099d$ba1f3a30$0202040a@catdog> <20030423211716.GA25678@nevyn.them.org> <0ca901c309de$a262f5d0$0202040a@catdog> <0cbf01c309e1$8bb32190$0202040a@catdog> <20030423214740.GA3719@nevyn.them.org> <000b01c309e5$098a5f90$0202040a@catdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000b01c309e5$098a5f90$0202040a@catdog> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00277.txt.bz2 On Wed, Apr 23, 2003 at 06:09:40PM -0400, Kris Warkentin wrote: > > I'd have to see exactly what you meant, but probably not. These things > > have to be an exact size, right? Barring wackiness like the 32-bit > > char platforms, which I shouldn't have brought into this. So if you > > run on a host with 64-bit "int", it will be wrong. > > It just has to be AT LEAST a certain size. If I have: > > typedef struct x86_cpu_registers > { > unsigned edi, esi, ebp, exx, ebx, edx, ecx, eax; > unsigned eip, cs, efl; > unsigned esp, ss; > } X86_CPU_REGISTERS; > > typedef union _debug_gregs > { > ARM_CPU_REGISTERS arm; > ... > X86_CPU_REGISTERS x86; > qnx_reg64 padding[1024]; > } nto_gregset_t; > > Then the padding guarantees a minimum size. If I then calculate edi, esi, > etc. > using char offsets, the way the compiler creates the structure is completely > irrelevant. The only reason for the structure is to maintain visible > compatability with our system headers. At that point, the entire contents of this header (for GDB's purposes) could be: typedef union _debug_gregs { qnx_reg64 padding[1024]; }; Right? If so, honestly I don't see the point of including it in GDB at all. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer