Issue running x64 ELF since 1803 Build Windows [Version 10.0.17134.1]

[jebos]

• Microsoft Windows [Version 10.0.17134.1]

• Since the latest Upgrade of Windows I have trouble running ELF provided by a custom yocto sdk. This used to work before the latest Windows Update. This looks exactly like Issue Issue running ARM cross compiler on WSL #1048

/opt/sdk-linux/usr/bin/arm-my-linux/arm-my-linux-gcc
cannot execute binary file: Exec format error

Some output:

readelf -e /opt/sdk-linux/usr/bin/arm-my-linux/arm-my-linux-gcc

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x4047f0
  Start of program headers:          64 (bytes into file)
  Start of section headers:          852312 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           64 (bytes)
  Number of section headers:         30
  Section header string table index: 29

[...]

 INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x0000000000001000 0x0000000000001000  R      1
      [Requesting program interpreter: /opt/sdk-linux/lib/ld-linux-x86-64.so.2]

ldd /opt/sdk-linux/usr/bin/arm-my-linux/arm-my-linux-gcc
        linux-vdso.so.1 =>  (0x00007fffd6021000)
        libstdc++.so.6 => /opt/sdk-linux/usr/bin/arm-my-linux/../../lib/libstdc++.so.6 (0x00007fb85b5c0000)
        libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fb85b2a0000)
        libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fb85b080000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb85acb0000)
        /opt/sdk-linux/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fb85ba00000)

/opt/sdk-linux/lib/ld-linux-x86-64.so.2 /opt/sdk-linux/usr/bin/arm-my-linux/arm-my-linux-gcc
arm-my-linux-gcc: fatal error: no input files
compilation terminated.

[ajssousa]

I'm also having an issue with yocto sdk since last update.

When checking for compiler ($CC) after sourcing the yocto sdk i get:

-bash: /mnt/e/edws/svn-edws/s3/S3Trunk/ThirdPartyTools/yocto/sdk/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-gcc: cannot execute binary file: Exec format error

readelf -e arm-poky-linux-gnueabi-gcc

ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x403eff
Start of program headers: 64 (bytes into file)
Start of section headers: 943096 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 9
Size of section headers: 64 (bytes)
Number of section headers: 41
Section header string table index: 38

Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040
0x00000000000001f8 0x00000000000001f8 R E 8
INTERP 0x0000000000000238 0x0000000000400238 0x0000000000400238
0x0000000000001000 0x0000000000001000 R 1
[Requesting program interpreter: /mnt/e/edws/svn-edws/s3/S3Trunk/ThirdPartyTools/yocto/sdk/sysroots/x86_64-pokysdk-linux/lib/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000
0x00000000000ca42c 0x00000000000ca42c R E 200000
LOAD 0x00000000000ca430 0x00000000006ca430 0x00000000006ca430
0x0000000000007f10 0x000000000000a400 RW 200000
DYNAMIC 0x00000000000cb318 0x00000000006cb318 0x00000000006cb318
0x00000000000001c0 0x00000000000001c0 RW 8
NOTE 0x0000000000001238 0x0000000000401238 0x0000000000401238
0x0000000000000044 0x0000000000000044 R 4
TLS 0x00000000000ca430 0x00000000006ca430 0x00000000006ca430
0x0000000000000000 0x0000000000000010 R 8
GNU_EH_FRAME 0x00000000000b9920 0x00000000004b9920 0x00000000004b9920
0x00000000000023ec 0x00000000000023ec R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 10

[jebos]

After downgrade to previous Windows Version I can run the binary again. No Workaround or anything required, pretty sure its not a 32 Bit Issue here.

[ajssousa]

I confirm what @jebos said.
I revert the Windows to the previous build 1709, and it is working fine again.

Hope this issue will be solved soon, otherwise i cannot update Windows to 1803 build.

[nsgundy]

Seem to have the same issue here on Windows 1803 Microsoft Windows [Version 10.0.17134.48]), this used to work for me on 1709:

