From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15701 invoked by alias); 11 Jan 2002 12:08:12 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15662 invoked from network); 11 Jan 2002 12:08:09 -0000 Received: from unknown (HELO dell-paw-2.cambridge.redhat.com) (195.224.55.226) by sources.redhat.com with SMTP; 11 Jan 2002 12:08:09 -0000 Received: from north-pole.nickc.cambridge.redhat.com (host217-35-40-66.in-addr.btopenworld.com [217.35.40.66]) by dell-paw-2.cambridge.redhat.com (Postfix) with ESMTP id 78C8A2B4E5 for ; Fri, 11 Jan 2002 12:08:08 +0000 (GMT) Received: from north-pole.nickc.cambridge.redhat.com.nickc.cambridge.redhat.com (localhost [127.0.0.1]) by north-pole.nickc.cambridge.redhat.com (Postfix) with ESMTP id E7CC11118E7 for ; Fri, 11 Jan 2002 12:02:24 +0000 (GMT) To: gdb-patches@sources.redhat.com Subject: RFA: Multilib support in gdb.asm tests From: Nick Clifton Date: Fri, 11 Jan 2002 04:08:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-01/txt/msg00282.txt.bz2 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 * 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." }