https://sourceware.org/bugzilla/show_bug.cgi?id=31615
--- Comment #7 from Alan Modra <amodra at gmail dot com> ---
/* gcc -O3 -flto -c xxx.c; gcc -o xxx xxx.o -lm */
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
int
main (int argc, char **argv)
{
double x = 1.0;
long y = 0;
if (--argc > 0)
x = strtod (*++argv, NULL);
if (--argc > 0)
y = strtol (*++argv, NULL, 0);
printf ("%f\n", ldexp (x, y));
return 0;
}
The above simpler testcase shows the problem. Prior to my commit e7e05a9dd0,
lookup of "ldexp@@GLIBC_2.2.5" (which I verified is put in first_hash) returns
NULL due to the string pointing into freed and reused memory.
0x00005555558a66b3 in bfd_hash_lookup (table=0x555555ffe5f0,
string=0x5555563f72c8 "ldexp@@GLIBC_2.2.5", create=create@entry=false,
copy=copy@entry=false) at /home/alan/src/binutils-gdb/bfd/hash.c:564
564 && strcmp (hashp->string, string) == 0)
(gdb) p *hashp
$5 = {next = 0x0, string = 0x5555561113f0 "", hash = 337613448}
This results in no reload of libm.so.6. If libm.so.6 is reloaded (post
e7e05a9dd0) ldexp is already an indirect symbol to a defweak versioned sym from
libc.so.6, and attempting to mash in the duplicated libm.so ldexp results in a
u.i.link loop back to itself. We don't normally try to override symbols like
that, but you could argue it is a long-standing bug in
_bfd_generic_link_add_one_symbol that case is not handled gracefully.
--
You are receiving this mail because:
You are on the CC list for the bug.
