x86_64 specific tests in dwz vs. other architectures

x86_64 specific tests in dwz vs. other architectures

[Jakub Jelinek]

Hi!

I've only got now to try building dwz 0.13 (just a scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=39485926
) in Fedora, but looking at the build files, I see on non-x86_64
arches ugly messages like:
dw2-restrict.c: Assembler messages:
dw2-restrict.c:55: Error: unrecognized opcode: `movq'
dw2-restrict.c:58: Error: unrecognized opcode: `movq'
dw2-restrict.c:59: Error: unrecognized opcode: `movsbl'
dw2-restrict.c:60: Error: unrecognized opcode: `ret'
dw2-restrict.c:76: Error: unrecognized opcode: `pushq'
dw2-restrict.c:78: Error: unrecognized opcode: `movq'
dw2-restrict.c:80: Error: unrecognized opcode: `subq'
dw2-restrict.c:82: Error: unrecognized opcode: `leaq'
dw2-restrict.c:83: Error: unrecognized opcode: `movl'
dw2-restrict.c:86: Error: unrecognized opcode: `callq'
dw2-restrict.c:87: Error: unrecognized opcode: `addq'
dw2-restrict.c:88: Error: unrecognized opcode: `popq'
dw2-restrict.c:89: Error: unrecognized opcode: `ret'
on ppc64le, 
dw2-restrict.c: Assembler messages:
dw2-restrict.c:55: Error: bad register name `%rdi'
dw2-restrict.c:58: Error: bad register name `%rsp)'
dw2-restrict.c:59: Error: bad register name `%rdi)'
dw2-restrict.c:76: Error: bad register name `%rbp'
dw2-restrict.c:78: Error: bad register name `%rsp'
dw2-restrict.c:80: Error: bad register name `%rsp'
dw2-restrict.c:82: Error: bad register name `%rdi'
dw2-restrict.c:83: Error: bad register name `%rbp)'
dw2-restrict.c:86: Error: invalid instruction suffix for `call'
dw2-restrict.c:87: Error: bad register name `%rsp'
dw2-restrict.c:88: Error: bad register name `%rbp'
...
/builddir/build/BUILD/dwz/testsuite/dwz.tests/dw2-skip-prologue.S:309: Error: cannot represent relocation type BFD_RELOC_64
as: /tmp/ccg3sw27.o: unsupported relocation type: 0x1
on i686 etc.  Can't we ensure that the tests are assembled only on the
corresponding architecture and nowhere else if they are architecture
specific?
It is fine if some tests are UNSUPPORTED, just we should completely skip
them if they can't be assembled.

	Jakub

Re: x86_64 specific tests in dwz vs. other architectures

[Jakub Jelinek]

On Wed, Dec 11, 2019 at 10:33:33PM +0100, Tom de Vries wrote:
> > /builddir/build/BUILD/dwz/testsuite/dwz.tests/dw2-skip-prologue.S:309: Error: cannot represent relocation type BFD_RELOC_64
> > as: /tmp/ccg3sw27.o: unsupported relocation type: 0x1
> > on i686 etc.  Can't we ensure that the tests are assembled only on the
> > corresponding architecture and nowhere else if they are architecture
> > specific?
> > It is fine if some tests are UNSUPPORTED, just we should completely skip
> > them if they can't be assembled.
> 
> Indeed, the messages are ugly, but it's not a correctness problem, just
> an annoyance.
> 
> The test execs are build directly from the makefile, not by dejagnu, so
> we can't use the target testing available there. I suppose I could test
> for uname -p:
> ...
> $ uname -p
> x86_64
> ...

Yeah, and if we e.g. require GNU make to build dwz, we could use all kinds
of GNU make features to conditionalize it easily.
Though, at least for the tests where gdb isn't run on it, perhaps it might
be good enough to replace actual instructions in the assembly sources with
.skip or similar; of course it depends also if the location info doesn't
contain something horribly wrong on other architecture, probably can't mix
32-bit and 64-bit and some arches use different characters in assembly, so
maybe some portability macros and preprocessing would be needed (e.g.
arm and a few others require %progbits rather than @progbits).

	Jakub

Re: x86_64 specific tests in dwz vs. other architectures

[Tom de Vries]

> Hi!
> 
> I've only got now to try building dwz 0.13 (just a scratch build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=39485926
> ) in Fedora,

Just FYI, there's a dwz-0.13-branch that I've maintained that is 0.13 +
fixes.

> but looking at the build files, I see on non-x86_64
> arches ugly messages like:
> dw2-restrict.c: Assembler messages:
> dw2-restrict.c:55: Error: unrecognized opcode: `movq'
> dw2-restrict.c:58: Error: unrecognized opcode: `movq'
> dw2-restrict.c:59: Error: unrecognized opcode: `movsbl'
> dw2-restrict.c:60: Error: unrecognized opcode: `ret'
> dw2-restrict.c:76: Error: unrecognized opcode: `pushq'
> dw2-restrict.c:78: Error: unrecognized opcode: `movq'
> dw2-restrict.c:80: Error: unrecognized opcode: `subq'
> dw2-restrict.c:82: Error: unrecognized opcode: `leaq'
> dw2-restrict.c:83: Error: unrecognized opcode: `movl'
> dw2-restrict.c:86: Error: unrecognized opcode: `callq'
> dw2-restrict.c:87: Error: unrecognized opcode: `addq'
> dw2-restrict.c:88: Error: unrecognized opcode: `popq'
> dw2-restrict.c:89: Error: unrecognized opcode: `ret'
> on ppc64le, 
> dw2-restrict.c: Assembler messages:
> dw2-restrict.c:55: Error: bad register name `%rdi'
> dw2-restrict.c:58: Error: bad register name `%rsp)'
> dw2-restrict.c:59: Error: bad register name `%rdi)'
> dw2-restrict.c:76: Error: bad register name `%rbp'
> dw2-restrict.c:78: Error: bad register name `%rsp'
> dw2-restrict.c:80: Error: bad register name `%rsp'
> dw2-restrict.c:82: Error: bad register name `%rdi'
> dw2-restrict.c:83: Error: bad register name `%rbp)'
> dw2-restrict.c:86: Error: invalid instruction suffix for `call'
> dw2-restrict.c:87: Error: bad register name `%rsp'
> dw2-restrict.c:88: Error: bad register name `%rbp'
> ...
> /builddir/build/BUILD/dwz/testsuite/dwz.tests/dw2-skip-prologue.S:309: Error: cannot represent relocation type BFD_RELOC_64
> as: /tmp/ccg3sw27.o: unsupported relocation type: 0x1
> on i686 etc.  Can't we ensure that the tests are assembled only on the
> corresponding architecture and nowhere else if they are architecture
> specific?
> It is fine if some tests are UNSUPPORTED, just we should completely skip
> them if they can't be assembled.

Indeed, the messages are ugly, but it's not a correctness problem, just
an annoyance.

The test execs are build directly from the makefile, not by dejagnu, so
we can't use the target testing available there. I suppose I could test
for uname -p:
...
$ uname -p
x86_64
...

Thanks,
- Tom