Hi Denys, 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. > 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 Thanks, Vivien
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14056): https://lists.yoctoproject.org/g/meta-ti/message/14056 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]] -=-=-=-=-=-=-=-=-=-=-=-