/opt/sdk/sysroots/x86_64-sdk-linux/usr/bin/protoc-c
-bash: /opt/sdk/sysroots/x86_64-sdk-linux/usr/bin/protoc-c: cannot execute binary file: Exec format error

strace /opt/sdk/sysroots/x86_64-sdk-linux/usr/bin/protoc-c
execve("/opt/sdk/sysroots/x86_64-sdk-linux/usr/bin/protoc-c", ["/opt/sdk/sysroots"...], [/* 18 vars */]) = -1 ENOEXEC (Exec format error)
write(2, "strace: exec: Exec format error\n", 32strace: exec: Exec format error
) = 32
exit_group(1)                           = ?
+++ exited with 1 +++

readelf -e /opt/sdk/sysroots/x86_64-sdk-linux/usr/bin/protoc-c
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              EXEC (Executable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x404840
  Start of program headers:          64 (bytes into file)
  Start of section headers:          222128 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         9
  Size of section headers:           64 (bytes)
  Number of section headers:         29
  Section header string table index: 28

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .interp           PROGBITS         0000000000400238  00000238
       0000000000001000  0000000000000000   A       0     0     1
  [ 2] .note.ABI-tag     NOTE             0000000000401238  00001238
       0000000000000020  0000000000000000   A       0     0     4
  [ 3] .note.gnu.build-i NOTE             0000000000401258  00001258
       0000000000000024  0000000000000000   A       0     0     4
  [ 4] .hash             HASH             0000000000401280  00001280
       00000000000004d0  0000000000000004   A       5     0     8
  [ 5] .dynsym           DYNSYM           0000000000401750  00001750
       0000000000000a68  0000000000000018   A       6     1     8
  [ 6] .dynstr           STRTAB           00000000004021b8  000021b8
       000000000000161f  0000000000000000   A       0     0     1
  [ 7] .gnu.version      VERSYM           00000000004037d8  000037d8
       00000000000000de  0000000000000002   A       5     0     2
  [ 8] .gnu.version_r    VERNEED          00000000004038b8  000038b8
       00000000000000d0  0000000000000000   A       6     3     8
  [ 9] .rela.dyn         RELA             0000000000403988  00003988
       0000000000000108  0000000000000018   A       5     0     8
  [10] .rela.plt         RELA             0000000000403a90  00003a90
       0000000000000738  0000000000000018  AI       5    24     8
  [11] .init             PROGBITS         00000000004041c8  000041c8
       0000000000000017  0000000000000000  AX       0     0     4
  [12] .plt              PROGBITS         00000000004041e0  000041e0
       00000000000004e0  0000000000000010  AX       0     0     16
  [13] .text             PROGBITS         00000000004046c0  000046c0
       0000000000028222  0000000000000000  AX       0     0     16
  [14] .fini             PROGBITS         000000000042c8e4  0002c8e4
       0000000000000009  0000000000000000  AX       0     0     4
  [15] .rodata           PROGBITS         000000000042c900  0002c900
       000000000000458d  0000000000000000   A       0     0     32
  [16] .eh_frame_hdr     PROGBITS         0000000000430e90  00030e90
       000000000000054c  0000000000000000   A       0     0     4
  [17] .eh_frame         PROGBITS         00000000004313e0  000313e0
       00000000000028ac  0000000000000000   A       0     0     8
  [18] .gcc_except_table PROGBITS         0000000000433c8c  00033c8c
       00000000000016ac  0000000000000000   A       0     0     4
  [19] .init_array       INIT_ARRAY       0000000000635d90  00035d90
       0000000000000010  0000000000000008  WA       0     0     8
  [20] .fini_array       FINI_ARRAY       0000000000635da0  00035da0
       0000000000000008  0000000000000008  WA       0     0     8
  [21] .jcr              PROGBITS         0000000000635da8  00035da8
       0000000000000008  0000000000000000  WA       0     0     8
  [22] .dynamic          DYNAMIC          0000000000635db0  00035db0
       0000000000000240  0000000000000010  WA       6     0     8
  [23] .got              PROGBITS         0000000000635ff0  00035ff0
       0000000000000010  0000000000000008  WA       0     0     8
  [24] .got.plt          PROGBITS         0000000000636000  00036000
       0000000000000280  0000000000000008  WA       0     0     8
  [25] .data             PROGBITS         0000000000636280  00036280
       0000000000000010  0000000000000000  WA       0     0     8
  [26] .bss              NOBITS           00000000006362a0  00036290
       0000000000000350  0000000000000000  WA       0     0     32
  [27] .gnu_debuglink    PROGBITS         0000000000000000  00036290
       0000000000000010  0000000000000000           0     0     1
  [28] .shstrtab         STRTAB           0000000000000000  000362a0
       000000000000010c  0000000000000000           0     0     1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000400040 0x0000000000400040
                 0x00000000000001f8 0x00000000000001f8  R E    8
  INTERP         0x0000000000000238 0x0000000000400238 0x0000000000400238
                 0x0000000000001000 0x0000000000001000  R      1
      [Requesting program interpreter: /opt/sdk/sysroots/x86_64-sdk-linux/lib/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x0000000000035338 0x0000000000035338  R E    200000
  LOAD           0x0000000000035d90 0x0000000000635d90 0x0000000000635d90
                 0x0000000000000500 0x0000000000000860  RW     200000
  DYNAMIC        0x0000000000035db0 0x0000000000635db0 0x0000000000635db0
                 0x0000000000000240 0x0000000000000240  RW     8
  NOTE           0x0000000000001238 0x0000000000401238 0x0000000000401238
                 0x0000000000000044 0x0000000000000044  R      4
  GNU_EH_FRAME   0x0000000000030e90 0x0000000000430e90 0x0000000000430e90
                 0x000000000000054c 0x000000000000054c  R      4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     10
  GNU_RELRO      0x0000000000035d90 0x0000000000635d90 0x0000000000635d90
                 0x0000000000000270 0x0000000000000270  R      1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .note.gnu.build-id .hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame .gcc_except_table
   03     .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss
   04     .dynamic
   05     .note.ABI-tag .note.gnu.build-id
   06     .eh_frame_hdr
   07
   08     .init_array .fini_array .jcr .dynamic .got

[nsgundy]

Going back to 1709 fixed this for me as well.

[benhillis]

An strace isn't going to be useful. Would it be possible to upload the failing binary in question?

[nsgundy]

Here is the binary in question (zipped):
protoc-c.zip

[benhillis]

@nsgundy - Thanks for sharing the binary, that made my life easy. Looks like there was an off-by-one error introduced to our ELF parser. I have submitted a fix that will get this working.

I'm of the opinion that we should backport this to 1803 but in order to get signoff I'll need to make a case. So far, as I understand it, some yocto tools that are provided by their SDK do not run. Those with more context on this thread, could you please provide me more context or details that I can use to help justify releasing this fix via Windows Update?

Thanks!

[jebos]

@benhillis Thanks, this would be great.

My case is that I'm using wsl on my daily work, cross-compiling for arm embedded linux. Without the patch I need to stay away from 1803. So 1803 stops me from working in Windows 10. Staying away from 1803 for long (until FALL) won't be an option due to our policies ect. Having a patch for 1803 would be really appreciated.

If there is no patch incoming, I fear that I will be forced to switch back to my native Linux for daily development work... that would be a shame since WSL worked flawless for me since over a year.

Thanks again. Give me a note if you need more input on making a case for the backport.

[benhillis]

@jebos - That is exactly what I was looking for, thank you!

[andyross]

Just stumbled on this myself. This also breaks the Zephyr (https://www.zephyrproject.org/ , https://github.com/zephyrproject-rtos/) SDK, which is another Yocto-derived toolchain suite.

[ajssousa]

Great finding @benhillis . Thank you

Me and my team use WSL as our development environment to do cross-compiling for ARM processors and we use yocto toolchain for that.

It would be great to fix this in 1803, otherwise I cannot update Windows 10.
At this moment it is essential for me to use WSL.

I hope we can see this fixed in 1803 soon :)

Thanks again

[nsgundy]

@benhillis Thanks for looking into this! I am in the same boat as @jebos. As it so happens, got my fingers crossed for a patch...