This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [m68k] adjust some tests


Andreas Schwab wrote:
Nathan Sidwell <nathan@codesourcery.com> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]