Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@cambridge.redhat.com>
To: gdb-patches@sources.redhat.com
Subject: RFA: Multilib support in gdb.asm tests
Date: Fri, 11 Jan 2002 04:08:00 -0000	[thread overview]
Message-ID: <m3wuyp5c4v.fsf@north-pole.nickc.cambridge.redhat.com> (raw)

Hi Guys.

  Whilst working through the GDB test results for the XScale
  processor, I discovered that the gdb.asm tests were not properly
  multi-libbed.  That is, when the armsrc1.s and asmsrc2.s files were
  assembled the multilib variations were not being taken into account.

  The patch below partially fixes this problem, at least for
  big-endian vs little-endian.  I did not go the whole hog however,
  because of the more generic problem of invoking the assembler 
  directly instead of via a compiler driver.  The problem is that when
  the assembler is invoked directly there is no chance to customise
  the assembled source code to suit the various different multilib
  options.  (In the XScale's case this meant not be able to choose
  between the ARM instruction set and the THUMB instruction set).

  I think that the correct solution to this problem is to use a
  compiler driver, but I suspect that the gdb.asm tests were intended
  to test GDBs support for debugging assembly files in the absence of
  a compiler.  Comments ?

  May I apply my patch ?

Cheers
        Nick


2002-01-11  Nick Clifton  <nickc@cambridge.redhat.com>

	* gdb.asm/asm-source.exp: Pass -EB or -EL on to the assembler
        if a big-endian or little-endian multilib option is being
        tested.

Index: gdb/testsuite/gdb.asm/asm-source.exp
===================================================================
RCS file: /cvs/src/src/gdb/testsuite/gdb.asm/asm-source.exp,v
retrieving revision 1.16
diff -c -3 -p -r1.16 asm-source.exp
*** asm-source.exp	2001/12/20 22:12:20	1.16
--- asm-source.exp	2002/01/11 11:58:13
*************** if { "${asm-flags}" == "" } {
*** 74,79 ****
--- 74,105 ----
      set asm-flags "-gstabs -I${srcdir}/${subdir} -I${objdir}/${subdir}"
  }
  
+ # FIXME: Invoking the assembler directly is incorrect.
+ # Although it would be good if this test could be independent of the
+ # the compiler we need it in order to ensure that we pass the correct,
+ # translated multilib options on to the assembler.
+ #
+ # For example if big-endian and little-endian multilibs are supported
+ # we may not be able to take the multilib -mbig-endian option and pass
+ # it directly to the assembler.  The spec strings in GCC may need to
+ # translate this into -EB.  For now we just hard code this translation.
+ 
+ case [target_info multilib_flags] in {
+     { *big-endian*    *-EB* *-meb* } { set asm-flags "${asm-flags} -EB" }
+     { *little-endian* *-EL* *-mel* } { set asm-flags "${asm-flags} -EL" }
+ }
+ # The "correct" thing to do is to add this line to the case statement above:
+ #
+ #   default { set asm-flags "${asm-flags} [target_info multilib_flags]" }
+ #
+ # I have not done so however because it breaks the tests for the ARM port
+ # when the THUMB multilibs are being tested.  The code in arm.inc is
+ # written in ARM not THUMB instructions, and so will not assemble if
+ # -mthumb is passed in.  Of course, if we were using GCC to drive
+ # the assembler (as we should be doing) then I could use the C pre-
+ # processor to check for the presence of a __THUMB__ define and so
+ # select the appropriate instruction sequences...
+ 
  if {[target_assemble ${src1} asmsrc1.o "${asm-flags}"] != ""} then {
       gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
  }


             reply	other threads:[~2002-01-11 12:08 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-11  4:08 Nick Clifton [this message]
2002-01-11  7:33 ` Andrew Cagney
2002-01-11  7:42   ` Andrew Cagney
2002-01-11  9:22   ` Nick Clifton
2002-01-11  9:50     ` Andrew Cagney
2002-01-20 16:19     ` Andrew Cagney
2002-01-11  9:28   ` Nick Clifton
2002-01-12  5:47     ` Mark Kettenis
2002-01-12 10:01       ` Michael Snyder
2002-01-13  0:14       ` Nick Clifton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3wuyp5c4v.fsf@north-pole.nickc.cambridge.redhat.com \
    --to=nickc@cambridge.redhat.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox