From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31203 invoked by alias); 23 Apr 2003 21:17:20 -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 31189 invoked from network); 23 Apr 2003 21:17:20 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 23 Apr 2003 21:17:20 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 198RcT-0007JA-00; Wed, 23 Apr 2003 16:17:33 -0500 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 198RcC-0006tW-00; Wed, 23 Apr 2003 17:17:16 -0400 Date: Wed, 23 Apr 2003 21:17:00 -0000 From: Daniel Jacobowitz To: Kris Warkentin Cc: gdb@sources.redhat.com Subject: Re: long long considered harmful? Message-ID: <20030423211716.GA25678@nevyn.them.org> Mail-Followup-To: Kris Warkentin , gdb@sources.redhat.com References: <076701c308f6$2f017eb0$0202040a@catdog> <20030422174522.GA728@nevyn.them.org> <080801c30903$2dc0ae60$0202040a@catdog> <081f01c30904$ea5b7f90$0202040a@catdog> <20030422193013.GA25488@nevyn.them.org> <096e01c3099d$ba1f3a30$0202040a@catdog> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <096e01c3099d$ba1f3a30$0202040a@catdog> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-04/txt/msg00272.txt.bz2 On Wed, Apr 23, 2003 at 09:39:13AM -0400, Kris Warkentin wrote: > > > Pardon me, by overall structure, I mean the starting address of the > > > structure. Having a 64 bit entry causes the compiler to align the > structure > > > on a 64 bit boundary. > > > > Whoever told you this is mistaken. A long long member of a structure > > only has four byte alignment on i386-linux, for example. That's > > mandated by the psABI. > > > > This is exactly one of those reasons why you can not use structures > > on the host to describe data on the target. > > I'm not talking about host vs. target here. These are the structures used > by our Mips and PowerPC kernels. I believe the mips compiler will do the > alignment as mentioned above. You are correct that you can't rely on it > being the same on host and target but this is not something that matters in > this case. All that's important is that when the data comes over the wire, > we can get at it. In this case, because of the awkward define (data below If you want to get at it, then it _is_ a host vs. target issue. > is unsigned regs[74]), we wind up extracting the mips registers like so: > > static void regset_fetch( int endian, unsigned first, unsigned last, > unsigned *data ) > { > if( endian) data += 1; /* data in second word for big endian */ > for(; first <= last; ++first) { > supply_register(first, (char *)data); > data+=2; > } > } > > I know it's not 100% portable. I personally don't really care as long as it > works on the hosts that we support. The only reason I'm asking all this is > because I want to know what level of portability is required for the GDB > project to accept this patch. I was trying to eliminate the long longs in a > relatively painless way and the char array seems to be not too bad. Are you > really trying to tell me that gdb wouldn't blow up on a 32 bit char host as > it stands right now? If you really feel that the only way for me to make > this acceptable is to just use a blob of memory and a table of offsets into > it, then that's what I'll do. My mandate is to get our stuff accepted so I > don't really have a choice. (I'd really rather not though. ;-) If it's not portable, I'd really strongly prefer it not go in at all until it is. I went through this exact thing making core dumps work in a cross environment; someone wanted to use them from a 64-bit Solaris host. It's just as easy to do it right, really. Look at this: typedef char qnx_reg64[8]; static void regset_fetch (int endian, unsigned first, unsigned last, qnx_reg64 *data) { for (; first <= last; first++) { if (endian) supply_register (first, (char *) &data[0][4]); else supply_register (first, (char *) data); data++; } } Was that really so hard? And it's a lot clearer. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer