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

jebos · 2018-05-05T20:58:17Z

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.

The text was updated successfully, but these errors were encountered:

ajssousa · 2018-05-08T08:41:38Z

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 · 2018-05-08T21:07:48Z

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 · 2018-05-11T10:30:01Z

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 · 2018-05-14T11:35:18Z

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 · 2018-05-14T12:07:10Z

Going back to 1709 fixed this for me as well.

benhillis · 2018-05-14T13:59:50Z

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

nsgundy · 2018-05-14T15:19:22Z

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

benhillis · 2018-05-14T20:08:40Z

@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 · 2018-05-14T20:41:22Z

@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 · 2018-05-14T20:52:55Z

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

andyross · 2018-05-15T04:02:15Z

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 · 2018-05-15T07:55:15Z

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 · 2018-05-15T19:43:17Z

@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...

benhillis · 2018-05-15T22:48:34Z

Thanks everyone, I think we have a very good case for getting this fix backported. The fix for this has been checked in and will be making its way to the flighting branch in the coming weeks. After that fix is public it would be useful for somebody on this thread to ensure this fixes all the issues they are having.

nsgundy · 2018-05-18T09:49:47Z

Standing by :) 1803 is now knocking on my door every day and I have to tell it to go away manually since I cannot change the update settings as that's controlled centrally.

Edit: Actually today was the last day I could press the "later" option on the update, the option to defer updates for up to a certain number of days is set to 5 and I cannot change it (again, domain policy). So I have just enabled "Pause Updates", buying an extra 35 days until 2018-06-22...

kylemanna · 2018-05-18T18:44:18Z

Hey all, I'm affected by this as well with a Yocto built SDK that no longer functions after updating to 1803. Looking forward to the fix. Member of our development team that made the decision to run Windows are disrupted.

Downgrading to 1709 resolved this.

ryan-ouster · 2018-05-18T18:47:40Z

Downgrading to 1709 fixed it.

Pause updates checked, hopefully it gets fixed by 6/22/18!

zedaav · 2018-05-30T12:48:20Z

Hey here,
opened #3259 by mistake (didn't see that one).
exactly the same problem here.
Will follow this ticket to be notified when the fix is back-ported to 1803.
@benhillis : any idea about an expected ETA?
thanks!

benhillis · 2018-06-06T17:46:36Z

This is fixed in 17686, please let me know if this resolves your issues and I will begin the backporting process.

nsgundy · 2018-06-07T07:49:51Z

@benhillis Unfortunately I'd like to stick to the stable releases... is there a less-intrusive way to test this?

benhillis · 2018-06-07T13:03:58Z

Unfortunately not.

carlescufi · 2018-06-11T09:02:52Z

Second the issue regarding the Zephyr SDK mentioned by @andyross. Our toolchain is yocto-based and we suffer from the same bug in 1803, which is preventing Zephyr developers from building on WSL. Currently running 17134.48

zedaav · 2018-06-14T06:25:05Z

Hi @benhillis
Just got build 17686 from Windows Insiders program.
I confirm that it fixes my problem, thanks for that!
Looking forward to have it patched on 1803 through Windows Update!

benhillis · 2018-06-14T13:00:14Z

Thanks for confirming, I've started the backporting process.

harisjlatif · 2018-06-19T18:13:41Z

My work's domain policy does not allow Insiders program. Is there a way to manually apply a fix as I cannot revert back to 1709?

therealkenc · 2018-06-19T21:04:17Z

There isn't a way to manually apply the fix. But maybe Ben can give some details about what makes these Yocto binaries so "weird" in the first place. Possibly you can just use the stock Ubuntu arm gcc cross compiler as a work-around. I am not clear on whether there is something special about Yocto's gcc that makes using their compiler build (contrast sdk) strictly necessary.

It would be better if Yocto's binary just worked, natch. But since you're locked into a "can't go back can't go forward" situation, I'm just looking for possible solutions in the interim. If the difference in their binary isn't critical, maybe it could even be addressed upstream. Anyway just spit-balling.

jebos · 2018-07-19T20:07:38Z

@benhillis is there any ETA for the backport to 1803? Thanks for your effort.

benhillis · 2018-07-19T20:13:15Z

@jebos - It's in the pipeline, but I don't know much beyond that.

JCYang · 2018-07-25T03:20:29Z

Just upgrade to 17134.191 today, still not fixed yet. Doesn't the backport process take too long time? More than one month already, the best bet is next Tuesday update, though it's two weeks away, yet who knows whether it will be there. Maybe we should wait another month?
Does microsoft force all users to go insider? This is not practical, the new half-year release/upgrade cycle is already fast enough for most users.

ndanzi · 2018-08-30T06:59:19Z

Any news?

chrisella · 2018-09-21T14:12:50Z

@benhillis Any news on the backport ? It's been a couple of months since any update here and I'm still experiencing this exact issue on 1803. Thanks

benhillis · 2018-09-21T14:15:21Z

Unfortunately due to some circumstances out of my control this fix got pushed to the next servicing Window. October is the last date I heard. Sorry for the delay, I'm frustrated with this as well.

