From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29524 invoked by alias); 19 Jun 2006 18:32:17 -0000 Received: (qmail 29515 invoked by uid 22791); 19 Jun 2006 18:32:16 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 19 Jun 2006 18:32:12 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k5JIUmru021524; Mon, 19 Jun 2006 20:30:48 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k5JIUmd8020638; Mon, 19 Jun 2006 20:30:48 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k5JIUmjO025819; Mon, 19 Jun 2006 20:30:48 +0200 (CEST) Date: Mon, 19 Jun 2006 18:32:00 -0000 Message-Id: <200606191830.k5JIUmjO025819@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: nathan@codesourcery.com CC: gdb-patches@sourceware.org, schwab@suse.de In-reply-to: <4496C2AF.2000906@codesourcery.com> (message from Nathan Sidwell on Mon, 19 Jun 2006 16:28:47 +0100) 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> <4496C2AF.2000906@codesourcery.com> 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/msg00274.txt.bz2 > Date: Mon, 19 Jun 2006 16:28:47 +0100 > From: Nathan Sidwell > > 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. Well, #b basically means reg_struct_return convention, which already is the default. And with #c you probably mean that the caller allocates the memory to store the returned structure instead of having the callee provide it in a static buffer (which is braindead since it is non-reentrant). The current code should cater for both, as long as a pointer to the memory is returned in %d0. Note that for SVR4 the pointer is returned in %a0, but that makes no sense for m68k-elf since normal pointers are returned in %d0. So I believe that the default m68k gdbarch vector should work just fine for m68k-elf. But perhaps it is a good idea to verify that the value is indeed returned in %d0. > Do you think the default should be compatible with m68k-elf, or > should the user explicitly set the abi in that case? I believe the default gdbarch vector should be suitable for m68k-aout, m68k-coff and m68k-elf. > 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. And unfortunately GCC's implementation is almost a guaranteed to break the ABI every now and then. So it wouldn't surprise me at all if your GCC is broken; or at least different from the GCC that comes with the latest OpenBSD/mac68k release, which still uses GCC 2.95.3. So it may actually be impossible to solve this. Fortunately you're probably fixing corner cases in what is already a corner case; structures tend to be larger than 8 bytes. Could you send me the testsuite output for your m68k-elf target? I'll run the testsuite on my Quadra 800 tonight so we can compare results. Mark