[02/13] Fix tests which expose ldbl -> _Float128 redirects
Commit Message
The ldbl redirects for ieee128 have some jagged edges when
inspecting and manipulating symbols directly.
e.g asprintf is unconditionally redirected to __asprintfieee128
thus any tests relying on GCC's redirect behavior will encounter
problems if they inspect the symbol names too closely.
I've mitigated tests which expose the limitations of the
ldbl -> f128 redirects by giving them knowledge about the
redirected symbol names.
Hopefully there isn't much user code which depends on this
implementation specific behavior.
---
elf/tst-addr1.c | 11 +++++++++++
stdio-common/tst-vfprintf-user-type.c | 4 ++++
2 files changed, 15 insertions(+)
Comments
"Paul E. Murphy" <murphyp@linux.vnet.ibm.com> writes:
> The ldbl redirects for ieee128 have some jagged edges when
> inspecting and manipulating symbols directly.
>
> e.g asprintf is unconditionally redirected to __asprintfieee128
> thus any tests relying on GCC's redirect behavior will encounter
> problems if they inspect the symbol names too closely.
>
> I've mitigated tests which expose the limitations of the
> ldbl -> f128 redirects by giving them knowledge about the
> redirected symbol names.
>
> Hopefully there isn't much user code which depends on this
> implementation specific behavior.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
On 3/13/20 4:37 PM, Tulio Magno Quites Machado Filho wrote:
> "Paul E. Murphy" <murphyp@linux.vnet.ibm.com> writes:
>
>> The ldbl redirects for ieee128 have some jagged edges when
>> inspecting and manipulating symbols directly.
>>
>> e.g asprintf is unconditionally redirected to __asprintfieee128
>> thus any tests relying on GCC's redirect behavior will encounter
>> problems if they inspect the symbol names too closely.
>>
>> I've mitigated tests which expose the limitations of the
>> ldbl -> f128 redirects by giving them knowledge about the
>> redirected symbol names.
>>
>> Hopefully there isn't much user code which depends on this
>> implementation specific behavior.
>
> Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
>
Pushed. Thank you for the review!
@@ -12,6 +12,16 @@ do_test (void)
return 1;
}
printf ("found symbol %s in %s\n", i.dli_sname, i.dli_fname);
+ if (i.dli_sname == NULL)
+ return 1;
+
+#if __LONG_DOUBLE_USES_FLOAT128 == 1
+ /* On architectures which redirect long double to
+ _Float128 (e.g powerpc64le), printf will resolve
+ to __printfieee128 due to header redirects. There
+ is no _IO_printfieee128 alias. */
+ return strcmp (i.dli_sname, "__printfieee128") != 0;
+#else
return i.dli_sname == NULL
|| (strcmp (i.dli_sname, "printf") != 0
/* On architectures which create PIC code by default
@@ -20,6 +30,7 @@ do_test (void)
are aliased and which one comes first in the
hash table is up to the linker. */
&& strcmp (i.dli_sname, "_IO_printf") != 0);
+#endif
}
#include <support/test-driver.c>
@@ -147,7 +147,11 @@ do_test (void)
/* Alias declaration for asprintf, to avoid the format string
attribute and the associated warning. */
+#if __LONG_DOUBLE_USES_FLOAT128 == 1
+ extern int asprintf_alias (char **, const char *, ...) __asm__ ("__asprintfieee128");
+#else
extern int asprintf_alias (char **, const char *, ...) __asm__ ("asprintf");
+#endif
TEST_VERIFY (asprintf_alias == asprintf);
char *str = NULL;
TEST_VERIFY (asprintf_alias (&str, "[[%P]]", 123L, 456.0) >= 0);