From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9899 invoked by alias); 4 May 2004 20:02:27 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9892 invoked from network); 4 May 2004 20:02:26 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 4 May 2004 20:02:26 -0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i44K2PkG009917 for ; Tue, 4 May 2004 16:02:25 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i44K2Ow13720; Tue, 4 May 2004 16:02:24 -0400 Received: from redhat.com (dhcp-172-16-25-160.sfbay.redhat.com [172.16.25.160]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id i44K2NC17995; Tue, 4 May 2004 13:02:23 -0700 Message-ID: <4097F6CF.1090305@redhat.com> Date: Tue, 04 May 2004 20:02:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4.2) Gecko/20040301 MIME-Version: 1.0 To: Mark Kettenis CC: schwab@suse.de, gdb-patches@sources.redhat.com Subject: Re: [PATCH/RFA] Update m68k function return value handling References: <200405022152.i42Lq2nc000394@elgar.kettenis.dyndns.org> <4096F727.9030907@redhat.com> <200405041719.i44HJqSX000782@elgar.kettenis.dyndns.org> In-Reply-To: <200405041719.i44HJqSX000782@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-RedHat-Spam-Score: 0 X-SW-Source: 2004-05/txt/msg00116.txt.bz2 Mark Kettenis wrote: > Date: Tue, 04 May 2004 01:51:35 +0000 > From: Michael Snyder > > Mark Kettenis wrote: > > Hi Andreas, > > > > Here's a patch that converts the m68k to the new function return value > > handling mechanism. I tried very hard to make it possible to deal > > with all the different m68k ABI's. I'm pretty sure I've got it right > > for at least OpenBSD, NetBSD and Linux. On other systems it can't > > really be worse than the old code. > > Unfortunately, it can. The problem is that when you use the new > gdbarch_return_value_p method, print_return_value simply gives up > on any function that returns a struct via a pointer argument > (what we refer to as the "struct convention"). I don't know why > it does (esp. in view of all the code you've added for determining > eg. which register this pointer is passed in), but it does. > > This has been discussed in the past. The problem is that on almost > every target, you cannot reliably tell where the return value is > stored. On some targets you can't even tell this when the call is > finished; I believe Andrew said this was the case on powerpc. Well, but it's not the case on m68k, is it? It seems that the location is returned in the same register as any other return value. > Anyway, > most targets, and m68k might be one of them, can tell where the > structure is stored when the function is finished. I've promised to > look into it some time ago (since i386 is in a similar situation). > Just didn't find the time yet... Didn't mean to nag -- it's just that I hoped your changes would make the results better. > This is especially bad for cross-m68k targets, since when > pcc_struct_convention is used, m68k_reg_struct_return_p > always returns false. BTW this is wrong for gcc m68k-elf, > so I don't understand why pcc_struct_convention is set for > all cross targets... > > Hmm. I looked at GCC, to see what the "default" convention would be, > and config/m68k/m68k.h implicates that all structures would be > returned in static storage. I somehow overlooked that the majority, > if not all, "embedded" targets use config/m68k/m68kemb.h, which > overrides the default in config/m68k/m68k.h to return small structures > in registers. So it seems I've simply looked in the wrong place and > chose the wrong default. Feel free to change it to reg_struct_return. > The Linux, OpenBSD and NetBSD targets should be immune to such a > change. If you don't get to making the change I'll do so in a few > days. OK, here are test results: ppc_struct_return: 91 fails reg_struct_return: 63 fails. Not as big an improvement as I'd hoped, but it's an improvement. I'll check it in. Unfortunately I won't have time to look into this further, I'm starting a new project (err) yesterday. Michael