From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22641 invoked by alias); 5 Jun 2006 19:27:08 -0000 Received: (qmail 22617 invoked by uid 22791); 5 Jun 2006 19:27:06 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Mon, 05 Jun 2006 19:26:27 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FnKiR-0007qo-Uf; Mon, 05 Jun 2006 15:26:20 -0400 Date: Mon, 05 Jun 2006 19:27:00 -0000 From: Daniel Jacobowitz To: Nathan Sidwell Cc: Andreas Schwab , gdb-patches@sourceware.org Subject: Re: [m68k] adjust some tests Message-ID: <20060605192619.GA29953@nevyn.them.org> Mail-Followup-To: Nathan Sidwell , Andreas Schwab , gdb-patches@sourceware.org References: <44845086.9010708@codesourcery.com> <44846472.4050408@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44846472.4050408@codesourcery.com> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes 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/msg00043.txt.bz2 On Mon, Jun 05, 2006 at 06:05:54PM +0100, Nathan Sidwell wrote: > 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? We've been back and forth around this many times, see most recently revision 1.48 of asm-source.exp. Let's not go around it again. I think there was some problem with using those options. But it's supposed to skip the entire test if there's any multilib flags; so if you're generating binaries you can't run, I wonder if you've got the defaults messed up somehow? -- Daniel Jacobowitz CodeSourcery