This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bug in lto-plugin.c ?
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Georg-Johann Lay <avr at gjlay dot de>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 20 Jul 2017 10:54:38 +0200
- Subject: Re: Bug in lto-plugin.c ?
- Authentication-results: sourceware.org; auth=none
- References: <596E38F1.1090201@gjlay.de> <CAFiYyc0jit-=PKtN4Qtndyg5o1wSQu4SdF1OjKrLBpxxnRbxjw@mail.gmail.com> <7d4e2827-cb2f-4c60-177c-539afcebfd37@gjlay.de>
On Wed, Jul 19, 2017 at 5:43 PM, Georg-Johann Lay <avr@gjlay.de> wrote:
> 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?
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