From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5585 invoked by alias); 12 Nov 2006 00:22:15 -0000 Received: (qmail 5576 invoked by uid 22791); 12 Nov 2006 00:22:14 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 12 Nov 2006 00:22:08 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id AC15B48CE28; Sat, 11 Nov 2006 19:22:06 -0500 (EST) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20447-01-3; Sat, 11 Nov 2006 19:22:06 -0500 (EST) Received: from takamaka.act-europe.fr (unknown [70.71.0.212]) by nile.gnat.com (Postfix) with ESMTP id 6523B48CDCA; Sat, 11 Nov 2006 19:22:06 -0500 (EST) Received: by takamaka.act-europe.fr (Postfix, from userid 1000) id 4D79734C099; Sat, 11 Nov 2006 16:22:26 -0800 (PST) Date: Sun, 12 Nov 2006 00:22:00 -0000 From: Joel Brobecker To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [RFA/sparc64] internal-error printing return value (Ada array) Message-ID: <20061112002226.GA22995@adacore.com> References: <20061111002614.GD3746@adacore.com> <24858.82.92.89.47.1163267262.squirrel@webmail.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24858.82.92.89.47.1163267262.squirrel@webmail.xs4all.nl> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-11/txt/msg00088.txt.bz2 > > 2006-11-10 Joel Brobecker > > > > * sparc64-tdep.c (sparc64_structure_or_union_p): Accept array > > types if the type length is 32 bytes or less. > > > > Fixes the two FAILs above, no regression. > > OK to apply? > > I don't think this is the right fix; the length check almost cetainly is. > > To decide what is the right fix, we need to investigate this a bit further. > I suspect that Ada arrays arereally treated as structures where all members > have the same type. In Ada, arrays can take many forms, and as a result, you have 3 types of arrays: . statically known arrays (where the array bounds are known at compile time), are implemented using a memory buffer. This is our case here. . Then we have fat pointers: This is a structure that contains two pointers, one to a structure containing the array bounds, and one pointer to the memory buffer itself. We use that for arrays whose bounds are not known at compile time. . Lastly, we have thin pointers: This is a pointer to the second field of a structure that resembles the fat pointer. > So the first question I have is whether these indeed > have "fields". Is this question still relevant after the description above? I am not sure I understand it. > You should also check how small arrays are passed as arguments to a > function. This is described by the Ada Reference Manual: Arrays are always passed by reference. So a function taking a parameter of our static array type will have the array passed by reference. As a result, the the array parameter will be a REF to a TYPE_CODE_ARRAY. > Here the magic length will be 16 bytes instead of 32 bytes. I don't understand this part. Why 16 bytes instead of 32? If the total size of the array is 32 bytes, shouldn't the compiler return it through %o0 - %o7? -- Joel