Hi Denys, On Tue, 19 Oct 2021 17:41:53 -0400 Denys Dmytriyenko <[email protected]> wrote: > > On Tue, 19 Oct 2021 16:02:46 -0400 Denys Dmytriyenko <[email protected]> > > wrote: > > > > I've, like many, run into the issue of toolchain detection for the > > > > ti-sgx-ddk-km driver. I've noticed the ugly patch [1] getting edited to > > > > add new toolchains like arm-oe-linux-gnueabi and arm-poky-linux-gnueabi. > > > > > > > > This is cumbersome because this step needs to be repeated for arbitrary > > > > toolchain vendors, and it is error-prone since the toolchain added > > > > doesn't > > > > explicitly mention the hardfp suffix expected by the driver, whereas > > > > arm-*-gnueabihf is already matched. > > > > > > > > My point is that I believe the proper fix for this is to make sure the > > > > toolchain generated by OpenEmbedded gets suffixed with "hf" when the > > > > hardfp > > > > tune is enabled, so that this ugly patch can be dropped and toolchain > > > > detection can work as expected. > > > > > > > > So far I've seen that the proper way to do this would be to set > > > > ABIEXTENSION > > > > .= "hf" accordingly given the arch tune. The only problem I've > > > > encountered > > > > so far is that the cross-canadian thingy [2] is zeroing the related > > > > variables > > > > for some reasons. Hence I'm not sure how to configure this properly. > > > > > > > > [1] > > > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/powervr-drivers/ti-sgx-ddk-km/0001-km-support-OpenEmbedded-hardfp-toolchain-w-o-gnueabi.patch > > > > > > > > [2] > > > > http://cgit.openembedded.org/openembedded-core/tree/meta/classes/cross-canadian.bbclass#n64 > > > > > > > > Cc'ing Richard in case he has an input on the ugly ABI extension > > > > zeroing. > > > > > > I'm seeing some level of negativity in this email - everything is ugly. > > > At > > > least it's not personal, which is good. But asking for help with an > > > attack > > > may not be very wise. Just saying... :) > > > > The comment in cross-canadian.bbclass literally states "This is a bit ugly." > > I'm only talking about code here and did not mean any attack. > > > > > Anyway, the reason for that SGX patch is to extend its internal toolchain > > > check with 2 supported exceptions - OE-Core and Poky, which have -gnueabi > > > suffix, but in reality are -gnueabihf toolchains. I'm not aware of any > > > other > > > *upstream* toolchain vendor with the same predicament. And the check > > > should > > > not be generic, as there are valid non-hardfp toolchains out there. This > > > is > > > a known "feature" of the OE-built toolchains and as meta-ti is downstream > > > from OE-Core, it has to adapt, whether it's ugly or not. > > > > My point exactly, we shouldn't be adding non-hf toolchains in the detection > > because this is error prone, they may not support hardfp, we should try to > > fix the hardfp toolchain names instead. > > Sure, try convincing upstream OE maintainers and the Community at large.
Now I'm seeing some level of negativity :-) > > > Now, the reasons behind this "irregularity" of OE-built toolchains have > > > been discussed many times in the past. I'm sure Khem and Richard can go > > > into more details, if they are so inclined. From my perspective, one of > > > the major reasons was that OE has been building and distributing > > > toolchains > > > way before other vendors started using "hf" extension in the OS/ABI field > > > of the target triplet. And OE tends to be very conservative when it comes > > > to making major changes that break compatibility with past releases... > > > > And this is not just OE-Core or Poky toolchains, but anyone setting a custom > > vendor for some reason has to carry such patch, like seen here: > > > > https://e2e.ti.com/support/processors-group/processors/f/processors-forum/881393/dra726-strange-build-error-for-ti-sgx-ddk-km/3259903#3259903 > > I completely understand the trouble, but as mentioned above, those are not > *upstream* toolchain vendors relative to meta-ti, unlike OE-Core and to some > extent Poky. > > Each OE distro tends to customize TARGET_VENDOR. Unfortunately, that ends up > in the toolchain name, even though toolchains between distros are not that > different. Linaro, Arm, Debian, Ubuntu chose not to do that and used "-none" > or just nothing at all in their toolchain vendor field. I also chose not to > customize it for Arago distro, using the default "-oe" vendor name, hence > its *internal* toolchain is still called arm-oe-linux-gnueabi, instead of > arm-arago-linux-gnueabi... > > Overall, I don't see this matter as SGX-specific, or even meta-ti specific. > This could be a more *generic* upstream toolchain topic, if you wish to take > it there. That's the whole purpose of this thread, this is why I am pointing this sgx patch as an example for the consequences for zeroing the ABI extension, and why I Cc'ed Richard to bootstrap the discussion about this. So far the fix seems "as simple as" setting ABIEXTENSION .= "hf" if TARGET_FPU is "hard", but this hits the cross-canadian.bbclass code clearing it. Thus I'm raising the discussion about finding an alternative way. Thanks, Vivien
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14061): https://lists.yoctoproject.org/g/meta-ti/message/14061 Mute This Topic: https://lists.yoctoproject.org/mt/86447553/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
