[testuite patch] Fix cross-arch .S testsuite files compatibility

[testuite patch] Fix cross-arch .S testsuite files compatibility

[Jan Kratochvil]

[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]

Hi,

on top of:
	[SH] gdb.dwarf2 tests: use .byte4 instead of .long
	http://sourceware.org/ml/gdb-patches/2012-03/msg00447.html

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 compilers)
but it has been made to make gdb_ari.sh quiet with its patch posting along).

No regressions on {x86_64,x86_64-m32,i686}-fedora17-linux-gnu.

Sorry for .gz but it was 587kB otherwise.


Thanks,
Jan


gdb/testsuite/
2012-03-14  Jan Kratochvil  <jan.kratochvil@redhat.com>

	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.
	* gdb.arch/amd64-prologue-xmm.s: Likewise.
	* gdb.arch/gdb1291.s: Likewise.
	* gdb.arch/gdb1431.s: Likewise.
	* gdb.arch/i386-gnu-cfi-asm.S: Likewise.
	* gdb.dwarf2/callframecfa.S: Likewise.
	* gdb.dwarf2/clztest.S: Likewise.
	* gdb.dwarf2/dw2-modula2-self-type.S: Likewise.
	* gdb.dwarf2/implptr.S: Likewise.
	* gdb.dwarf2/pieces.S: Likewise.
	* gdb.dwarf2/typeddwarf-amd64.S: Likewise.
	* gdb.dwarf2/typeddwarf.S: Likewise.
	* gdb.dwarf2/valop.S: Likewise.
	* gdb.dwarf2/watch-notconst2.S: Likewise.
	* gdb.mi/mi2-amd64-entry-value.s: Likewise.

[-- Attachment #2: ari2b.patch.gz --]
[-- Type: application/x-gzip, Size: 52448 bytes --]

Re: [testuite patch] Fix cross-arch .S testsuite files compatibility

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]

Hi!

On Wed, 14 Mar 2012 21:20:20 +0100, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> on top of:
> 	[SH] gdb.dwarf2 tests: use .byte4 instead of .long
> 	http://sourceware.org/ml/gdb-patches/2012-03/msg00447.html
> 
> 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 compilers)
> but it has been made to make gdb_ari.sh quiet with its patch posting along).
> 
> No regressions on {x86_64,x86_64-m32,i686}-fedora17-linux-gnu.

> gdb/testsuite/
> 2012-03-14  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	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üße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: [testuite patch] Fix cross-arch .S testsuite files compatibility

[Jan Kratochvil]

On Thu, 15 Mar 2012 09:57:11 +0100, Thomas Schwinge wrote:
> 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:

I checked specifically the "v" case where .debug_info already expects it takes
_4_ bytes:
        .byte   0x4     /* DW_AT_byte_size */

It is true I did not check other cases but:


> I just wanted to check whether we can be sure that .4byte always conveys
> the same meaning as .long did in such cases?

as these testfiles were created on x86* .long is compiled there as .4byte.
This means that any such occurence of .long can be replaced by .4byte.


> Can there be other semantic differences between the two?

It is a good question and I am not aware of any such differences.


> (And no, I don't think you could reasonably encode ``don't allow .long --
> but only in .debug_* sections'' in the ARI system...)  :-)

Fortunately we do not need full freedoms for the testfiles, we may restrict
them arbitrarily as long as one can write the needed testfiles afterwards.

Some of such restrictions would affecth gdb.arch/gdb.disasm testfiles so
I rather excluded them from the ARI verifications.  gdb.arch/gdb.disasm
testfiles are not made as multi-arch, therefore these arch-compatibility
issues should not affect them.


Thanks,
Jan

Re: [testuite patch] Fix cross-arch .S testsuite files compatibility

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1426 bytes --]

Hi!

