From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6760 invoked by alias); 25 Jan 2011 16:49:38 -0000 Received: (qmail 6694 invoked by uid 22791); 25 Jan 2011 16:49:35 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from gate.lvk.cs.msu.su (HELO mail.lvk.cs.msu.su) (158.250.17.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 25 Jan 2011 16:49:25 +0000 Received: from mail.lvk.cs.msu.su (localhost [127.0.0.1]) by mail.lvk.cs.msu.su (Postfix) with ESMTP id B1EBD3644; Tue, 25 Jan 2011 19:49:16 +0300 (MSK) X-Spam-ASN: Received: from thunder.localnet (gate.lvknet [192.168.128.254]) by mail.lvk.cs.msu.su (Postfix) with ESMTPSA id A5108DD9; Tue, 25 Jan 2011 19:49:16 +0300 (MSK) From: Vladimir Prus To: Mark Kettenis Subject: Re: m68k-elf return value registers Date: Tue, 25 Jan 2011 17:01:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-24-generic-pae; KDE/4.5.1; i686; ; ) Cc: gdb-patches@sources.redhat.com References: <201101140157.38487.vladimir@codesourcery.com> <201101141037.p0EAbFFA023135@glazunov.sibelius.xs4all.nl> In-Reply-To: <201101141037.p0EAbFFA023135@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Message-Id: <201101251949.15840.vladimir@codesourcery.com> X-AV-Checked: ClamAV using ClamSMTP Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-01/txt/msg00500.txt.bz2 On Friday, January 14, 2011 13:37:15 Mark Kettenis wrote: > > From: Vladimir Prus > > Date: Fri, 14 Jan 2011 01:57:38 +0300 > > > > This patch, originally written by Nathan Sidwel, makes m68k-tdep.c use > > right registrers for returning values from functions on bare metal. > > There are actually 3 parts: > > > > 1. Right now, it's assumed that pointer values are returned in %a0. > > However, for m68k-elf, they are returned in %d0. So, this patch makes > > %a0 the default, and then makes OSABI sniffers set %a0 again. > > > > 2. Structures can be returned in either %a0 or %a1. This was discussed > > > > previously at: > > http://thread.gmane.org/gmane.comp.gdb.devel/20117 > > > > I have now put together a table listing what register gcc uses, and how > > > > gdb does the same with this patch. See: > > http://tinyurl.com/5r2j5x6 > > > > As you see, in the end we have only uclinuxoldeabi using wrong register > > (just as now). I am not sure whether (i) this can be fixed, and (ii) > > anybody care, given that this target was proposed for deprecation in gcc > > 4.6. Anyway, if somebody cares, it can be done with a separate patch. > > > > 3. This patch also updates the logic that decides whether structure is > > returned in memory or registers. This is a black magic written by Nathan > > that I don't pretend to understand. > > > > Is this OK? I have tests still running, but they will only cover elf and > > linux, so it would be great to have somebody check behaviour for other > > targets. > > Sorry, but this doesn't make an awful lot of sense to me. For one > thing, there is no such thing as an OpenBSD ELF platform. > OpenBSD/m68k still uses a.out as its executable format. Oh. I might have mistakenly assumed that OpenBSD uses the same format on x86 and m68k. Well, if it's a.out on m68k this actually simplified things. Please refer to updated table. http://tinyurl.com/5r2j5x6 For OpenBSD/a.out, m68k-tdep.c sets structure return register to a1, which matches that GCC uses for that purpose. No need for override m68kbsd-tdep.c > Second, there is a formal System V ABI for the Motorola 68000. I > think GCC has never properly implemented that ABI. But it seems that > GCC has diverged even more from it in the last couple of years. > Probably the point has been reached that you shouldn't call this the > System V ABI anymore. So it'd make more sense to implement the GCC > ABI in its own set of functions, and leave the SVR4 variants (largely) > alone. Are there any other compilers that matter for m68k and for which GDB should be used. If not, then probably, those functions should be just renamed? > Then, m68k_reg_struct_return_r() is a nonsensical name. That function > should probably be renamed in something like > m68k_gcc_reg_struct_return_p(). Well, there's m68k_reg_struct_return_p() and m68k_reg_struct_return_r(), with the _r version being a recursive version of _p. I suppose I can add gcc to both function, but that won't change the need to have non-recursive front-end and recursive back-end functions, I don't think. > The comment isn't really helpful, > since it uses GCC-specific terminology. Can the rules be formulated > in a more GDB-centric way? I never quite understood what BLKmode is, > and I always have to look up what QI mode, SF mode, etc. etc. are. I think the problem with describing things in GDB-centric way is that nobody will be able to match that description with GCC logic -- which is pretty much the point of this function. > > Also, you should make sure that that code doesn't get used for > OpenBSD/m68k a.out, since it will be wrong. Ok, I'll think about making this code only used for ELF targets. > > Also, I think you're trying to fix too many issues in a single diff, > which makes it hard to review. Can you split this up in seperate > diffs each addressing a seperate issue? How about this split: - Register used to return structures - Logic used to decide whether a structure is returned in register - Adjusting register used for returning pointers Thanks, -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40