This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 03/17] Add support for the RISC-V-specific ELF flags
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: Palmer Dabbelt <palmer at dabbelt dot com>, <nd at arm dot com>, <libc-alpha at sourceware dot org>, Andrew Waterman <andrew at sifive dot com>, Darius Rad <darius at bluespec dot com>, <dj at redhat dot com>, <patches at groups dot riscv dot org>, Steve Ellcey <sellcey at cavium dot com>
- Date: Fri, 26 Jan 2018 18:00:23 +0000
- Subject: Re: [PATCH 03/17] Add support for the RISC-V-specific ELF flags
- Authentication-results: sourceware.org; auth=none
- References: <mhng-83cb62b8-04b9-402a-9a6e-8a6c4637fec1@palmer-si-x1c4> <15294291-e434-47e2-5464-9282d401fcba@arm.com>
On Fri, 26 Jan 2018, Szabolcs Nagy wrote:
> note that the FLAG_RISCV_FLOAT_ABI_SOFT ldconfig.h macro
> value conflicts with the arm/ilp32 branch, i can update this
> in the ilp32 branch but ldconfig will print existing ilp32
> ld.so.cache files incorrectly.
I don't think we expect ld.so.cache compatibility between different
releases, and certainly not between releases and versions not on master.
Indeed, that was the basis on which I reviewed the patch - because at the
time the patch series included RV32 support, so there were actually four
ABIs involved, and so if the Linux kernel gained support for running RV32
binaries on RV64 systems, four rather than two flag values would be needed
and there would be incompatibility in those values for whichever of RV32
and RV64 changed values.
(If RV32 support is added in future to glibc without the multi-ABI support
for ldconfig / ldd / ld.so.cache for RV32 binaries on RV64 systems, I'd
still consider it OK just to keep the two values. It's only at the point
where you add support for RV32 binaries on RV64 systems that it needs to
become four values, and as per the above, I'm assuming it's OK to change
the meaning of ld.so.cache values at that point.)
--
Joseph S. Myers
joseph@codesourcery.com