**** BEGIN LOGGING AT Thu Jun 14 03:00:04 2018
Jun 14 03:04:08 <khem> tlwoerner: igts possible that they are using -ffreestanding or some such option to ask gcc to ignore internal header search paths 
Jun 14 03:43:09 <khem> 3
Jun 14 08:11:00 <ant_work> khem, I am bothering #gcc people and I got confirmation of my amateurish findings
Jun 14 08:11:02 <ant_work> <apmorton> ant_work, it is indeed readdir causing the alignment fault
Jun 14 08:11:10 <ant_work> <apmorton> although given the values in the trap information I can't see _why_ - the values given for the fault address are word aligned
Jun 14 08:11:16 <ant_work> heh
Jun 14 08:19:35 <ant_work> khem: he got it :)
Jun 14 08:19:39 <ant_work> apmorton> ah, sorry - i missed the D at the end of those instructions
Jun 14 08:19:49 <ant_work> <apmorton> Prior to ARMv6, doubleword (LDRD/STRD) accesses to memory, where the address is not doubleword-aligned,
Jun 14 08:19:58 <ant_work> <apmorton> are UNPREDICTABLE
Jun 14 08:20:07 <ant_work> <apmorton> the instruction its faulting at is an LDRD (doubleword load), and the address given in the trap is only 4 byte aligned
Jun 14 08:23:29 <ant_work> apmorton> whatever compiled readdir is assuming some member of the DIR structure it gets passed is aligned to allow a LDRD instruction, and its not
Jun 14 08:23:54 <ant_work> <apmorton> that, or the compiler is generating incorrect code
Jun 14 09:29:13 <ant_work> khem, there have been binutils upgrades as well...
Jun 14 13:32:46 <khem> ant_work: I can see the bug 
Jun 14 13:33:00 <ant_work> I am compiling gdb-cross-arm
Jun 14 13:33:05 <ant_work> gm
Jun 14 13:35:01 <khem> the problem seems to be that gcc is doing an optimization to combine an arrat of two longs into a single load 
Jun 14 13:35:11 <khem> Can you try somethin ?
Jun 14 13:35:15 <ant_work> sure
Jun 14 13:35:30 <ant_work> I have the device here with serial
Jun 14 13:35:36 <Crofton|work> | ../../../../../../../../work-shared/gcc-7.3.0-r0/gcc-7.3.0/libgfortran/runtime/backtrace.c:36:10: fatal error: backtrace-supported.h: No such file or directory
Jun 14 13:35:36 <Crofton|work> |  #include "backtrace-supported.h"
Jun 14 13:35:36 <Crofton|work> |           ^~~~~~~~~~~~~~~~~~~~~~~
Jun 14 13:35:36 <Crofton|work> | compilation terminated.
Jun 14 13:35:36 <Crofton|work> | make[1]: *** [Makefile:2310: backtrace.lo] Error 1
Jun 14 13:35:38 <Crofton|work> | make[1]: *** Waiting for unfinished jobs....
Jun 14 13:35:46 <Crofton|work> on rocko with pi bsp
Jun 14 13:37:21 <khem> ant_work: what is -march/-mcpu value passed when compiling musl
Jun 14 13:38:59 <ant_work> no thumb, is  -march=armv5e -marm
Jun 14 13:39:48 <khem> ant_work: OK do you know the part name ?
Jun 14 13:40:10 <LetoThe2nd> Crofton|work: have you checked that you include the fortran fixes by ricardo?
Jun 14 13:40:21 <khem> ant_work: can you add -fno-store-merging to CFLAGS in musl recipe 
Jun 14 13:40:39 <ant_work> ok
Jun 14 13:40:51 <khem> ant_work: and then compile musl and dump libc.so and search for same patterns 
Jun 14 13:41:11 <ant_work> okay
Jun 14 13:41:17 <khem> ant_work: I would like to understand why thumb is disabled in your case 
Jun 14 13:41:24 <khem> whats the board you have 
Jun 14 13:41:56 <ant_work> well, there are a few compiled w/out thumb, in core-image-bse I see
Jun 14 13:41:58 <Crofton|work> LetoThe2nd, this is on rcoko, master is OK. Sounds liek there are some backports maybe
Jun 14 13:42:14 <ant_work> glib-2.0 gmp icu musl
Jun 14 13:42:21 * Crofton|work wonders why he always ends up in weird palces :)
Jun 14 13:42:36 <khem> ant_work: as I said yesterday non t variant of v5 is going out of support in gcc 
Jun 14 13:42:45 <ant_work> under armv5e-oe- ..
Jun 14 13:42:58 <ant_work> well, maybe is set in the recipe ?
Jun 14 13:43:58 <ant_work> see glib.2
Jun 14 13:43:59 <ant_work> ARM_INSTRUCTION_SET_armv4 = "arm"
Jun 14 13:43:59 <ant_work> ARM_INSTRUCTION_SET_armv5 = "arm"
Jun 14 13:44:30 <Crofton|work> LetoThe2nd, feels like rocko has them
Jun 14 13:44:56 <ant_work> khem, same for musl
Jun 14 13:44:59 <ant_work> # thumb1 is unsupported
Jun 14 13:44:59 <ant_work> ARM_INSTRUCTION_SET_armv5 = "arm"
Jun 14 13:44:59 <ant_work> ARM_INSTRUCTION_SET_armv4 = "arm"
Jun 14 13:46:05 <Crofton|work> ah, but not RP's
Jun 14 13:46:31 <ant_work> khem, should I first try to build using thumb?
Jun 14 13:47:12 <ant_work> or go with the -fno-store-merging ?
Jun 14 13:47:14 <khem> Crofton|work: I think these patches are not in rocko yet
Jun 14 13:47:40 <khem> ant_work: no try to build with that option -fno-store-merging
Jun 14 13:47:44 <khem> and just build musl 
Jun 14 13:47:46 <ant_work> ok
Jun 14 13:47:50 <khem> and see if it changes
Jun 14 13:47:54 <Crofton|work> 2c2f20a9756eccafac776e45e319af7666e6da96 is the one needed for rocko
Jun 14 13:48:02 <Crofton|work> biulding now
Jun 14 13:55:43 <khem> ant_work: does your build for musl shows up -mcpu used as well ?
Jun 14 13:57:06 <ant_work> no
Jun 14 14:05:51 <ant_work> khem, od  https://filebin.net/g17niupvztps17d2
Jun 14 14:06:03 <ant_work> I am rebuilding the image to run-test meanwhile
Jun 14 14:06:59 <khem> ant_work: whats your board CPU I would like to know I think we can avoid the bug 
Jun 14 14:07:07 <khem> I am not sure if someone will fix it for us
Jun 14 14:07:15 <ant_work> pxa25x
Jun 14 14:07:29 <ant_work> iirc same on pxa27x
Jun 14 14:08:44 <ant_work> khem, the assembler didn't change, isn't :/
Jun 14 14:10:33 <ant_work> so you mean it is aligned for the shorter thumb instructions?
Jun 14 14:12:16 <ant_work> abelloni, do you still have verstile around? Do you see align traps?
Jun 14 14:19:43 <abelloni> I didn't see any report
Jun 14 14:20:32 <ant_work> qemuarm does not show them, I see only on real hw
Jun 14 14:21:16 <ant_work> so it is again som elittle diff between arm926j and pxa
Jun 14 14:21:27 <abelloni> probably
Jun 14 14:21:49 <abelloni> the armv5 socs from atmel are plain arm9ejs
Jun 14 14:22:18 <abelloni> arm926ejs
Jun 14 14:23:02 <ant_work> khem, I see suggestion for using -march=native and even -mcpu...
Jun 14 14:23:55 <ant_work> I wouldn't do that now
Jun 14 14:34:32 <khem> ant_work: ah pxa, pxa25x is lubbock and pxa27x is codename bulverde these are intel xscale+iwmmxt cpus
Jun 14 14:35:21 <ant_work> there is still life in LAKML
Jun 14 14:36:51 <ant_work> even for assabet/neponset, the sa100 toys of RMK
Jun 14 14:36:53 <khem> ant_work: so you can avoid this issue by changing your defaulttune
Jun 14 14:38:19 <ant_work> hmso avoid require conf/machine/include/tune-xscale.inc
Jun 14 14:38:23 <khem> ant_work: in your machine conf include conf/machine/include/tune-xscale.inc
Jun 14 14:38:45 <khem> ant_work: and set DEFAULTTUNE = "xscale"
Jun 14 14:38:57 <ant_work> http://cgit.openembedded.org/meta-handheld/tree/conf/machine
Jun 14 14:39:00 <ant_work> see c7x0
Jun 14 14:39:19 <ant_work> the inc forces ARM_INSTRUCTION_SET = "thumb"
Jun 14 14:40:00 <ant_work> I added that a while ago
Jun 14 14:40:10 <khem> ant_work: yeah the difference is  now you set DEFAULTTUNE = "xscale"
Jun 14 14:40:44 <khem> ant_work: yeah thumb1 is kind of pushed to corner but should work mostly 
Jun 14 14:41:45 <abelloni> ant_work: if at some point, you have 5 minutes, can you confirm that the RTC driver was broken in v4.3 ? :)
Jun 14 14:41:54 <ant_work> so the tune-xscale.inc must be fixed?
Jun 14 14:41:58 <ant_work> it is now DEFAULTTUNE ?= "armv5te"
Jun 14 14:43:29 <ant_work> Iìll try that right now
Jun 14 14:43:45 <ant_work> abelloni, no real rtc on Zaurus, just the sa1100 ip
Jun 14 14:43:57 <ant_work> afair pxa just borrowed
Jun 14 14:44:00 <abelloni> I'm interested in that one
Jun 14 14:44:05 <ant_work> ok then
Jun 14 14:44:21 <abelloni> the fact is that two drivers will be loaded for the same ip
Jun 14 14:44:22 <ant_work> I have 4.4 as oldest ;) must summon the other kernels
Jun 14 14:44:29 <abelloni> rtc-sa1100 and rtc-pxa
Jun 14 14:44:44 <ant_work> at one point I did enable both on pxa27x
Jun 14 14:44:53 <ant_work> then smthg broke in kernel
Jun 14 14:45:07 <ant_work> I'll check, sure
Jun 14 14:45:56 <abelloni> ant_work: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e4302aec8a0646828a701443e303eb5ef48b37f5
Jun 14 14:48:28 <khem> ant_work: although I think gcc should be fixed for this in the end, we might need a small reproducer
Jun 14 14:49:01 <ant_work> I am pretty sure gcc7.2 was ok in this regard
Jun 14 14:49:03 <khem> ant_work: other option is to try use armv5 ( without 'e') as defaulttune 
Jun 14 14:49:21 <khem> ant_work: its possible something regressed 
Jun 14 14:50:02 <ant_work> it was after the 0051-ARM-PR-82445-suppress-32-bit-aligned-ldrd-strd-peeph.patch
Jun 14 14:50:15 <ant_work> there I could boot again \o/
Jun 14 14:51:58 <ant_work> and it was november, patch was in limbo for months
Jun 14 14:52:13 <ant_work> http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145293.html
Jun 14 14:52:56 <ant_work> so I'd say the binaries were okay back then
Jun 14 14:55:51 <ant_work> abelloni, fwiw 4.4.latest does not yet build with gcc8.1 so I doubt 4.3 will do any better
Jun 14 15:01:40 <khem> ant_work: that patch is already in gcc8
Jun 14 15:03:21 <khem> ant_work: I suppose you are trying gcc8 here right ?
Jun 14 15:05:36 <ant_work> 8.1
Jun 14 15:05:41 <ant_work> master-next
Jun 14 15:06:31 <ant_work> last year kernel moving from gcc6 to gcc7 kernel did not decompress until that patch was committed
Jun 14 15:06:49 <ant_work> err.. yea
Jun 14 15:07:10 <ant_work> on xscale
Jun 14 15:21:43 <ant_work>  khem, ok, is added to TUNE_FEATURES = "arm armv5 thumb dsp xscale"
Jun 14 15:22:16 <ant_work> still building
Jun 14 15:36:03 <ant_work> khem: assembler is slightly different  https://filebin.net/2a3jbz7azrsk4coj
Jun 14 15:36:12 <ant_work> image still cooking
Jun 14 15:37:28 <abelloni> ant_work: well, you can try v4.17-rc1 vs linux-next
Jun 14 15:37:52 <ant_work> yea, but last 'good' is 4.14 
Jun 14 15:38:01 <ant_work> for these deevices
Jun 14 15:39:58 <abelloni> ant_work: then 4.14 and 4.14 with the patch ;)
Jun 14 15:40:10 * ant_work is cornered
Jun 14 15:40:10 <abelloni> it's not like the rtc driver is moving a lot
Jun 14 15:40:40 <ant_work> I remember at one point there have been issues after 4.2
Jun 14 15:40:48 <ant_work> but we moved to 4.4
Jun 14 15:42:07 <abelloni> I didn't see any complain though :)
Jun 14 15:42:35 <ant_work> you see, we had a nice spi bug killing the lcd and backlight..all dark :)
Jun 14 15:42:47 <ant_work> a bad backport to stable
Jun 14 15:43:08 <ant_work> we have now gpio changes and keyboard mappings are wrong
Jun 14 15:43:20 <ant_work> so rtc is the last of the pile :)
Jun 14 15:44:19 <ant_work> we have fixed sound and partition parser at least
Jun 14 15:44:43 <ant_work> I think support for these device will end someday
Jun 14 15:44:54 <ant_work> will have to
Jun 14 15:50:34 <ant_work> ouch gcc-runtime fails to build...I'll have to bother khem again
Jun 14 15:52:09 <abelloni> I think boris and miquel were thinking about ripping the nand driver out of the kernel
Jun 14 15:52:28 <abelloni> it is pretty difficult to find boards to test
Jun 14 15:53:03 <abelloni> we actually bought one but the bootloader only want to boot windows ce
Jun 14 15:53:06 <abelloni> so meh..
Jun 14 15:54:10 <ant_work> ouch -mcpu=xscale switch conflicts with -march=armv5te switch
Jun 14 15:57:14 <ant_work> khem, now gcc-runtime fails to build, libstdc++/compatibility.cc
Jun 14 15:58:21 <ant_work> undefines symbol _ZNSt13basic
Jun 14 15:58:52 <ant_work> and expansion of _GLIBCXX_3_4_5_SYMVER
Jun 14 15:59:48 <ant_work> and _GLIBCXX_APPLY_SYMVER
Jun 14 16:00:36 <ant_work> doest it ring a bell? maybe the warning about conflicting switches?
Jun 14 16:05:17 <ant_work> abelloni, you can still find some cheap NOR around
Jun 14 16:05:30 <ant_work> but very small
Jun 14 16:06:15 <ant_work> https://www.ebay-kleinanzeigen.de/s-anzeige/sharp-zaurus-5500-g/876684449-168-3467
Jun 14 16:06:19 <ant_work> 10 euro
Jun 14 16:08:43 <ant_work> bbl
Jun 14 16:26:00 <khem> ah yes that march/mcpu mix I really hate 
Jun 14 16:26:14 <khem> we should just remove march when we know we want to use -mcpu 
Jun 14 16:26:18 <khem> atleast for arm
Jun 14 17:02:12 <ant_home> khem, ok, I am guinea-pigging at home
Jun 14 17:34:27 <khem> ant_home: it might be that you have to use DEFAULTTUNE = "armv5"
Jun 14 17:34:41 <khem> ant_home: see if that works with everything else remaining same 
Jun 14 18:59:38 <ant_home> khem, okm then I comment out the ARM_INSTRUCTION:SET="thumb"
Jun 14 19:45:12 <khem> ant_home: yes
Jun 14 20:58:07 <ant_home> khem, then no alignment traps
Jun 14 20:58:09 <ant_home> :)
Jun 14 20:58:13 <ant_home> this is od  https://filebin.net/p7y19db5nvxle5e8/zz2?t=h2fsyfzb
Jun 14 20:58:54 <ant_home> TUNE_FEATURES        = "arm armv5"
Jun 14 20:59:06 <ant_home> so thumb and dsp are lost
Jun 14 21:01:22 <ant_home> now trying with armv5e
Jun 14 21:08:32 <ant_home> ok, this gives TUNE_FEATURES        = "arm armv5 dsp"
Jun 14 21:09:14 <ant_home> but I see readdir seems bad again: https://filebin.net/6tamgu3tsmda06f9/zz3?t=yjwgwhoq
Jun 14 21:09:24 <ant_home> khem, so it is the 'e'
Jun 14 21:47:49 <ant_home> yes, align trap
Jun 14 21:50:46 <ant_home> trying now with TUNE_FEATURES        = "arm armv5 thumb" and forcing instruction set to use thumb
Jun 14 21:55:57 <ant_home> musl does not change, vaid readdir
Jun 14 21:56:03 <ant_home> *valid
Jun 15 02:23:15 <khem> ant_home: its a bug in gcc 
Jun 15 02:23:29 <khem> I think get along with workaround for now 
Jun 15 02:23:53 <khem> it only has to do with gcc being over enthusiastic about combining store/loads
**** ENDING LOGGING AT Fri Jun 15 03:00:10 2018