**** BEGIN LOGGING AT Sun Jan 27 02:59:57 2019 Jan 27 10:32:39 New news from stackoverflow: Bitbake command to locate path to installed toolchain Jan 27 16:39:33 RP: Can you give a try to top two patches from http://git.openembedded.org/openembedded-core-contrib/log/?h=yoe/mut Jan 27 16:40:01 RP: I want to check if this patch is technically causing no regressions Jan 27 16:40:24 RP: and next week glibc 2.29 is releasing so I will send the patch the day it comes out Jan 27 16:40:48 I have been testing master all along so should be a simple recipe upgrade Jan 27 16:52:50 khem: that patch isn't correct :( Jan 27 16:53:06 khem: I can tell just by looking at it Jan 27 16:53:31 khem: cool on 2.29 :) Jan 27 17:04:38 RP: I think the question is should be allow -march or not Jan 27 17:05:03 I think I agree to provide an option to override MCPU is not ideal Jan 27 17:05:14 khem: I think we have to have the option Jan 27 17:05:16 I was trying to address Andre's feedback Jan 27 17:05:33 khem: the trouble with that patch is it breaks the way the tune code is meant to dynamically adjust Jan 27 17:05:41 RP: so may be add some generic tunes then ? Jan 27 17:05:47 khem: has implications for multilib and perhaps other corner cases Jan 27 17:05:58 and not let people include the arm/arch-arm.inc exclusively Jan 27 17:06:05 khem: your patch is ok, we just need to fix the dynamic adjustment Jan 27 17:07:02 explain to me the dynamic adjustments and I can see what we can do Jan 27 17:15:13 khem: if I were to include some of your tune files but select a base tune, we'd get inconsistent results Jan 27 17:15:58 khem: e.g. tune-arm1136jf-s.inc clears TUNE_MARCH even if that tune isn't selected Jan 27 17:18:20 RP: but thats the point isnt it, arm1136jf-s is a CPU imeplementation based on armv6 architecture Jan 27 17:18:45 so if you are including a tune for this then we are using that as base ISA Jan 27 17:18:49 via -mcpu Jan 27 17:20:04 khem: Its perfectly legal to include 1136jf but then set the selected tune to armv6t Jan 27 17:20:28 yes Jan 27 17:20:37 khem: your patch breaks that Jan 27 17:20:51 that will be added as separate option via -mthumb or -marm option Jan 27 17:21:37 khem: since 1136jf isn't selected, the mcpu option won't be added but with your change, the march won't be either Jan 27 17:21:47 its not represented via -mcpu option Jan 27 17:21:53 or march for that matter Jan 27 17:22:17 khem: well, what option should be passed to the compiler if the "armv6t" tune is selected? Jan 27 17:22:49 -mthumb-interwork as per OE's semantics Jan 27 17:23:02 ISA is set based on another variable Jan 27 17:23:17 ARM_INSTRUCTION_SET Jan 27 17:23:45 khem: so you're saying there shouldn't be any march, mtune or mpcu set for "armv6t" ? Jan 27 17:24:29 yes that was the point I mentioned in email thread as well.. should we demand include of a tune-*.inc file Jan 27 17:24:42 and not tune-arm.inc directly in machine configs Jan 27 17:24:59 khem: no, we shouldn't, that doesn't make sense Jan 27 17:25:02 because that assumes that we need you to define a CPU more than an arch Jan 27 17:25:18 but in a way thats what we are doing today Jan 27 17:25:32 I agree what we;re doing today breaks Jan 27 17:25:33 I am just making it explicit and logically correct Jan 27 17:25:47 no, you break some of it Jan 27 17:26:02 you do fix some cases but break others Jan 27 17:26:24 we expect mcpu to override march but in real its the opposite in gcc Jan 27 17:26:36 khem: on that I agree and understand Jan 27 17:26:49 khem: but the patch as it stands breaks some of the other tunes Jan 27 17:27:03 thats what I was asking, and no one answered Jan 27 17:27:13 khem: I did reply? Jan 27 17:27:29 does someone has cases where they dont include tune* but arch file directly Jan 27 17:27:44 khem: the people who understand this fully can probably be counted on one hand at this point :( Jan 27 17:27:57 We'll see complaints with about a 6-12 month lag as people upgrade Jan 27 17:28:09 right :) but then we need to do the right thing Jan 27 17:28:17 so choice to make Jan 27 17:28:41 do we want to give up some cpu specific opts and use march/mtune and fix it once for all Jan 27 17:29:12 should be leave out the cases where mcpu is not defined in gcc Jan 27 17:29:20 khem: or design this so both work? Jan 27 17:29:30 and lets then define tunes where they are allowed to add -march Jan 27 17:30:09 both could work I have thought of it and that is to use -march= with extentions Jan 27 17:30:37 but it means the package feed arch will be roughly equal Jan 27 17:30:41 to site you an example Jan 27 17:32:10 use -march=armv7ve+fp+neon+vfpv4 Jan 27 17:32:26 instread of -mcpu=cortex-a53 Jan 27 17:33:17 khem: 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" Jan 27 17:33:17 to be TUNE_FEATURES_tune-arm1136jfs = "arm arm1136jfs" ? Jan 27 17:33:20 we can add the fragments based on tune features Jan 27 17:33:33 that way the armv6 is dropped Jan 27 17:34:39 khem: in other words I think the bug is that armv6 is included there and shouldn't be Jan 27 17:37:25 for armv6 the lowest level of marches are ‘armv6’, ‘armv6j’, ‘armv6k’, ‘armv6kz’, ‘armv6t2’, ‘armv6z’, ‘armv6zk’ Jan 27 17:37:47 so we need to incrementally construction the march Jan 27 17:38:16 where TUNE_FEATURES_tune-armv6 seeds it with 'armv6' Jan 27 17:38:27 and then we keep appending to it based on tune features Jan 27 17:38:34 khem: I think we can do something simpler as above Jan 27 17:38:47 khem: we don't have to append it though Jan 27 17:39:00 that is currently how the files are structured but its the problem Jan 27 17:39:21 khem: nothing says "armv6" has to be in TUNE_FEATURES Jan 27 17:39:45 Its an internal hook on how we construct the values Jan 27 17:40:50 so you think if we break the include chain ? Jan 27 17:41:04 khem: I think it will then do what we want Jan 27 17:41:18 khem: let me see if I can write a patch to test Jan 27 17:42:20 so you mean replace TUNE_FEATURES_tune-arm1136jfs = "${TUNE_FEATURES_tune-armv6} arm1136jfs" with TUNE_FEATURES_tune-arm1136jfs = "armv6 arm1136jfs" Jan 27 17:43:17 khem: no, I don't Jan 27 17:44:00 khem: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=3200ec0b60a90ee2a10c06f12e463297b20887f6 Jan 27 17:44:21 khem: I just did four examples Jan 27 17:44:50 comments need fixing :) Jan 27 17:44:54 ah I see Jan 27 17:45:09 yes so basically define concrete tunes in tune files Jan 27 17:45:30 define concrete tune features Jan 27 17:46:51 yes Jan 27 17:47:20 its fine to inherit if the values are right but they're not Jan 27 17:47:47 this will flatten the structure and I think I like it but it also means the whole thing will change Jan 27 17:48:18 khem: I think that is ok Jan 27 17:48:32 so idea is define atomic base tune features and then assemble them as needed in tune files Jan 27 17:48:43 khem: yes Jan 27 17:49:05 khem: we don't need to do this everywhere, only where we have the mcpu/march conflicts Jan 27 17:49:44 I think we should do it across to be consistent Jan 27 17:50:34 khem: 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 out Jan 27 17:50:36 since when we use -mcpu and -match together gcc becomes smart and chooses the march but then compares it with internally generated march from mtune Jan 27 17:50:57 khem: lets just add a sanity test which throws a bb.fatal if we see it Jan 27 17:50:58 and complains if it finds it compatible it uses march silently Jan 27 17:51:09 so we will be chasing the ghost always Jan 27 17:51:10 i.e. ban the combination Jan 27 17:51:25 test is trivial Jan 27 17:52:04 khem: we could find out which tunes people are using this way :) Jan 27 17:52:14 so if mcpu and march are in CCARGS then throw a fatal ? Jan 27 17:52:18 * RP is only half joking Jan 27 17:52:21 khem: yes Jan 27 17:53:00 but that means we have to stop tune-* to recurse into arch-arm* Jan 27 17:53:11 when it comes to TUNE_CCARGS Jan 27 17:54:39 khem: why? Jan 27 17:55:16 khem: ll we need to do is set TUNE_FEATURES correctly in the broken cases, add the sanity test and I think we're good. Jan 27 18:06:47 khem: Need to head afk but will have a go at a patch later Jan 27 18:18:20 RP: looking at code I think if we avoid adding armv6 to TUNE_FEATURES then -march=armv6 wont be added to armv6 derivatives Jan 27 18:33:20 khem: I guess I should come up with a patch to show what I mean... Jan 27 18:34:53 RP: yes it will be a biggish patch but I think it will be right thing to do Jan 27 18:36:10 right now this recursive includes means DEFAULTTUNE constructs various settings as it includes other tunes Jan 27 18:37:17 khem: right, that will continue to work Jan 27 18:50:28 RP: I think we should also change -mfpu=name to use 'auto' Jan 27 18:50:45 so let compiler deduce the right FPU from -mcpu Jan 27 18:51:54 but thats for another day :) Jan 27 18:54:24 khem: yes! :) Jan 27 18:54:44 since this will be a prerequisite for that to work Jan 27 18:56:49 RP: btw there is -mcpu=generic-arch e.g. -mcpu=generic-armv7-a Jan 27 18:57:39 which is equivalent to -march=arch -mtune=generic-arch Jan 27 18:59:02 so may be we should replace the -march with these values Jan 27 18:59:16 in arch specific includes Jan 27 19:05:01 khem: not sure which is more confusing! Jan 27 19:05:26 using -mcpu across board is consistent IMO Jan 27 19:06:13 khem: not really convinced... Jan 27 19:07:51 khem: one step at a time I guess, lets get tis first change right Jan 27 19:08:29 but we can again postpone that Jan 27 19:08:41 after getting this first thing going Jan 27 19:08:47 nod Jan 27 19:09:41 using these fairly esoteric options would also mean I have to check what clang is doing :) Jan 27 19:28:55 RP: http://git.openembedded.org/openembedded-core-contrib/commit/?h=yoe/mut&id=3e44bd14417702936421c0e4336ad8bc14ccd791 Jan 27 19:29:05 we need to emulate this behaviour Jan 27 19:54:09 and this is portion ( for cortexa5 ) that you were thinking http://git.openembedded.org/openembedded-core-contrib/log/?h=yoe/mut Jan 27 20:04:21 RP: I see http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222 and we also need to append armv* to OVERRIDES there is lot of places where it is used Jan 27 21:04:46 sent a v3 Jan 27 22:24:58 * armpit hahah, now thats a first.. eclipse built but nothing else Jan 27 22:29:18 khem: just saw the patch, beat me to it. Looks good Jan 27 22:36:22 khem: fired a test run (inc the valgrind fix) Jan 27 23:07:09 RP, stable/thud-next clean on qa-full Jan 27 23:07:34 * armpit working on sumo-next with testimage and qa updates Jan 27 23:08:11 RP, will send pull request later Jan 28 02:35:36 New news from stackoverflow: How to build redhat root file system? [closed] **** ENDING LOGGING AT Mon Jan 28 02:59:57 2019