chrisella · 2018-09-21T14:20:16Z

Ok, thanks nonetheless for the quick reply and update

carlescufi · 2018-10-03T18:49:39Z

@benhillis does 1809 fix this issue?

benhillis · 2018-10-03T19:31:27Z

@carlescufi - Yes the fix for this issue is in 1809.

chrisella · 2018-10-04T07:03:34Z

I'm assuming that Windows server 2019 that is releasing imminently will already have this fix in it ? We are moving our build servers to that once it releases to take advantage of WSL instead of requiring a separate Linux or Docker setup.

carlescufi · 2018-10-04T08:21:21Z

Just stumbled on this myself. This also breaks the Zephyr (zephyrproject.org , @zephyrproject-rtos) SDK, which is another Yocto-derived toolchain suite.

@andyross this is fixed now, I just built Zephyr on WSL

benhillis · 2018-10-04T14:17:39Z

@chrisella - correct, Server 2019 has the fix as well.

ad-on-is · 2018-10-05T11:33:24Z

Not fixed for ELF32, at least not for me:

bash: ./arm-v7a8v4r3-linux-gnueabi-gcc: cannot execute binary file: Exec format error

readelf -e arm-v7a8v4r3-linux-gnueabi-gcc

ELF Header:
Magic:   7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class:                             ELF32
Data:                              2's complement, little endian
Version:                           1 (current)
OS/ABI:                            UNIX - System V
ABI Version:                       0
Type:                              EXEC (Executable file)
Machine:                           Intel 80386
Version:                           0x1
Entry point address:               0x804cf58
Start of program headers:          52 (bytes into file)
Start of section headers:          1591256 (bytes into file)
Flags:                             0x0
Size of this header:               52 (bytes)
Size of program headers:           32 (bytes)
Number of program headers:         8
Size of section headers:           40 (bytes)
Number of section headers:         38
Section header string table index: 35

WSLUser · 2018-10-05T12:52:31Z

@ad-on-is That's because you need to use qemu for 32 bit support. See #2468.

benhillis added bug fixinbound labels May 14, 2018

benhillis self-assigned this May 15, 2018

0xbadfca11 mentioned this issue May 30, 2018

"Exec format error" when calling Yocto toolchain GCC compiler #3259

Closed

therealkenc added fixedininsiderbuilds and removed fixinbound labels Jun 14, 2018

vanwinkeljan mentioned this issue Oct 8, 2018

gcc: "Exec format error" - WSL in Windows 10 1803 zephyrproject-rtos/zephyr#10420

Closed

therealkenc added fixedin1809 and removed bug fixedininsiderbuilds labels Oct 8, 2018

therealkenc closed this as completed Oct 8, 2018

therealkenc mentioned this issue Jun 27, 2019

Can offer some 32-bit distrubution for choose? #4215

Closed

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

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

Comments

jebos commented May 5, 2018

ajssousa commented May 8, 2018 • edited Loading

jebos commented May 8, 2018 • edited Loading

ajssousa commented May 11, 2018

nsgundy commented May 14, 2018 • edited Loading

nsgundy commented May 14, 2018

benhillis commented May 14, 2018

nsgundy commented May 14, 2018

benhillis commented May 14, 2018

jebos commented May 14, 2018

benhillis commented May 14, 2018

andyross commented May 15, 2018

ajssousa commented May 15, 2018

nsgundy commented May 15, 2018

benhillis commented May 15, 2018

nsgundy commented May 18, 2018 • edited Loading

kylemanna commented May 18, 2018

ryan-ouster commented May 18, 2018

zedaav commented May 30, 2018

benhillis commented Jun 6, 2018

nsgundy commented Jun 7, 2018

benhillis commented Jun 7, 2018

carlescufi commented Jun 11, 2018 • edited Loading

zedaav commented Jun 14, 2018

benhillis commented Jun 14, 2018

harisjlatif commented Jun 19, 2018

therealkenc commented Jun 19, 2018

jebos commented Jul 19, 2018

benhillis commented Jul 19, 2018

JCYang commented Jul 25, 2018

ndanzi commented Aug 30, 2018

chrisella commented Sep 21, 2018

benhillis commented Sep 21, 2018

chrisella commented Sep 21, 2018

carlescufi commented Oct 3, 2018

benhillis commented Oct 3, 2018

chrisella commented Oct 4, 2018 • edited Loading

carlescufi commented Oct 4, 2018

benhillis commented Oct 4, 2018

ad-on-is commented Oct 5, 2018 • edited Loading

WSLUser commented Oct 5, 2018

ajssousa commented May 8, 2018 •

edited

Loading

jebos commented May 8, 2018 •

edited

Loading

nsgundy commented May 14, 2018 •

edited

Loading

nsgundy commented May 18, 2018 •

edited

Loading

carlescufi commented Jun 11, 2018 •

edited

Loading

chrisella commented Oct 4, 2018 •

edited

Loading

ad-on-is commented Oct 5, 2018 •

edited

Loading