Comments (4)
The profiles expand to individual extensions that will be represented by existing machinery in psABI (i.e. ELF headers and tags) to identify the required extensions. Consequently, we don't need any special support for RISC-V profiles: the compatibility determination remains the current subset-relationship (i.e. a binary that requires a subset of the available functionality is compatible with a machine).
Having an orthogonal mechanism in the ABI would be more error-prone (and thus not advisable) as the various software layers would then have to match up between the profiles and individual extension specification: any ELF file that requires a subset of functionality guaranteed by a profile will need to be accepted as "compatible" ... if we have profiles as a separate concept, we would still need to look at the individual extensions in a secondary compatibility relationship.
from riscv-elf-psabi-doc.
The idea was mentioned in yesterday's RISC-V GNU community call.
The intention is the following: using an orthogonal mechanism for the compatibility check that requires just testing for a bit will be much faster than parsing the complete march string and doing the compatibility check based on extension-subset-matching at run-time.
from riscv-elf-psabi-doc.
The compatibility check only occurs when loading an ELF file.
The process of installing the ELF as an executable certainly makes the subset-matching look cheap in comparison.
That said, we will forever have issues around ELF files that require only a subset of the function provided by a profile (e.g., someone decides to compile their library just for "rv64gc" to have a single tested binary)... or, where a toolchain is smart enough to mark a dependency on the needed extensions only instead of "everything in the profile".
Next problem will be upgrading from RVA22 to RVA24: this will just create convoluted compatibility check logic (e.g. is "RVA22 + vectors" compatible with RVA24) in the long term.
from riscv-elf-psabi-doc.
Having a profile tag might not helpful to checking the binary is OK for platform or host, and I have similar concern as @ptomsich, give 2 more concrete example to show what could be happened:
we have a binary is rva24-compatible, and rva24 is including everything with rva22, AND plus A ext., B ext. which not existed in rva22.
So could we say that binary is compatible with rva22? I think yes - because the binary having every mandatory extensions required by rva22. but does it able to safe to run on any rva22 compatible platform? - No, because that might missing A ext. and B ext. support.
And the situation will happened even within single profile - we have a binary built with rva22 plus a vendor Xfoo., could we said it's rva22 compatible binary? Yes - because it satisfied every requirement of rva22.
Does it able to safe to run on any rva22 compatible platform? - No, because not every rva22 compatible platform implement Xfoo.
IMO everything should just using arch info is enough.
from riscv-elf-psabi-doc.
Related Issues (20)
- Mandatory/optional merging of build attributes HOT 5
- Collect psABI requirements for next release
- Alignment of __int128 on ILP32 HOT 7
- Question on calculation for HI20 HOT 2
- Question on calculation for HI20 HOT 1
- Clarification of rules for flattening structs containing arrays of empty records HOT 3
- Specify relocation overflow checks HOT 1
- Specify a platform reserved register HOT 20
- Should calling convention also define ptrdiff_t? HOT 1
- Should we use lw/sw in push pop when we used ILP32, whether it's RV32 or RV64 HOT 3
- Operation semantics of __bf16 datatype HOT 2
- representation of GNU C fixed-size vectors HOT 4
- Deprecate R_RISCV_RVC_LUI? HOT 4
- Define GOT-Relative data relocation HOT 8
- Embedding R_RISCV_RELAX to another relocations HOT 7
- Define gp(x3) as global VLENB HOT 4
- Bitfield integer calling convention garbled
- Calling convention uses RV64GQ without definition or reference HOT 3
- Calling convention description of va_list et al. are unclear HOT 2
- Interpretation of floating-point types
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from riscv-elf-psabi-doc.