mbox series

[0/4] gprofng: small testsuite adjustments

Message ID fb6f3da8-42fc-6911-fcc9-a444bc41df0c@suse.com
Headers
Series gprofng: small testsuite adjustments |

Message

Jan Beulich Dec. 16, 2022, 8:26 a.m. UTC 
  While the latter two patches are purely cosmetic, I wonder how things have
worked properly without the former two. I'm therefore not going to exclude that
the changes done really need to be conditional upon some environmental aspects,
but it's not clear to me what these would be (or why).

Beyond / independent of these small fixes I'm still concerned by the time
running these testcases takes: The few tests here take quite a bit longer than
building _and_ testing all of the rest of binutils (not gdb of course) for
those targets where gprofng is actually available. One aspect I'm wondering
about in particular: What is it that is actually tested when the binutils build
is a cross one? The produced binaries are host executables, so it's unclear to
me what meaning it has to run on them a profiler (supposedly) targeting another
architecture. Eliminating the testing in such cases would already speed up the
mass testing of many targets in a noticable way.

There are still "warning: always_inline function might not be inlinable"
instances left with the gcc version I'm using, but I can't tell whether that's
a reason for worrying.

1: adjust linking of synprog
2: correct names for signal handling tests
3: correct line continuation in endcases.c
4: eliminate bogus casts

Jan

Comments

Jan Beulich Dec. 16, 2022, 8:36 a.m. UTC | #1 
On 16.12.2022 09:26, Jan Beulich via Binutils wrote:
> Beyond / independent of these small fixes I'm still concerned by the time
> running these testcases takes: The few tests here take quite a bit longer than
> building _and_ testing all of the rest of binutils (not gdb of course) for
> those targets where gprofng is actually available. One aspect I'm wondering
> about in particular: What is it that is actually tested when the binutils build
> is a cross one? The produced binaries are host executables, so it's unclear to
> me what meaning it has to run on them a profiler (supposedly) targeting another
> architecture. Eliminating the testing in such cases would already speed up the
> mass testing of many targets in a noticable way.

And just now I spotted this

set pltf [exec uname -i]

in display.exp. Shouldn't this check that the resulting $pltf actually
matches the build target before performing any of the tests?

Jan
Vladimir Mezentsev Dec. 16, 2022, 8:16 p.m. UTC | #2 
On 12/16/22 00:26, Jan Beulich wrote:
> While the latter two patches are purely cosmetic, I wonder how things have
> worked properly without the former two. I'm therefore not going to exclude that
> the changes done really need to be conditional upon some environmental aspects,
> but it's not clear to me what these would be (or why).
>
> Beyond / independent of these small fixes I'm still concerned by the time
> running these testcases takes: The few tests here take quite a bit longer than
> building _and_ testing all of the rest of binutils (not gdb of course) for
> those targets where gprofng is actually available. One aspect I'm wondering
> about in particular: What is it that is actually tested when the binutils build
> is a cross one?

Nothing.

>   The produced binaries are host executables, so it's unclear to
> me what meaning it has to run on them a profiler (supposedly) targeting another
> architecture. Eliminating the testing in such cases would already speed up the
> mass testing of many targets in a noticable way.

Agree.
We need to ignore `make check` for the cross build.

I'd rather test the installed binaries.
Can we add the check-install  target in Makefile for this ?

I use a big testsuite for gprofng.
The testsuite has ~400 tests and takes ~4 hours.
The problem is that tests are only available in Oracle.

> There are still "warning: always_inline function might not be inlinable"
> instances left with the gcc version I'm using, but I can't tell whether that's
> a reason for worrying.
>
> 1: adjust linking of synprog
> 2: correct names for signal handling tests
> 3: correct line continuation in endcases.c
> 4: eliminate bogus casts

Your patches look good to me.

Thank you for the gprofng improvement.
-Vladimir