diff mbox

[v2,3/3] Consolidate posix_fadvise implementations

Message ID 3faeab56-ea0f-1fb1-68cd-f260162b18ab@linaro.org
State New
Headers show

Commit Message

Adhemerval Zanella Oct. 12, 2016, 4:04 p.m. UTC 
On 12/10/2016 12:39, Joseph Myers wrote:
> On Wed, 12 Oct 2016, Adhemerval Zanella wrote:

> 

>> For some reason I am not seeing this issue with my mips64n64 toolchain

>> (gcc 5.3.1, binutils 2.26.0.20160331).

> 

> I was using GCC 5.4.1 20160810 and binutils 2.27.51.20160810.  I've now 

> updated to today's GCC 5 branch and binutils master, and still see the 

> same issue, in a clean build from scratch.


I updated the binutils in my mips64 toolchain to master (2.27.51.20161012)
and now I am see this behaviour.

> 

> The error is complaining about libc.so when linking sotruss-lib.so.  

> libc.so has (readelf --dyn-syms)

> 

>    262: 000000000010b950    28 FUNC    GLOBAL DEFAULT   12 posix_fadvise64@GLIBC_2.2

>    417: 000000000010b950    28 FUNC    WEAK   DEFAULT   12 posix_fadvise64@@GLIBC_2.2

>   1505: 000000000010b950    28 FUNC    GLOBAL DEFAULT   12 posix_fadvise64@@GLIBC_2.3.3

> 

> that is, two separate definitions at version GLIBC_2.2.  It looks to me 

> like sysdeps/unix/sysv/linux/posix_fadvise64.c would create a 

> posix_fadvise64 weak_alias, while 

> sysdeps/unix/sysv/linux/mips/mips64/n64/posix_fadvise64.c then adds 

> compat_symbol / versioned_symbol calls.  If a symbol is being created with 

> explicit versioning, direct weak_alias / strong_alias calls for it should 

> be disabled.


Yes, it seems the case.  The patch below disable the weak_alias for mips64
and I could complete the build without issues with check-abi clean.

By the way, do you know exactly why mips64n64 requires this symbol versioning?
I noted MIPS64 sets __OFF_T_MATCHES_OFF64_T and it is ILP64 (so size_t is
8 bytes), so 

--

Comments

Adhemerval Zanella Oct. 12, 2016, 4:14 p.m. UTC | #1 
On 12/10/2016 13:10, Joseph Myers wrote:
> On Wed, 12 Oct 2016, Adhemerval Zanella wrote:

> 

>> By the way, do you know exactly why mips64n64 requires this symbol versioning?

> 

> See what I said in 

> <https://sourceware.org/ml/libc-ports/2012-05/msg00006.html>.  Because 

> there were releases with both symbol versions, we need to keep the exports 

> at both versions even though they have the same semantics.

> 

> Please commit the patch.

> 


Thanks, I will add a comment on mips64 posix_fadvise64 implementation
explaining why it is required.
diff mbox

Patch

diff --git a/sysdeps/unix/sysv/linux/mips/mips64/n64/posix_fadvise64.c b/sysdeps/unix/sysv/linux/mips/mips64/n64/posix_fadvise64.c
index d7aab25..0af3c38 100644
--- a/sysdeps/unix/sysv/linux/mips/mips64/n64/posix_fadvise64.c
+++ b/sysdeps/unix/sysv/linux/mips/mips64/n64/posix_fadvise64.c
@@ -15,6 +15,8 @@ 
    License along with the GNU C Library; if not, see
    <http://www.gnu.org/licenses/>.  */
 
+#undef weak_alias
+#define weak_alias(a, b)
 #undef strong_alias
 #define strong_alias(a, b)