From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9322 invoked by alias); 5 Jun 2006 17:07:09 -0000 Received: (qmail 9314 invoked by uid 22791); 5 Jun 2006 17:07:08 -0000 X-Spam-Check-By: sourceware.org Received: from intranet.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.6) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 05 Jun 2006 17:07:06 +0000 Received: (qmail 20487 invoked from network); 5 Jun 2006 17:07:04 -0000 Received: from unknown (HELO ?192.168.189.145?) (nathan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jun 2006 17:07:04 -0000 Message-ID: <44846472.4050408@codesourcery.com> Date: Mon, 05 Jun 2006 17:07:00 -0000 From: Nathan Sidwell User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) MIME-Version: 1.0 To: Andreas Schwab CC: gdb-patches@sourceware.org Subject: Re: [m68k] adjust some tests References: <44845086.9010708@codesourcery.com> In-Reply-To: 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/msg00041.txt.bz2 Andreas Schwab wrote: > Nathan Sidwell writes: > > >>Coldfire has no jbsr instruction, > > > Neither does m68k. The assembler translates it to bsr.s/bsr.w/bsr.l/jsr, > whichever fits best. you're correct. My explanation was incorrect. I've remembered what was going on now. The asm-source tests are assembled using default options. That defaults to m68020 capabilities and the jbsr gets assembled to one of the bsr instructions. However, using a 'jsr' directly in the source forces emission of a jsr, which is available on all m68k/cf cores, and allows the resultant executable to be run on any of them. The asm-source tests don't pay attention to any multilib or compiler specific flags so I can't see a way to specify to the assembler what the target cpu really is. I suppose it would be possible to assemble and link the sources with gcc's --no-startfiles --no-stdlib options. That would allow this test to work with multilibs, pass the right options from cflags, and avoid the need for a fully specified path for any linker script that is needed. However it would tie the gdb testsuite to gcc. Although I guess this test could probe the compiler and discover whether it was gcc or not, and do the above if it was or fall back on the old behaviour if it wasn't. would something like that be acceptable? nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk