Closed simpal01 closed 4 hours ago
Similar comment to #553: should we move the expansion of library variants inside the add_library_variants_for_cpu
function, like we do for exceptions/rtti,instead of adding more calls to it? That will probably make this patch a bit more complicated, as we'll need to pass both the QEMU and FVP parameters into the call and select the right one for each variant, but in the longer term we'll want big-endian and strict-align variants for (almost) every library variant, so it should simplify things in the end.
Similar comment to #553: should we move the expansion of library variants inside the
add_library_variants_for_cpu
function, like we do for exceptions/rtti,instead of adding more calls to it? That will probably make this patch a bit more complicated, as we'll need to pass both the QEMU and FVP parameters into the call and select the right one for each variant, but in the longer term we'll want big-endian and strict-align variants for (almost) every library variant, so it should simplify things in the end.
Yeah there is a plan to do this as a long term solution when you have more library variants work with big-endian and strict-align. As a starting point, we will start adding separately now.
This patch add new aarch64 big endian library variants.
QEMU's doesn't have big-endian support in the release binaries. so need to use FVPs to test those libraries.