ndk r21 strip.exe failed in windows with "File truncated" error

[Yongqu]

I'm using android-ndk-r21/toolchains/llvm/prebuilt/windows-x86_64/arm-linux-androideabi/bin/strip.exe to strip symbol for a big debug version of so file we built for android. The generated libwebcore.so is 2.5G in size, and we are getting following error.
android-ndk-r21/toolchains/llvm/prebuilt/windows-x86_64/arm-linux-androideabi/bin/strip.exe:libwebcore.so: File truncated

It's interesting that the version number for strip.exe is the same in r20 and r21, and the main difference seems to be that in r20 msvcrt.dll is used, while in r21 ucrtbase.dll is used. Are you aware of issues like this? the repro .so file is too big for normal upload. Please contact [email protected] for alternative way to unload the repro debug .so file.

Meanwhile, do you think we can just use strip.exe from r20 as a temporary work around?

Thanks!
Yong

[rprichard]

@pirama-arumuga-nainar

I tried to reproduce this the obvious way with a test case with 3 functions, each with 1GiB of inline assembly padding, but that tended to break even the r20 binutils. The error message tended to be "Memory exhausted" instead of "File truncated". I suspect there are 2GiB limits even in the r20 Windows binutils. I did manage to produce a test case that worked with r20 ld.bfd but not r21 ld.bfd. I think a better test case would have gigabytes of debug info that aren't loaded onto the target.

I built the r20 Windows binutils and a ToT binutils, and the newer binutils is falling back to 32-bit I/O, whereas the r20 binutils used 64-bit I/O.

r20 (binutils-5139636):

out/binutils/win64/arm64/build/bfd/bfd-in3.h:

...
#define BFD_HOST_64_BIT long long
#define BFD_HOST_U_64_BIT unsigned long long
...
/* An offset into a file.  BFD always uses the largest possible offset
   based on the build time availability of fseek, fseeko, or fseeko64.  */
typedef BFD_HOST_64_BIT file_ptr;
typedef unsigned BFD_HOST_64_BIT ufile_ptr;
...

out/binutils/win64/arm64/build/bfd/config.h:

...
/* Define to 1 if you have the `fseeko' function. */
#define HAVE_FSEEKO 1

/* Define to 1 if you have the `fseeko64' function. */
#define HAVE_FSEEKO64 1

/* Define to 1 if you have the `ftello' function. */
#define HAVE_FTELLO 1

/* Define to 1 if you have the `ftello64' function. */
#define HAVE_FTELLO64 1
...

ToT binutils

out/binutils/win64/arm64/build/bfd/bfd-in3.h:

...
/* An offset into a file.  BFD always uses the largest possible offset
   based on the build time availability of fseek, fseeko, or fseeko64.  */
typedef long file_ptr;
typedef unsigned long ufile_ptr;
...

out/binutils/win64/arm64/build/bfd/config.h:

...
/* Define to 1 if you have the `fseeko' function. */
/* #undef HAVE_FSEEKO */

/* Define to 1 if you have the `fseeko64' function. */
/* #undef HAVE_FSEEKO64 */

/* Define to 1 if you have the `ftello' function. */
#define HAVE_FTELLO 1

/* Define to 1 if you have the `ftello64' function. */
#define HAVE_FTELLO64 1
...

Here's where autoconf goes wrong (out/binutils/win64/arm64/build/bfd/config.log):

...
configure:12904: checking for fseeko
configure:12904: /x/android/binutils/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/bin/x86_64-w64-mingw32-gcc -o conftest.exe -O2 -m64 -D__USE_MINGW_ACCESS  -static-libstdc++ -static-libgcc -O2 -m64 -Wl,--stack,12582912 conftest.c  >&5
/x/android/binutils/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/bin/../lib/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-fseeko64.o): In function `_ftelli64':
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:213: undefined reference to `__imp___pioinfo'
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:194: undefined reference to `__imp___pioinfo'
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:228: undefined reference to `__imp___pioinfo'
collect2: error: ld returned 1 exit status
...
configure:12904: checking for fseeko64
configure:12904: /x/android/binutils/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/bin/x86_64-w64-mingw32-gcc -o conftest.exe -O2 -m64 -D__USE_MINGW_ACCESS  -static-libstdc++ -static-libgcc -O2 -m64 -Wl,--stack,12582912 conftest.c  >&5
/x/android/binutils/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/bin/../lib/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-fseeko64.o): In function `_ftelli64':
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:213: undefined reference to `__imp___pioinfo'
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:194: undefined reference to `__imp___pioinfo'
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:228: undefined reference to `__imp___pioinfo'
collect2: error: ld returned 1 exit status
...
configure:12950: checking file_ptr type
configure:12959: result: long
...

