This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][libgcc] Fix PR81080, build libgcov with large file support
On June 14, 2017 6:25:52 PM GMT+02:00, Joseph Myers <joseph@codesourcery.com> wrote:
>On Wed, 14 Jun 2017, Richard Biener wrote:
>
>> The following patch makes sure we build the 32bit multilib libgcov
>with
>> large file support on x86_64-linux. libgcov.h ends up using
>auto-host.h
>> via including tconfig.h which is only valid for the main multilib
>> (and on x86_64 doesn't need explicit large-file support defines).
>That
>> libgcc ends up using that is probably from times where it wasn't at
>> the toplevel, some files already include auto-target.h generated by
>> libgcc configure but most do so after including tsystem.h which is
>> of course too late. I suppose libgcc files shouldn't include
>tconfig.h
>> from gcc/, but that's a change going to far for this bug ;)
>
>tconfig.h shouldn't include host-specific configure test results (as
>the
>relevant bits of config.in should be conditioned on USED_FOR_TARGET),
>though that doesn't mean everything is indeed properly conditioned (and
>
>ideally we'd avoid configuration information from the gcc/ directory
>needing to be used in target libraries at all).
But it seems it assumes that the results are independent on the multilib variant which is exactly the problem here - the main multilib not needing _FILE_OFFSET_BITS=32 while the 32bit one does.
>> Other than libgcov libgomp, libcilkrts, libmpx and libstdc++
>> are similarly affected (they use fopen on the 32bit multilib)
>> but not fixed. libubsan, libasan, libssp, libbacktrace and
>libgfortran
>> use open. While libgfortran configury has AC_SYS_LARGEFILE, the
>> open use leaks in through libbacktrace (ubsan/asan might have the
>> same issue, didn't investigate). libbacktrace lacks
>AC_SYS_LARGEFILE.
>
>In general, watch out for off_t etc. as part of the ABI for such
>libraries
>(in which case AC_SYS_LARGEFILE could break the ABI). And if the code
>uses fseek/ftell, it needs to change to fseeko/ftello (where available)
>to
>handle large offsets.
True. Large files should be the very exception though.
Richard.