Re: [PATCH] Fix tests that are testing obsoleted functionality

[Palmer Dabbelt <palmer at dabbelt dot com>]

On Thu, 24 Aug 2017 16:11:21 PDT (-0700), carlos@redhat.com wrote:
> On 08/24/2017 06:55 PM, Steve Ellcey wrote:
>> Here is a patch to fix three tests; malloc/tst-mallocstate.c,
>> math/test-matherr.c, and math/test-matherr-2.c.  These tests
>> test functionality that is no longer in the latest GLIBC but
>> should still exist for programs linked with an older GLIBC.
>> If you have a new ABI (like ILP32 aarch64) which never existed
>> in the older form, these tests will fail. tst-mallocstate.c
>> and test-matherr.c give link errors and test-matherr-2.c
>> compiles and links but exits with status 1.
>>
>> See https://sourceware.org/ml/libc-alpha/2017-08/msg01127.html
>> and https://sourceware.org/ml/libc-alpha/2016-12/msg00527.html
>> for some more discussions on this problem.
>>
>> This patch fixes the tests so that they will compile and
>> link and, if on a platform that does not support the functionality
>> being tested return an UNSUPPORTED return code.  They continue
>> to run and pass as before on other platforms.  To do this
>> I created a new macro TEST_COMPAT, similar to SHLIB_COMPAT
>> that can be used to check for the abi versions available
>> when building the test.
>>
>> Tested on aarch64 with LP64 (where they run) and ILP32 (where
>> they return unsupported).  While I tested this with the aarch64
>> ILP32 ABI, they changes are not specific to any ABI so I would
>> like to check them in now and not wait for aarch64 ILP32 or some
>> other new ABI get checked in first.
>>
>> Steve Ellcey
>> sellcey@cavium.com
>>
>>
>> 2017-08-24  Steve Ellcey  <sellcey@cavium.com>
>>
>> 	* include/shlib-compat.h (TEST_COMPAT): New Macro.
>> 	* malloc/tst-mallocstate.c: Convert from test-skeleton
>> 	to test-driver.  Ifdef code using TEST_COMPAT macro.
>> 	* math/test-matherr-2.c: Ifdef test using TEST_COMPAT macro.
>> 	* math/test-matherr.c: Likewise.
>>
>
> From a high-level perspective this looks good to me.
>
> I know we're not supposed to do anything special on master for
> AArch64 ILP32, but this kind of generic cleanup that future-proofs
> the test for new arches (we are expecting RISC-V port to turn
> up soon and they would have seen this) is a win win.

Thanks for the heads up -- our port is still a WIP, I was waiting until we have
Linux a bit farther along before submitting a v2.  I'm pretty sure I have a
version of these floating around my tree somewhere, now it can disappear when I
merge.

> I'd like one other developer to ACK before you commit this, since
> I'd like to hear a few more opinions on how we might handle this.