From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6948 invoked by alias); 15 Aug 2011 16:56:29 -0000 Received: (qmail 6932 invoked by uid 22791); 15 Aug 2011 16:56:27 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Aug 2011 16:56:13 +0000 Received: (qmail 1323 invoked from network); 15 Aug 2011 16:56:12 -0000 Received: from unknown (HELO ?192.168.0.101?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Aug 2011 16:56:12 -0000 Message-ID: <4E494FA9.9000402@codesourcery.com> Date: Mon, 15 Aug 2011 16:56:00 -0000 From: Yao Qi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: Mark Kettenis CC: gdb-patches@sourceware.org Subject: Re: [patch] Handle return small struct in rs600 (size is not 4/8) References: <4E4939A9.70000@codesourcery.com> <201108151605.p7FG5F1Z004428@glazunov.sibelius.xs4all.nl> In-Reply-To: <201108151605.p7FG5F1Z004428@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-08/txt/msg00301.txt.bz2 On 08/16/2011 12:05 AM, Mark Kettenis wrote: >> X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,TW_CP,TW_EG >> Date: Mon, 15 Aug 2011 23:22:17 +0800 >> From: Yao Qi >> >> Hi, >> It looks to me that ppc-sysv-tdep.c:do_ppc_sysv_return_value doesn't >> consider the case that returning a small struct (size <= 8) whose size >> is not 4 or 8. >> >> Supposing we have a struct defined as below, >> >> struct C >> {char c1; char c2; char c3;}; >> struct C c; >> c.c1 = 'a'; c.c2 = 'b'; c.c3 = 'c'; >> >> The raw memory content of c is 0x616263XX (big-endian) or 0xXX636261 >> (little-endian). When returning c, according to Power Arch ABI: >> "Aggregates or unions whose size is less than or equal to eight bytes >> shall be returned in r3 and r4, as if they were first stored in memory >> area and then the low-addressed word were loaded in r3 and the >> high-addressed word were loaded into r4.", the content of r3 should be >> 0x616263 (big-endian) or 0x636261 (little-endian). > > That's not how I read the ABI. If you store that struct in a > zero-initialized 8-byte buffer you'll have the following sequence of 8 > bytes: > > 0x61 0x62 0x63 0x00 0x00 0x00 0x00 0x00 > > Viewed as two big-endian words this becomes: > > 0x61626300 0x00000000 > > and as two little-endian words this becomes: > > 0x00636261 0x00000000 Yea, that looks right to me. > > So in the little-endian case r3 will indeed be 0x636261 like you say, > but in the big-endian case r3 will be 0x61626300. > Looks like we have different interpretation to ABI doc here. Here is the doc, "Aggregates or unions whose size is less than or equal to eight bytes shall be returned in r3 and r4, as if they were first stored in memory area and then the low-addressed word were loaded in r3 and the high-addressed word were loaded into r4." I think the description "shall be returned in r3 and r4, as if they were first stored in memory area and then the low-addressed word were loaded in r3 ...." is not very clear on the length of data. In this case, struct C variable is returned, and its content is 0x61 0x62 0x63. They (3 bytes) are stored in memory, and (3 bytes) are loaded into r3. Since 3 bytes, not 4, are loaded to r3, so I believe r3 should be 0x616263, instead of 0x61626300. >> When gdb reads r3's content via regcache_cooked_read into a buf, the >> content of buf looks like this, >> buf: [0] [1] [2] [3] >> big-endian : 00 61 62 63 >> little-endian : 61 62 63 00 > > If that's really what you're seeing, then GCC must not implement this > part of the ABI correctly. Not really surprising since GCC has a long > history of getting corner cases like this wrong. > The big-endian case is what I see. > Now the question is if this just happens to be broken in the > particular version of GCC you're using or whether this has always been > broken. Eh, wait a moment... > Yeah, that makes sense. I'll have to read gcc to see how gcc does. -- Yao (齐尧)