On Wed, Jul 19, 2017 at 5:43 PM, Georg-Johann Lay <a...@gjlay.de> wrote: > On 19.07.2017 12:46, Richard Biener wrote: >> >> On Tue, Jul 18, 2017 at 6:36 PM, Georg-Johann Lay <a...@gjlay.de> wrote: >>> >>> Hi, I tried to build a canadian cross with Configured with >>> --build=x86_64-linux-gnu >>> --host=i686-w64-mingw32 >>> --target=avr >>> >>> While the result appears to work under wine, I am getting the >>> following error from ld in a non-LTO compile + link: >>> >>> >>> e:/winavr/8.0_2017-07-18/bin/../lib/gcc/avr/8.0.0/../../../../avr/bin/ld.exe: >>> error: asprintf failed >>> >>> After playing around I found that -fno-use-linker-plugin avoids that >>> message, and I speculated that the error is emit by lto-plugin.c >>> >>> In claim_file_handler() we have: >>> >>> >>> /* We pass the offset of the actual file, not the archive header. >>> Can't use PRIx64, because that's C99, so we have to print the >>> 64-bit hex int as two 32-bit ones. */ >>> int lo, hi, t; >>> lo = file->offset & 0xffffffff; >>> hi = ((int64_t)file->offset >> 32) & 0xffffffff; >>> t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi) >>> : asprintf (&objname, "%s@0x%x", file->name, lo); >>> check (t >= 0, LDPL_FATAL, "asprintf failed"); >>> >>> >>> If hi != 0, then why is hi printed at the low end? Shouldn't hi and lo >>> be swapped like so >>> >>> t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, hi, lo) >>> >>> if this is supposed to yield a 64-bit print? >> >> >> Looks odd indeed... I suppose such large archives are the exception ;) >> >>> >>> What else could lead to an "asprintf failed" ? Unfortunately I have >>> no idea how to debug that on the host... >> >> >> memory allocation failure I guess. >> >> Richard. > > > hm, as I still have no idea how to debug, played around by changing > lto-plugin.c. I managed to get the host on virtual box so that it's > less of a pain trying around... > > My guess is that asprintf on that host is broken. config.log says > that asprintf prototypes are available and host stdio.h shows them. > > When I am replacing asprintf with allocation by hand like so: > > #if 0 > t = hi ? asprintf (&objname, "%s@0x%x%08x", file->name, lo, hi) > : asprintf (&objname, "%s@0x%x", file->name, lo); > #else > objname = xmalloc (30 + strlen (file->name)); > if (objname) > { > if (hi) > sprintf (objname, "%s@0x%x%08x", file->name, hi, lo); > else > sprintf (objname, "%s@0x%x", file->name, lo); > t = 1; > } > else > t = -2; > #endif > > then it works fine. I also hooked into xmalloc to find other > questionable allocations, but all calls of xmalloc look sane. > > For the case in question, 84 bytes are requested and with > xmalloc + sprintf it works fine, so the host-asprintf is broken > somehow. > > I also tried to remove the asprintf from host-stdio.h and hoped that > after re-configure libiberty would jump in... but no. Also I'd expected > that auto-host.h should be included before libiberty.h?
It should be included via system.h which lto-plugin.c doesn't include. Does including that after config.h work? (not sure why we check for HAVE_CONFIG_H there...). Most if not all system header includes should go away then as well. > Would a change like above be in order? (without the #if 0 of course) > It's tad that a host's function is broken, but in that case the length > is easy to compute. > > Any why is all this stuff executed anyway? It's a non-LTO compilation > with -O0, hence it's a bit surprising that ld needs to look into > libgcc.a. With the linker plugin we invoke the plugin for all compilations since we no longer require explicit -flto at link time. So we have to see whether any input contains LTO sections. Richard. > > Johann