On Tue, Oct 19, 2021 at 04:51:29PM -0400, Vivien Didelot wrote: > 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.
Sure, try convincing upstream OE maintainers and the Community at large. > > 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. -- Regards, Denys Dmytriyenko <[email protected]> PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964 Fingerprint: 25FC E4A5 8A72 2F69 1186 6D76 4209 0272 9A92 C964
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#14059): https://lists.yoctoproject.org/g/meta-ti/message/14059 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]] -=-=-=-=-=-=-=-=-=-=-=-
