We need a way to test whether binary object files contain any VSX instructions to make sure that the build flags from bug #1132 and bug #1131 are being applied by the build scripts. This is a rudimentary test to help not waste time trying to simulate / run code that is guaranteed to not work in an SFFS compliant environment.
or, run in userspace OR simply do "istruction trace logging" and check afterwards if any VSX instructios were included. OR, perform an "objdump" disassembly on all binaries and examine them to see if they have VSX. it is not *actually* necessary to execute the binaries at all: the actual task is "check if the binaries contain VSX instructions", where executing under qemu is just one way to achieve that task.
(In reply to Luke Kenneth Casson Leighton from comment #1) > OR, perform an "objdump" disassembly on all binaries and examine > them to see if they have VSX. I'll add that as a worst case scenario if patching qemu proves very difficult
(In reply to Sadoon Albader from comment #0) > and to fix whatever > oddities we find in software that does not respect CFLAGs and various build > toggles. this is an additional task for which it is perfectly reasonable to put in an additional (new) grant request. the reason why is becausewe have no idea yet the scale of the task. you could be letting yourself in for 24 months worth of patching work for only EUR 5,000.
(sadoon ihave edited ths comment to trim rxtraneous context. the reply comments are right above if anyne wants to see them. please be strict about this in bugreports, this server is not "unlimited resources" plus it wastes reader's valuable time) (In reply to Luke Kenneth Casson Leighton from comment #3) > this is an additional task for which it is perfectly reasonable to > put in an additional (new) grant request. the reason why is becausewe have > no idea yet the scale of the task. you could be letting yourself > in for 24 months worth of patching work for only EUR 5,000. Yes of course, that would be a separate task to fix all those oddities :) What I meant was that task 1128 would enable us to find those outliers so they can be fixed later.
(In reply to Sadoon Albader from comment #2) > (In reply to Luke Kenneth Casson Leighton from comment #1) > > > OR, perform an "objdump" disassembly on all binaries and examine > > them to see if they have VSX. > > I'll add that as a worst case scenario if patching qemu proves very difficult rather than do the difficult task first for which you will receive exactly the same amount of money can i suggest doing the easy task as a shell script with some "grep" commands in it then see if you feel like doing qemu after that? after all, if you *know* that the binaries have no VSX instuctions because the scripts informed you of this why the go to the trouble of executing them? also the scripts will find untested codepaths that simply running the binaries will not.
(In reply to Sadoon Albader from comment #4) > What I meant was that task 1128 would enable us to find those outliers so > they can be fixed later. ah it reads ambiguously, can you edit comment #0 so it is clearer? "...is proper. this allows a future task to fix..." or other words
(In reply to Luke Kenneth Casson Leighton from comment #5) > rather than do the difficult task first for which you will receive > exactly the same amount of money can i suggest doing the easy task > as a shell script with some "grep" commands in it then see if you > feel like doing qemu after that? > > after all, if you *know* that the binaries have no VSX instuctions > because the scripts informed you of this why the go to the trouble of > executing them? > > also the scripts will find untested codepaths that simply running > the binaries will not. Yes that sounds reasonable, thanks for the heads up!
Created attachment 198 [details] Incomplete list of AltiVec/VSX instructions This list is based on https://git.libre-soc.org/?p=binutils-gdb.git&a=search&h=85f4cf41a852b5983ca436615a019315f6dc7301&st=grep&s=PPCVEC%7CPPCVSX&sr=1 (Thanks Jacob!) we can use it to check our objdump'd binaries for any Vector instructions, example of default compiled hello.deb on Debian 12: fgrep -of insns.txt hello.asm | sort | uniq -c | awk '{print $2 " " $1}' lvx 1 lxvd2x 45 mfvrd 1 stvx 1 stxvd2x 49 vcmpequb 12 vgbbd 1 vsldoi 1 vspltisw 5 xxlorc 4 xxswapd 4 Example of our custom CFLAGS (see bug 999): fgrep -of insns.txt hello.final.asm | sort | uniq -c | awk '{print $2 " " $1}' *no output*
https://libre-soc.org/irclog/%23libre-soc.2023-08-04.log.html#t2023-08-04T16:58:04
Added sections in [debian_bootstrap](https://libre-soc.org/SFFS/debian_bootstrap) and [gentoo_bootstrap](https://libre-soc.org/SFFS/gentoo_boostrap) wiki pages for testing VSX instructions. Task is completed.
what was the summary of why qemu could not be built to emulate SFFS only? (notes for the basis of a future grant)
(In reply to Luke Kenneth Casson Leighton from comment #11) > what was the summary of why qemu could not be built to emulate SFFS > only? (notes for the basis of a future grant) I'll add a wiki page for that as well as attach a comment on bug #1132 as that is the bug for the QEMU task
Luke, please quit adding spaces after the date when there are no spaces around the `=`, it breaks budget-sync (because of a bug known in the toml package)!