From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32223 invoked by alias); 19 Jun 2006 15:28:44 -0000 Received: (qmail 32213 invoked by uid 22791); 19 Jun 2006 15:28:42 -0000 X-Spam-Check-By: sourceware.org Received: from potter.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 19 Jun 2006 15:28:37 +0000 Received: (qmail 1771 invoked from network); 19 Jun 2006 15:28:34 -0000 Received: from unknown (HELO ?192.168.189.145?) (nathan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 19 Jun 2006 15:28:34 -0000 Message-ID: <4496C2AF.2000906@codesourcery.com> Date: Mon, 19 Jun 2006 15:28:00 -0000 From: Nathan Sidwell User-Agent: Thunderbird 1.5.0.4 (X11/20060615) MIME-Version: 1.0 To: Mark Kettenis CC: gdb-patches@sourceware.org, schwab@suse.de Subject: Re: [m68k] return values References: <44897213.3070309@codesourcery.com> <200606180550.k5I5o0ni009268@elgar.sibelius.xs4all.nl> <4496B738.1050500@codesourcery.com> <200606191510.k5JFAfG0028604@elgar.sibelius.xs4all.nl> In-Reply-To: <200606191510.k5JFAfG0028604@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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-06/txt/msg00272.txt.bz2 Mark Kettenis wrote: > Well, I fear you've managed to confuse yourself. The current m68k > default target uses m68k_extract_return_value(), which reads all > return values from %d0. you're right. ok, the whole problem I'm trying to solve is to get the function return working for m68k-elf. That appears to be a mixture of original and svr4 features. Namely: a) returns always go in %d0 (original) b) small structures can be passed in registers (svr4) c) structure return values use the struct_return convention (svr4?) What approach do you think would be best in tackling this? The way I'd gone at it was to treat the m68k-elf as a variant of svr4 (i.e. #a was the exceptional behaviour). It would be possible to organize it as original ABI, but with #b & #c as the exceptions. Do you think the default should be compatible with m68k-elf, or should the user explicitly set the abi in that case? As you may be aware, #b is implemented by GCC in a horrible way that is dependent on internal implementation details -- it's not just that the structure is 'small' or even 2^n bytes. I have a patch that emulate's GCC's behaviour, and I was going to post that after this patch was resolved. It certainly is an adventure trying to figure out what's meant to happen :) nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk