This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug in lto-plugin.c ?


On 19.07.2017 12:46, Richard Biener wrote:
On Tue, Jul 18, 2017 at 6:36 PM, Georg-Johann Lay <avr@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?

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.

Johann


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]