From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18807 invoked by alias); 11 Nov 2006 17:47:53 -0000 Received: (qmail 18798 invoked by uid 22791); 11 Nov 2006 17:47:53 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-vbr14.xs4all.nl (HELO smtp-vbr14.xs4all.nl) (194.109.24.34) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 11 Nov 2006 17:47:47 +0000 Received: from webmail.xs4all.nl (dovemail9.xs4all.nl [194.109.26.11]) by smtp-vbr14.xs4all.nl (8.13.8/8.13.8) with ESMTP id kABHlct1057688; Sat, 11 Nov 2006 18:47:42 +0100 (CET) (envelope-from mark.kettenis@xs4all.nl) Received: from 82.92.89.47 (SquirrelMail authenticated user sibelius) by webmail.xs4all.nl with HTTP; Sat, 11 Nov 2006 18:47:42 +0100 (CET) Message-ID: <24858.82.92.89.47.1163267262.squirrel@webmail.xs4all.nl> In-Reply-To: <20061111002614.GD3746@adacore.com> References: <20061111002614.GD3746@adacore.com> Date: Sat, 11 Nov 2006 17:47:00 -0000 Subject: Re: [RFA/sparc64] internal-error printing return value (Ada array) From: "Mark Kettenis" To: "Joel Brobecker" Cc: 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/msg00080.txt.bz2 > The type in question is a TYPE_CODE_ARRAY. It seems that this case > is not handled yet by the function that extracts the return value: > > sparc64-tdep.c:sparc64_extract_return_value > > I am not sure yet whether this case is specific to Ada or if we can > reproduce the same with C, I will double-check. C doesn't really have arrays. > I think the best fix for this is to update sparc64_structure_or_union_p > to accept arrays of 32 bytes or less. The name would become slightly > misleading for its actual implementation, and I wouldn't mind changing > it if felt necessary. > > I don't know if the same issue applies to 32bit GDB or not. I tried, > but "fin" doesn't stop at the function return, so I never get the > returned value printed by GDB. I'll have a look at this another time. > > I also noticed that the same problem happens for arrays larger than > 32bytes. In fact, this is not specific to arrays, but to structures > as well. Support for structures larger than 32 bytes seems to be > missing. I can add that too, but let's make this another patch. > > 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. So the first question I have is whether these indeed have "fields". You should also check how small arrays are passed as arguments to a function. Here the magic length will be 16 bytes instead of 32 bytes. Mark