| Summary: | Find a way to check that the SFFS binaries have no VSX instructions. | ||
|---|---|---|---|
| Product: | Libre-SOC's first SoC | Reporter: | Sadoon Albader <sadoon> |
| Component: | Milestones | Assignee: | Sadoon Albader <sadoon> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | andy.miroshnikov, libre-soc-bugs, lkcl, programmerjake, toshaan |
| Priority: | --- | ||
| Version: | unspecified | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| NLnet milestone: | NLnet.2022-08-107.ongoing | total budget (EUR) for completion of task and all subtasks: | 2500 |
| budget (EUR) for this task, excluding subtasks' budget: | 2500 | parent task for budget allocation: | 999 |
| child tasks for budget allocation: | The table of payments (in EUR) for this task; TOML format: |
sadoon={amount=1700, submitted=2024-02-26, paid=2024-03-08}
lkcl = {amount=800, submitted=2024-02-26, paid=2024-03-08}
|
|
| Bug Depends on: | 999 | ||
| Bug Blocks: | |||
| Deadline: | 2023-10-31 | ||
| Attachments: | Incomplete list of AltiVec/VSX instructions | ||
|
Description
Sadoon Albader
2023-08-02 14:56:54 BST
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* 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)! |