Sunday, 2019-01-27

*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:08
*** armpit <armpit!~armpit@2601:202:4180:c33:29af:1aac:5242:8221> has joined #yocto00:10
*** everclear <everclear!> has joined #yocto00:43
*** ferlzc <ferlzc!~ferlzc@> has quit IRC01:18
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto01:18
*** gtristan <gtristan!~tristanva@> has joined #yocto03:31
*** chandana73 <chandana73!~ckalluri@> has joined #yocto03:39
*** ferlzc <ferlzc!~ferlzc@> has quit IRC04:58
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC05:23
*** harisokanovic <harisokanovic!~harisokan@> has quit IRC05:38
*** harisokanovic <harisokanovic!~harisokan@> has joined #yocto05:51
*** chandana73 <chandana73!~ckalluri@> has quit IRC06:11
*** camus <camus!~Instantbi@> has joined #yocto06:48
*** kaspter <kaspter!~Instantbi@> has quit IRC06:50
*** camus is now known as kaspter06:50
*** |King_InuYasha| <|King_InuYasha|!> has joined #yocto07:13
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has quit IRC07:16
*** tprrt <tprrt!> has joined #yocto08:49
*** kroon <kroon!> has joined #yocto09:00
*** kroon <kroon!> has quit IRC09:12
*** nighty- <nighty-!> has joined #yocto10:02
*** kroon <kroon!> has joined #yocto10:09
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto10:28
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:30
yoctiNew news from stackoverflow: Bitbake command to locate path to installed toolchain <>10:32
*** tprrt <tprrt!> has quit IRC11:10
*** slips <slips!> has quit IRC11:59
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:00
*** ferlzc <ferlzc!~ferlzc@> has joined #yocto13:23
*** wooosaiii <wooosaiii!> has joined #yocto14:42
*** wooosaiiii <wooosaiiii!> has quit IRC14:43
*** wooosaii <wooosaii!> has joined #yocto14:47
*** wooosaiii <wooosaiii!> has quit IRC14:49
*** wooosaiii <wooosaiii!> has joined #yocto14:52
*** wooosaii <wooosaii!> has quit IRC14:54
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC15:08
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto15:09
*** chandana73 <chandana73!~ckalluri@> has joined #yocto15:25
*** sagner <sagner!~ags@2a02:169:34b6::b11> has joined #yocto15:39
*** chandana73 <chandana73!~ckalluri@> has quit IRC15:41
*** tprrt <tprrt!> has joined #yocto15:47
*** nighty- <nighty-!> has quit IRC16:09
khemRP: Can you give a try to top two patches from
khemRP: I want to check if this patch is technically causing no regressions16:40
khemRP: and next week glibc 2.29 is releasing so I will send the patch the day it comes out16:40
khemI have been testing master all along so should be a simple recipe upgrade16:40
RPkhem: that patch isn't correct :(16:52
RPkhem: I can tell just by looking at it16:53
RPkhem: cool on 2.29 :)16:53
khemRP: I think the question is should be allow -march or not17:04
khemI think I agree to provide an option to override MCPU is not ideal17:05
RPkhem: I think we have to have the option17:05
khemI was trying to address Andre's feedback17:05
RPkhem: the trouble with that patch is it breaks the way the tune code is meant to dynamically adjust17:05
khemRP: so may be add some generic tunes then ?17:05
RPkhem: has implications for multilib and perhaps other corner cases17:05
khemand not let people include the arm/ exclusively17:05
RPkhem: your patch is ok, we just need to fix the dynamic adjustment17:06
khemexplain to me the dynamic adjustments and I can see what we can do17:07
RPkhem: if I were to include some of your tune files but select a base tune, we'd get inconsistent results17:15
RPkhem: e.g. clears TUNE_MARCH even if that tune isn't selected17:15
khemRP: but thats the point isnt it, arm1136jf-s is a CPU imeplementation based on armv6 architecture17:18
khemso if you are including a tune for this then we are using that as base ISA17:18
khemvia -mcpu17:18
RPkhem: Its perfectly legal to include 1136jf but then set the selected tune to armv6t17:20
RPkhem: your patch breaks that17:20
khemthat will be added as separate option via -mthumb or -marm option17:20
RPkhem: since 1136jf isn't selected, the mcpu option won't be added but with your change, the march won't be either17:21
khemits not represented via -mcpu option17:21
khemor march for that matter17:21
RPkhem: well, what option should be passed to the compiler if the "armv6t" tune is selected?17:22
khem-mthumb-interwork as per OE's semantics17:22
khemISA is set based on another variable17:23
RPkhem: so you're saying there shouldn't be any march, mtune or mpcu set for "armv6t" ?17:23
khemyes that was the point I mentioned in email thread as well.. should we demand include of a tune-*.inc file17:24
khemand not directly in machine configs17:24
RPkhem: no, we shouldn't, that doesn't make sense17:24
khembecause that assumes that we need you to define a CPU more than an arch17:25
khembut in a way thats what we are doing today17:25
RPI agree what we;re doing today breaks17:25
khemI am just making it explicit and logically correct17:25
RPno, you break some of it17:25
RPyou do fix some cases but break others17:26
khemwe expect mcpu to override march but in real its the opposite in gcc17:26
RPkhem: on that I agree and understand17:26
RPkhem: but the patch as it stands breaks some of the other tunes17:26
*** ravi <ravi!~ravi@2a02:908:698:68a0:584:157:c422:7169> has joined #yocto17:26
khemthats what I was asking, and no one answered17:27
RPkhem: I did reply?17:27
khemdoes someone has cases where they dont include tune* but arch file directly17:27
RPkhem: the people who understand this fully can probably be counted on one hand at this point :(17:27
RPWe'll see complaints with about a 6-12 month lag as people upgrade17:27
khemright :) but then we need to do the right thing17:28
khemso choice to make17:28
khemdo we want to give up some cpu specific opts and use march/mtune and fix it once for all17:28
khemshould be leave out the cases where mcpu is not defined in gcc17:29
RPkhem: or design this so both work?17:29
khemand lets then define tunes where they are allowed to add -march17:29
khemboth could work I have thought of it and that is to use -march= with extentions17:30
khembut it means the package feed arch will be roughly equal17:30
khemto site you an example17:30
khemuse -march=armv7ve+fp+neon+vfpv417:32
kheminstread of -mcpu=cortex-a5317:32
RPkhem: Looking at the code and specifically at 1136jf, could what you want not work if we change TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs"17:33
RP to be TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs" ?17:33
khemwe can add the fragments based on tune features17:33
RPthat way the armv6 is dropped17:33
RPkhem: in other words I think the bug is that armv6 is included there and shouldn't be17:34
*** kroon <kroon!> has quit IRC17:35
khemfor armv6 the lowest level of marches are ‘armv6’, ‘armv6j’, ‘armv6k’, ‘armv6kz’, ‘armv6t2’, ‘armv6z’, ‘armv6zk’17:37
khemso we need to incrementally construction the march17:37
khemwhere TUNE_FEATURES_tune-armv6 seeds it with 'armv6'17:38
khemand then we keep appending to it based on tune features17:38
RPkhem: I think we can do something simpler as above17:38
RPkhem: we don't have to append it though17:38
RPthat is currently how the files are structured but its the problem17:39
RPkhem: nothing says "armv6" has to be in TUNE_FEATURES17:39
RPIts an internal hook on how we construct the values17:39
khemso you think if we break the include chain ?17:40
RPkhem: I think it will then do what we want17:41
RPkhem: let me see if I can write a patch to test17:41
khemso you mean replace TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs" with TUNE_FEATURES_tune-arm1136jfs = "armv6 arm1136jfs"17:42
RPkhem: no, I don't17:43
RPkhem: I just did four examples17:44
RPcomments need fixing :)17:44
khemah I see17:44
khemyes so basically define concrete tunes in tune files17:45
khemdefine concrete tune features17:45
RPits fine to inherit if the values are right but they're not17:47
khemthis will flatten the structure and I think I like it but it also means the whole thing will change17:47
RPkhem: I think that is ok17:48
khemso idea is define atomic base tune features and then assemble them as needed in tune files17:48
RPkhem: yes17:48
RPkhem: we don't need to do this everywhere, only where we have the mcpu/march conflicts17:49
khemI think we should do it across to be consistent17:49
RPkhem: I disagree, we just need to fix the places its broken. There is no value in duplicating this everywhere, just where it needs to be spelt out17:50
khemsince when we use -mcpu and -match together gcc becomes smart and chooses the march but then compares it with internally generated march from mtune17:50
RPkhem: lets just add a sanity test which throws a bb.fatal if we see it17:50
khemand complains if it finds it compatible it uses march silently17:50
khemso we will be chasing the ghost always17:51
RPi.e. ban the combination17:51
RPtest is trivial17:51
RPkhem: we could find out which tunes people are using this way :)17:52
khemso if mcpu and march are in CCARGS then throw a fatal ?17:52
* RP is only half joking17:52
RPkhem: yes17:52
khembut that means we have to stop tune-* to recurse into arch-arm*17:53
*** kroon <kroon!> has joined #yocto17:53
khemwhen it comes to TUNE_CCARGS17:53
RPkhem: why?17:54
RPkhem: ll we need to do is set TUNE_FEATURES correctly in the broken cases, add the sanity test and I think we're good.17:55
*** chandana73 <chandana73!~ckalluri@> has joined #yocto18:01
RPkhem: Need to head afk but will have a go at a patch later18:06
*** gtristan <gtristan!~tristanva@> has quit IRC18:08
khemRP: looking at code I think if we avoid adding armv6 to TUNE_FEATURES then -march=armv6 wont be added to armv6 derivatives18:18
*** tprrt <tprrt!> has quit IRC18:21
*** kroon <kroon!> has quit IRC18:26
RPkhem: I guess I should come up with a patch to show what I mean...18:33
khemRP: yes it will be a biggish patch but I think it will be right thing to do18:34
khemright now this recursive includes means DEFAULTTUNE constructs various settings as it includes other tunes18:36
RPkhem: right, that will continue to work18:37
*** kroon <kroon!> has joined #yocto18:39
*** WillMiles <WillMiles!> has joined #yocto18:41
khemRP: I think we should also change -mfpu=name to use 'auto'18:50
khemso let compiler deduce the right FPU from -mcpu18:50
khembut thats for another day :)18:51
*** ravi <ravi!~ravi@2a02:908:698:68a0:584:157:c422:7169> has quit IRC18:53
RPkhem: yes! :)18:54
khemsince this will be a prerequisite for that to work18:54
khemRP: btw there is -mcpu=generic-arch e.g. -mcpu=generic-armv7-a18:56
khemwhich is equivalent to -march=arch -mtune=generic-arch18:57
khemso may be we should replace the -march with these values18:59
khemin arch specific includes18:59
RPkhem: not sure which is more confusing!19:05
khemusing -mcpu across board is consistent IMO19:05
RPkhem: not really convinced...19:06
RPkhem: one step at a time I guess, lets get tis first change right19:07
khembut we can again postpone that19:08
khemafter getting this first thing going19:08
khemusing these fairly esoteric options would also mean I have to check what clang is doing :)19:09
*** remcycles <remcycles!> has joined #yocto19:13
khemwe need to emulate this behaviour19:29
*** WillMiles <WillMiles!> has quit IRC19:32
*** aleblanc <aleblanc!~aleblanc@2607:f2c0:95d9:8500:5de2:6581:5c40:650> has quit IRC19:39
*** aleblanc <aleblanc!~aleblanc@2607:f2c0:95d9:8500:158d:788b:8f6c:7350> has joined #yocto19:40
khemand this is portion ( for cortexa5 ) that you were thinking
khemRP: I see and we also need to append armv* to OVERRIDES there is lot of places where it is used20:04
*** sagner <sagner!~ags@2a02:169:34b6::b11> has quit IRC20:10
*** |King_InuYasha| <|King_InuYasha|!> has quit IRC20:10
*** King_InuYasha <King_InuYasha!~King_InuY@fedora/ngompa> has joined #yocto20:11
*** sagner <sagner!~ags@2a02:169:34b6::d58> has joined #yocto20:15
*** RB2 <RB2!> has quit IRC20:23
*** RB2 <RB2!> has joined #yocto20:25
*** chandana73 <chandana73!~ckalluri@> has quit IRC20:45
*** vmeson <vmeson!> has quit IRC21:02
khemsent a v321:04
*** TurBoss <TurBoss!turbossmat@gateway/shell/> has left #yocto21:08
*** TurBoss <TurBoss!turbossmat@gateway/shell/> has joined #yocto21:26
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto21:32
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto21:33
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto21:33
*** remcycles <remcycles!> has quit IRC21:38
*** kroon <kroon!> has quit IRC21:49
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto21:50
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC21:55
*** camus <camus!~Instantbi@> has joined #yocto22:02
*** kaspter <kaspter!~Instantbi@> has quit IRC22:06
*** camus is now known as kaspter22:06
*** chandana73 <chandana73!~ckalluri@> has joined #yocto22:07
*** ravi <ravi!~ravi@2a02:908:698:68a0:584:157:c422:7169> has joined #yocto22:18
*** everclear <everclear!> has quit IRC22:20
* armpit hahah, now thats a first.. eclipse built but nothing else22:24
*** sagner <sagner!~ags@2a02:169:34b6::d58> has quit IRC22:27
*** ravi <ravi!~ravi@2a02:908:698:68a0:584:157:c422:7169> has quit IRC22:28
RPkhem: just saw the patch, beat me to it. Looks good22:29
RPkhem: fired a test run (inc the valgrind fix)22:36
armpitRP, stable/thud-next clean on qa-full23:07
* armpit working on sumo-next with testimage and qa updates23:07
armpitRP, will send pull request later23:08
*** vmeson <vmeson!> has joined #yocto23:09
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto23:36

Generated by 2.11.0 by Marius Gedminas - find it at!