From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5474 invoked by alias); 4 May 2004 17:20:03 -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 5415 invoked from network); 4 May 2004 17:20:00 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.77.109) by sources.redhat.com with SMTP; 4 May 2004 17:20:00 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i44HJq5U000291; Tue, 4 May 2004 19:19:52 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i44HJqju000785; Tue, 4 May 2004 19:19:52 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i44HJqSX000782; Tue, 4 May 2004 19:19:52 +0200 (CEST) Date: Tue, 04 May 2004 17:20:00 -0000 Message-Id: <200405041719.i44HJqSX000782@elgar.kettenis.dyndns.org> From: Mark Kettenis To: msnyder@redhat.com CC: schwab@suse.de, gdb-patches@sources.redhat.com In-reply-to: <4096F727.9030907@redhat.com> (message from Michael Snyder on Tue, 04 May 2004 01:51:35 +0000) Subject: Re: [PATCH/RFA] Update m68k function return value handling References: <200405022152.i42Lq2nc000394@elgar.kettenis.dyndns.org> <4096F727.9030907@redhat.com> X-SW-Source: 2004-05/txt/msg00108.txt.bz2 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. 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... 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.