**** BEGIN LOGGING AT Fri Jun 15 03:00:10 2018 Jun 15 05:39:54 khem, ok Jun 15 05:40:20 Is there any difference between setting SSTATE_DIR and SSTATE_MIRRORS to the same local path? (SSTATE_DIR = "/tmp/yocto", SSTATE_MIRRORS = "file://.* file:///tmp/yocto/PATH") Jun 15 05:40:33 Will there be any difference in this, like the fetch speed? Jun 15 05:40:43 Can anyone please help Jun 15 09:29:55 khem, I have one report that using void linux gcc7.3 and Jun 15 09:30:04 "-march=armv5te -mtune=xscale -msoft-float -mfloat-abi=soft -Os -pipe -fomit-frame-pointer -funit-at-a-time" Jun 15 09:30:13 there are no align issues Jun 15 09:30:36 that gcc is almost vanilla Jun 15 09:30:38 https://github.com/greguu/voidz-packages/tree/voidz-packages-v01/srcpkgs/gcc/patches Jun 15 09:31:06 https://github.com/greguu/voidz-packages/blob/voidz-packages-v01/srcpkgs/gcc/template Jun 15 09:31:42 so th etrick might be -mtune=xscale Jun 15 14:53:05 yes Jun 15 14:53:13 I am bringing that patch to gcc Jun 15 14:57:53 ok, I am looking github...insane activity... Jun 15 14:59:14 can I just add this for testing right now? Jun 15 14:59:51 (PR 86003) Jun 15 15:09:41 retrying TUNE_FEATURES = "arm armv5 thumb dsp xscale" Jun 15 16:41:26 khem, gcc-cross-arm-8.1.0-r0 did compile now Jun 15 16:43:36 libgcc as well Jun 15 16:58:05 readir has again the problematic instruction Jun 15 16:58:09 1d080:<----->e1cc00d8 <----->ldrd<-->r0, [ip, #8] Jun 15 17:00:15 but assembler is different, let's try it Jun 15 17:03:01 khem: objdump of libc with -mcpu=xscale https://filebin.net/a1a72ilbjd48z7gg Jun 15 17:04:59 ant_home: I think that instruction in itself is fine Jun 15 17:05:21 but the problem is that ip contains a 32bit aligned address Jun 15 17:05:39 so we have alignement issue coming from there Jun 15 17:05:49 from dsp feature Jun 15 17:09:14 1d044: e280c01c add ip, r0, #28 Jun 15 17:09:29 so what we have in r0 matters Jun 15 17:09:48 thats the disasm from readdir function I am seeing Jun 15 17:10:03 is a bit different than before, yes Jun 15 17:10:18 w/out dsp is totally rewritten Jun 15 17:10:32 image is almost built Jun 15 17:10:57 we'll see in a few mins Jun 15 17:11:06 struct dirent *readdir(DIR *dir) Jun 15 17:11:25 so r0 contains the address of a struct DIR Jun 15 17:11:28 khem, the issue is with glibc as well Jun 15 17:11:38 code is very different Jun 15 17:12:01 if DIR is not 64bit aligned then we can not use LDRD Jun 15 17:12:14 or STRD Jun 15 17:12:26 on arm <6 Jun 15 17:13:49 khem, btw see kernel patch Jun 15 17:13:50 https://patchwork.kernel.org/patch/10196991/ Jun 15 17:21:48 yeah you need that, but thats not related here Jun 15 17:23:21 struct __dirstream Jun 15 17:23:23 { Jun 15 17:23:25 int fd; Jun 15 17:23:27 off_t tell; Jun 15 17:23:29 int buf_pos; Jun 15 17:23:31 int buf_end; Jun 15 17:23:33 volatile int lock[1]; Jun 15 17:23:35 char buf[2048]; Jun 15 17:23:37 }; Jun 15 17:23:49 now if off_t is 64bit then this struct will be aligned at 64bit as well and LDRD would work Jun 15 17:24:16 thats the only element which can push the natural alignment to 64bit Jun 15 17:24:45 for this struct ( whose address is passed in R0 of readdir call) Jun 15 17:25:03 now I wonder if we have largefile support enabled in your distro or not Jun 15 17:25:15 since off_t depends on that Jun 15 17:25:22 it can be either 32bit or 64bit Jun 15 17:28:40 booting now Jun 15 17:29:15 ouch... Jun 15 17:29:54 khem, https://pastebin.com/uHeR83MJ Jun 15 17:30:17 distro is nodistro Jun 15 17:30:50 same problem I guess Jun 15 17:31:01 same instr Jun 15 17:31:05 can you check your distro_features and see if largefile is in there Jun 15 17:31:57 yes Jun 15 17:32:29 https://pastebin.com/PgjS2AB3 Jun 15 17:36:29 so you mean the address gets truncated thus unaligne Jun 15 17:38:43 let me check whats the size of off_t Jun 15 17:40:19 heh rings a bell... Jun 15 17:41:38 like the patch for ubi-utils-klibc Jun 15 17:41:50 ant_home: https://gist.github.com/f68e61d01926bae9107ae6ba3b1a2c66 Jun 15 17:42:01 take that example and compile it like this Jun 15 17:44:25 /mnt/a/oe/build/tmp/work/armv5te-bec-linux-musleabi/busybox/1.27.2-r0/recipe-sysroot-native/usr/bin/arm-bec-linux-musleabi/arm-bec-linux-musleabi-gcc --sysroot=/mnt/a/oe/build/tmp/work/armv5te-bec-linux-musleabi/busybox/1.27.2-r0/recipe-sysroot -march=armv5te -O2 -E tests/foo.c | grep off_t Jun 15 17:44:31 and show me the output Jun 15 17:45:00 ok Jun 15 17:53:21 root@andrea-ThinkPad-T520:/tmp/build/tmp-musl/work/xscalete-oe-linux-musleabi/busybox/1.27.2-r0/busybox-1.27.2# /tmp/build/tmp-musl/work/xscalete-oe-linux-musleabi/busybox/1.27.2-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-musleabi/arm-oe-linux-musleabi-gcc --sysroot= /tmp/build/tmp-musl/work/xscalete-oe-linux-musleabi/busybox/1.27.2-r0/recipe-sysroot -march=armv5te -O2 -E tests/foo.c |grep off_t Jun 15 17:53:21 cc1: warning: include location "/usr/local/include" is unsafe for cross-compilation [-Wpoison-system-directories] Jun 15 17:53:21 cc1: warning: include location "/usr/include" is unsafe for cross-compilation [-Wpoison-system-directories] Jun 15 17:53:22 __extension__ typedef long int __off_t; Jun 15 17:53:24 typedef __off64_t __loff_t; Jun 15 17:53:26 __off_t __pos; Jun 15 17:53:28 __off_t _old_offset; Jun 15 17:53:30 typedef __off_t off_t; Jun 15 17:53:32 extern int fseeko (FILE *__stream, __off_t __off, int __whence); Jun 15 17:53:36 extern __off_t ftello (FILE *__stream) ; Jun 15 17:53:38 any idea how to install fortran comiler on target? Jun 15 17:53:38 typedef __loff_t loff_t; Jun 15 17:53:39 error: library dfftpack has Fortran sources but no Fortran compiler found Jun 15 17:53:39 error Jun 15 17:53:40 off_t blah; Jun 15 17:53:42 arm-oe-linux-musleabi-gcc: warning: /tmp/build/tmp-musl/work/xscalete-oe-linux-musleabi/busybox/1.27.2-r0/recipe-sysroot: linker input file unused because linking not done Jun 15 17:54:56 urgh..root shell Jun 15 17:55:41 khem, it is long int Jun 15 17:56:31 brb Jun 15 17:57:24 * armpit int bigly ? Jun 15 18:02:52 Crofton|work: add tools-sdk to package Jun 15 18:03:24 khem, already done Jun 15 18:03:45 root@raspberrypi3-64:~/scipy-1.1.0# gcc --version Jun 15 18:03:45 gcc (GCC) 7.3.0 Jun 15 18:04:30 this is rocko Jun 15 18:42:05 khem, we had similar prob with off_t and klibc Jun 15 18:42:08 http://cgit.openembedded.org/meta-openembedded/tree/meta-initramfs/recipes-devtools/mtd/ubi-utils-klibc-1.5.2/0004-Restore-compatibility-to-dietlibc-klibc-musl-libc-af.patch?id=edbe41f53ec15eeae4673498c41a1f3a42ac813b Jun 15 18:45:40 khem, my bad, one space left after --sysroot= Jun 15 18:45:45 tis one is correct Jun 15 18:45:46 sybox/1.27.2-r0/busybox-1.27.2# /tmp/build/tmp-musl/work/xscalete-oe-linux-musle Jun 15 18:45:47 abi/busybox/1.27.2-r0/recipe-sysroot-native/usr/bin/arm-oe-linux-musleabi/arm-oe-linux-musleabi-gcc --sysroot=/tmp/build/tmp-musl/work/xscalete-oe-linux-musleabi/busybox/1.27.2-r0/recipe-sysroot -march=armv5te -O2 -E tests/foo.c |grep off_t Jun 15 18:45:47 typedef long long off_t; Jun 15 18:45:47 int fseeko(FILE *, off_t, int); Jun 15 18:45:48 off_t ftello(FILE *); Jun 15 18:45:50 off_t blah; Jun 15 19:27:01 ant_home: ok it seems same her e Jun 15 19:37:48 khem, should I start to bisect with OE's gcc7.2? Jun 15 19:38:56 I'm puzzled by that vois linux 7.3 compiler apparently immune Jun 15 19:39:33 but he does -march=armv5te -mtune=xscale Jun 15 19:39:40 not -mcpu Jun 15 19:58:13 well, I am now back just before 'gcc: Upgrade 7.2 -> 7.3' Jun 15 23:09:06 khem, 7.2 is ok Jun 15 23:09:07 TUNE_FEATURES = "arm armv5 thumb dsp" Jun 15 23:09:07 TARGET_FPU = "soft" Jun 15 23:09:07 meta = "HEAD:af9612f5d6b848fceea22d10ee964437299be776" Jun 15 23:09:49 it fails with xscale, probably same patch as for gcc8 Jun 15 23:12:57 hmm Jun 15 23:13:10 can you upload the objdump of musl.so Jun 15 23:13:12 https://filebin.net/hvdc5d5hgbjq9vwz Jun 15 23:13:21 or just readdir.o Jun 15 23:13:30 as you say, ldrd is used but in valid way Jun 15 23:15:24 well, no align traps in the logs: https://pastebin.com/SyY5YkjG Jun 15 23:21:30 I see one difference betweeen your good and bad one Jun 15 23:21:52 stack size in good case is 32bytes for readdir for bad one its 28nytes Jun 15 23:21:57 hence the problem Jun 15 23:22:11 right, I've seen the diff of 0xa Jun 15 23:22:40 I'd have asked you about it :) Jun 15 23:23:15 but I had another valid one, without dsp, and it was #28 afair (is in the logs) Jun 15 23:24:45 that one? https://filebin.net/p7y19db5nvxle5e8/zz2?t=h2fsyfzb Jun 15 23:25:20 right, didn't use ldrd Jun 15 23:25:44 and add ip, r0, #28 Jun 15 23:33:43 see it seems to be thinking that DIR struct is 28bytes where as it should be 32 bytes if off_t was 64bit Jun 15 23:34:34 let me just know what to do to confirm your suspicions Jun 15 23:34:48 fwiw binutils was 2.29.1 Jun 15 23:36:21 ant_home: can you try this sample https://gist.github.com/419888cf5ae774354c268bec06d0e896 Jun 15 23:36:34 that checkout was 2018-01-25 Jun 15 23:36:56 binutils may not matter here Jun 15 23:37:06 you mean replacing it in musl or standalone? Jun 15 23:37:17 try this with -march=armv5e -O2 -S -ffreestanding Jun 15 23:37:27 no its a small test Jun 15 23:37:33 compile it with working and non-working gcc Jun 15 23:37:43 I am interested with working gcc Jun 15 23:37:50 non-working I have it Jun 15 23:37:59 see what is thinks of side of DIR struct Jun 15 23:43:13 https://pastebin.com/74JmQHnz Jun 15 23:54:47 khem, ok, this is the output Jun 15 23:54:49 https://pastebin.com/8jGqS0tX Jun 15 23:55:48 same with gcc 5.4 online http://rextester.com/l/c_online_compiler_gcc Jun 16 01:01:37 ant_home: add -S option which should generate asm output Jun 16 01:01:43 please share that .s file **** ENDING LOGGING AT Sat Jun 16 03:00:04 2018