On Thu, 15 Mar 2012 10:06:02 +0100, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> On Thu, 15 Mar 2012 09:57:11 +0100, Thomas Schwinge wrote:
> > 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:
> 
> I checked specifically the "v" case where .debug_info already expects it takes
> _4_ bytes:
>         .byte   0x4     /* DW_AT_byte_size */
> 
> It is true I did not check other cases but:
> 
> 
> > I just wanted to check whether we can be sure that .4byte always conveys
> > the same meaning as .long did in such cases?
> 
> as these testfiles were created on x86* .long is compiled there as .4byte.
> This means that any such occurence of .long can be replaced by .4byte.
> 
> 
> > Can there be other semantic differences between the two?
> 
> It is a good question and I am not aware of any such differences.

Hmm, I just had a quick look, and found that, for example, tc-arm.c has
this:

    #ifdef OBJ_ELF
      { "word",	        s_arm_elf_cons, 4 },
      { "long",	        s_arm_elf_cons, 4 },

... and obj-elf.c:

      {"4byte", cons, 4},

Compared to cons, s_arm_elf_cons does quite a lot of things, for example
handle mapping symbols (which cons doesn't do, I think?).


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]

Re: [testuite patch] Fix cross-arch .S testsuite files compatibility

[Jan Kratochvil]

On Thu, 15 Mar 2012 10:32:06 +0100, Thomas Schwinge wrote:
> On Thu, 15 Mar 2012 10:06:02 +0100, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> > On Thu, 15 Mar 2012 09:57:11 +0100, Thomas Schwinge wrote:
> > > Can there be other semantic differences between the two?
> > 
> > It is a good question and I am not aware of any such differences.
> 
> Hmm, I just had a quick look, and found that, for example, tc-arm.c has
> this:
> 
>     #ifdef OBJ_ELF
>       { "word",	        s_arm_elf_cons, 4 },
>       { "long",	        s_arm_elf_cons, 4 },
> 
> ... and obj-elf.c:
> 
>       {"4byte", cons, 4},
> 
> Compared to cons, s_arm_elf_cons does quite a lot of things, for example
> handle mapping symbols (which cons doesn't do, I think?).

It does not seem to be needed for these testcases, they still PASS on:
	armv7l-unknown-linux-gnueabihf
(I did not verify if they still FAIL->PASS by their specific fixes.)


Thanks,
Jan

Re: [testuite patch] Fix cross-arch .S testsuite files compatibility

[Jan Kratochvil]

On Wed, 14 Mar 2012 21:20:20 +0100, Jan Kratochvil wrote:
> 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 compilers)
> but it has been made to make gdb_ari.sh quiet with its patch posting along).

I found it has no effect for archs in general as all these testcases are
already limited to their specific arch.  So this patch makes sense only to
quiet the ARI verification.  But I do not have access/rights for the ARI
script myself.


Regards,
Jan

Re: [testuite patch] Fix cross-arch .S testsuite files compatibility

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1388 bytes --]

Hi!

On Fri, 16 Mar 2012 09:51:58 +0100, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> On Thu, 15 Mar 2012 10:32:06 +0100, Thomas Schwinge wrote:
> > On Thu, 15 Mar 2012 10:06:02 +0100, Jan Kratochvil <jan.kratochvil@redhat.com> wrote:
> > > On Thu, 15 Mar 2012 09:57:11 +0100, Thomas Schwinge wrote:
> > > > Can there be other semantic differences between the two?
> > > 
> > > It is a good question and I am not aware of any such differences.
> > 
> > Hmm, I just had a quick look, and found that, for example, tc-arm.c has
> > this:
> > 
> >     #ifdef OBJ_ELF
> >       { "word",	        s_arm_elf_cons, 4 },
> >       { "long",	        s_arm_elf_cons, 4 },
> > 
> > ... and obj-elf.c:
> > 
> >       {"4byte", cons, 4},
> > 
> > Compared to cons, s_arm_elf_cons does quite a lot of things, for example
> > handle mapping symbols (which cons doesn't do, I think?).
> 
> It does not seem to be needed for these testcases, they still PASS on:
> 	armv7l-unknown-linux-gnueabihf
> (I did not verify if they still FAIL->PASS by their specific fixes.)

I still have some reservations about this patch, but I won't hold it up
having now now tested that it doesn't change the test results for
sh-linux-gnu cross-testing -- SH also differentiates between using
sh_elf_cons for .long/.int/etc. vs. s_uacons for .2byte/.4byte/.8byte.


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 489 bytes --]