This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

On Thu, 24 Aug 2017 16:11:21 PDT (-0700), 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
>> and
>> 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
>> 2017-08-24  Steve Ellcey  <>
>> 	* 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

> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]