[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr
From: |
fweimer at redhat dot com |
Subject: |
[Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr |
Date: |
Sat, 26 Nov 2016 16:36:34 +0000 |
https://sourceware.org/bugzilla/show_bug.cgi?id=20852
--- Comment #6 from Florian Weimer <fweimer at redhat dot com> ---
(In reply to ambrosehua from comment #5)
> But I wonder if glibc defining __GI_strlen is legal for making a strlen
> unavailalble to be interposed in strfry. Is libc.so a special case for symbol
> interposition?
We only make malloc-related symbols available for interposition. For things
like strlen which are in all standards, it would not make a functional
difference because we could simply say you are not allowed to redefine them.
But for “open”, which is in POSIX but not ISO C, an application must be able to
define a function called “open” and still call “fopen”, with the behavior
required by ISO C. If the application definition of “open” was interposed into
glibc, then this would not work.
--
You are receiving this mail because:
You are on the CC list for the bug.
- [Bug ld/20852] New: glibc/MIPS strfry call strlen by bal not jalr, ambrosehua at 126 dot com, 2016/11/22
- [Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr, ambrosehua at 126 dot com, 2016/11/22
- [Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr, fweimer at redhat dot com, 2016/11/22
- [Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr, ambrosehua at 126 dot com, 2016/11/23
- [Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr, ambrosehua at 126 dot com, 2016/11/23
- [Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr, ma.jiang at zte dot com.cn, 2016/11/23
- [Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr, ambrosehua at 126 dot com, 2016/11/26
- [Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr,
fweimer at redhat dot com <=