From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10490 invoked by alias); 15 Mar 2012 08:57:40 -0000 Received: (qmail 10478 invoked by uid 22791); 15 Mar 2012 08:57:38 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Mar 2012 08:57:25 +0000 Received: from nat-dem.mentorg.com ([195.212.93.2] helo=eu2-mail.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1S86Ut-0003Uf-NH from Thomas_Schwinge@mentor.com ; Thu, 15 Mar 2012 01:57:23 -0700 Received: from feldtkeller.schwinge.homeip.net ([172.30.64.227]) by eu2-mail.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 09:57:21 +0100 From: Thomas Schwinge To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [testuite patch] Fix cross-arch .S testsuite files compatibility In-Reply-To: <20120314201849.GB1412@host2.jankratochvil.net> References: <20120314201849.GB1412@host2.jankratochvil.net> User-Agent: Notmuch/0.9-101-g81dad07 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Thu, 15 Mar 2012 08:57:00 -0000 Message-ID: <87aa3ikzrs.fsf@schwinge.name> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00524.txt.bz2 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 2139 Hi! On Wed, 14 Mar 2012 21:20:20 +0100, Jan Kratochvil wrote: > on top of: > [SH] gdb.dwarf2 tests: use .byte4 instead of .long > http://sourceware.org/ml/gdb-patches/2012-03/msg00447.html >=20 > some parts of this patch may not be required (such as > gdb.arch/amd64-entry-value.s does not need fixes for non-amd64 asm compil= ers) > but it has been made to make gdb_ari.sh quiet with its patch posting alon= g). >=20 > No regressions on {x86_64,x86_64-m32,i686}-fedora17-linux-gnu. > gdb/testsuite/ > 2012-03-14 Jan Kratochvil >=20 > Fix build compatibility with non-x86* archs. > * gdb.arch/amd64-entry-value.s: Replace # by /**/, .long by .4byte, > .value by .2byte, drop #APP and #NO_APP. > * [...] In my patch I had explicitly taken care to replace .long with .4byte only in .debug_* sections (and only in files that are not x86-specific, as it doesn't matter for those). You're now proposing such changes, too: --- a/gdb/testsuite/gdb.dwarf2/dw2-modula2-self-type.S +++ b/gdb/testsuite/gdb.dwarf2/dw2-modula2-self-type.S @@ -22,7 +22,7 @@ But "v" has been removed afterwards. */ .data -v: .long 0 +v: .4byte 0 Or: --- a/gdb/testsuite/gdb.dwarf2/typeddwarf-amd64.S +++ b/gdb/testsuite/gdb.dwarf2/typeddwarf-amd64.S @@ -175,24 +175,24 @@ _start: .section .rodata.cst8,"aM",@progbits,8 .align 8 .LC0: - .long 0 - .long 1074266112 + .4byte 0 + .4byte 1074266112 I just wanted to check whether we can be sure that .4byte always conveys the same meaning as .long did in such cases? For example, on SH you wouldn't get the alignment mismatch error (that prompted my original patch) -- but that probably doesn't matter for the GDB testsuite, as we would always have conforming assembler files (where no assembler errors are expected; as opposed to the gas testsuite). Can there be other semantic differences between the two? (And no, I don't think you could reasonably encode ``don't allow .long -- but only in .debug_* sections'' in the ARI system...) :-) Gr=C3=BC=C3=9Fe, Thomas --=-=-= Content-Type: application/pgp-signature Content-length: 489 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJPYa7nAAoJENuKOtuXzphJs2gIALPhsAGp7kEtquFYlCu/GvJS Y2Sblt+yAFmErNOKOvyo+Y4g9xSwk0CFcLYknklOxI1dOCq08vb+n6b2pY/lzM0K oHHuL02JR3k0awyH/aowBmicJ45pC1RKJuXUWbVRRJ79rgyTra8QogI5lTOlEweH NgLY3gY+Zqhzc/dN1dNb14HwAiwOuV0aVJ2T44akzZn/EnVOVnRjmPGfOp/lu7LA 765Sh+YCP9S1NfQOqfSYBLABUWHpuFn+iFGj229o2ifAswIidHR3XzAVhPDO80rl g9UjurVH8T3uSgYHNh2koyXCmQ7WehBI1wiRcTB8cdxlkyLQTZtQlhi677WNmDw= =8vOx -----END PGP SIGNATURE----- --=-=-=--