[Bug ld/31615] Hang when linking vorbis-tools

[amodra at gmail dot com]

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.