mirror of
https://sourceware.org/git/glibc.git
synced 2024-12-27 21:20:18 +00:00
d0d1811fb9
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>
37 lines
1001 B
C
37 lines
1001 B
C
#include <dlfcn.h>
|
|
#include <stdio.h>
|
|
#include <string.h>
|
|
|
|
static int
|
|
do_test (void)
|
|
{
|
|
Dl_info i;
|
|
if (dladdr (&printf, &i) == 0)
|
|
{
|
|
puts ("not found");
|
|
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
|
|
&printf may resolve to an address in libc.so
|
|
rather than in the binary. printf and _IO_printf
|
|
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>
|