From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23341 invoked by alias); 12 Nov 2006 20:49:39 -0000 Received: (qmail 23328 invoked by uid 22791); 12 Nov 2006 20:49:38 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-vbr15.xs4all.nl (HELO smtp-vbr15.xs4all.nl) (194.109.24.35) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 12 Nov 2006 20:49:30 +0000 Received: from webmail.xs4all.nl (dovemail8.xs4all.nl [194.109.26.10]) by smtp-vbr15.xs4all.nl (8.13.8/8.13.8) with ESMTP id kACKnINc044748; Sun, 12 Nov 2006 21:49:26 +0100 (CET) (envelope-from mark.kettenis@xs4all.nl) Received: from 82.92.89.47 (SquirrelMail authenticated user sibelius) by webmail.xs4all.nl with HTTP; Sun, 12 Nov 2006 21:49:26 +0100 (CET) Message-ID: <6654.82.92.89.47.1163364566.squirrel@webmail.xs4all.nl> In-Reply-To: <20061112002226.GA22995@adacore.com> References: <20061111002614.GD3746@adacore.com> <24858.82.92.89.47.1163267262.squirrel@webmail.xs4all.nl> <20061112002226.GA22995@adacore.com> Date: Sun, 12 Nov 2006 20:49:00 -0000 Subject: Re: [RFA/sparc64] internal-error printing return value (Ada array) From: "Mark Kettenis" To: "Joel Brobecker" Cc: "Mark Kettenis" , gdb-patches@sourceware.org User-Agent: SquirrelMail/1.4.8 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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/msg00090.txt.bz2 > > 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. Hmm, I gueass I should have asked how a gdb `struct type' looks for these Ada arrays? In particular, if main_type->nfields is set and whether main_type->fields is set to something useful. > > 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. So there is no way to pass a TYPE_CODE_ARRAY directly? > > 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? The 16-byte limit is for passing structures as an argument to a function. I presume this is because function arguments occupy 16-byte slots in the ABI. Mark