[rprichard]

It looks like autoconf bypasses the system C headers when it calls fseeko and fseeko64, and that doesn't work with our mingw-w64 toolchain.

conftest.c.txt

$ /x/android/binutils/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/bin/x86_64-w64-mingw32-gcc conftest.c
/x/android/binutils/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/bin/../lib/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-fseeko64.o): In function `_ftelli64':
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:213: undefined reference to `__imp___pioinfo'
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:194: undefined reference to `__imp___pioinfo'
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:228: undefined reference to `__imp___pioinfo'

test1.c:

char fseeko();
int main() {
  return fseeko();
}

$ /x/android/binutils/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/bin/x86_64-w64-mingw32-gcc test1.c
/x/android/binutils/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/bin/../lib/gcc/x86_64-w64-mingw32/4.8.3/../../../../x86_64-w64-mingw32/lib/../lib/libmingwex.a(lib64_libmingwex_a-fseeko64.o): In function `_ftelli64':
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:213: undefined reference to `__imp___pioinfo'
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:194: undefined reference to `__imp___pioinfo'
/work/src/mingw/toolchain/mingw/mingw-w64-v6.x/mingw-w64-crt/stdio/fseeko64.c:228: undefined reference to `__imp___pioinfo'
collect2: error: ld returned 1 exit status

The calls work if I declare them using stdio.h:

#include <stdio.h>
int main() {
  return fseeko((void*)0, 0, 0);
}

$ /x/android/binutils/prebuilts/gcc/linux-x86/host/x86_64-w64-mingw32-4.8/bin/x86_64-w64-mingw32-gcc test2.c

mingw-w64's stdio.h uses inline versions of fseeko / fseeko64 when __MSVCRT_VERSION__ is 0x1400 is higher. (When I checked it was equal to 0x1400.)

  /* Shouldn't be any fseeko32 in glibc, 32bit to 64bit casting should be fine */
  /* int fseeko32(FILE* stream, _off_t offset, int whence);*/ /* fseeko32 redirects to fseeko64 */
#if __MSVCRT_VERSION__ >= 0x1400
  // Mark these as _CRTIMP to avoid trying to link in the mingwex versions.
  _CRTIMP int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
  _CRTIMP __int64 __cdecl _ftelli64(FILE *_File);
  __mingw_static_ovr int fseeko(FILE *_File, _off_t _Offset, int _Origin) {
    return fseek(_File, _Offset, _Origin);
  }
  __mingw_static_ovr int fseeko64(FILE *_File, _off64_t _Offset, int _Origin) {
    return _fseeki64(_File, _Offset, _Origin);
  }
  __mingw_static_ovr _off_t ftello(FILE *_File) {
    return ftell(_File);
  }
  __mingw_static_ovr _off64_t ftello64(FILE *_File) {
    return _ftelli64(_File);
  }
#else
  __MINGW_EXTENSION int __cdecl _fseeki64(FILE *_File,__int64 _Offset,int _Origin);
  __MINGW_EXTENSION __int64 __cdecl _ftelli64(FILE *_File);
  int fseeko64(FILE* stream, _off64_t offset, int whence);
  int fseeko(FILE* stream, _off_t offset, int whence);
  /* Returns truncated 64bit off_t */
  _off_t ftello(FILE * stream);
  _off64_t ftello64(FILE * stream);
#endif

[pirama-arumuga-nainar]

d66350ea60d043a8992ada752040fc4ea48537c3 changes the _fseeki64 declaration that @rprichard posted above. If I cherry-pick it, the rebuilt x86_64-w64-mingw32-gcc compiles conftest.c succesfully.

@rprichard I've uploaded https://android-review.googlesource.com/c/toolchain/mingw/+/1221662 for further testing.

[rprichard]

I created a test case that successfully links a 2.6GB shared object with r20 bfd and lld. On r21, it links with lld, but bfd prints the "File truncated" error. I see the same behavior targeting either arm32 or arm64. (gold seemed to hang, but maybe it would have finished if I gave it more time.)

big_link_input.py.txt

I confirmed that the patch above fixes the problem. (Rebuild mingw-w64 with the patch, rebuild binutils with the new mingw-w64.)

[DanAlbert]

@pirama-arumuga-nainar have the mingw prebuilts been updated with the merged patch, or is that still todo?

[pirama-arumuga-nainar]

@DanAlbert Yes, the mingw prebuilts have merged.

[Yongqu]

Thanks @pirama-arumuga-nainar ! Do we know when we will have a new ndk build with the fix?

[DanAlbert]

Fix is in build 6352462 on https://ci.android.com/builds/branches/aosp-ndk-release-r21/grid?