From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32667 invoked by alias); 23 Apr 2003 13:39:09 -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 32658 invoked from network); 23 Apr 2003 13:39:09 -0000 Received: from unknown (HELO hub.ott.qnx.com) (209.226.137.76) by sources.redhat.com with SMTP; 23 Apr 2003 13:39:09 -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 JAA02064; Wed, 23 Apr 2003 09:37:39 -0400 Received: from catdog ([10.4.2.2]) by smtp.ott.qnx.com (8.8.8/8.6.12) with SMTP id JAA17712; Wed, 23 Apr 2003 09:39:08 -0400 Message-ID: <096e01c3099d$ba1f3a30$0202040a@catdog> From: "Kris Warkentin" To: "Daniel Jacobowitz" Cc: References: <076701c308f6$2f017eb0$0202040a@catdog> <20030422174522.GA728@nevyn.them.org> <080801c30903$2dc0ae60$0202040a@catdog> <081f01c30904$ea5b7f90$0202040a@catdog> <20030422193013.GA25488@nevyn.them.org> Subject: Re: long long considered harmful? Date: Wed, 23 Apr 2003 13: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/msg00266.txt.bz2 > > 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 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. ;-) cheers, Kris