On Sun, 24 Jun 2018 at 18:37, Waldemar Brodkorb <wbx(a)uclibc-ng.org> wrote:
Hi Christophe,
Christophe Lyon wrote,
Hi,
While working on FDPIC support for ARM in uclibc-ng, I've noticed that
the write() function if defined as a strong global symbol, while the
__GI_write alias is weak.
00000034 w F .text 0000005c .hidden __GI_write
00000034 g F .text 0000005c write
my pre-processed write.i contains:
ssize_t __attribute__ ((weak)) write (int fd, const void *buf, size_t
count) { int oldtype; ssize_t result; if (__builtin_expect
(__libc_multiple_threads == 0, 1)) return __write_nocancel (fd, buf,
count); oldtype = __libc_enable_asynccancel (); result =
__write_nocancel (fd, buf, count); __libc_disable_asynccancel
(oldtype); return result; }
extern __typeof (write) __EI_write __asm__("" "write"); extern
__typeof (write) __EI_write __attribute__((alias (""
"__GI_write")));
and write.s has:
.weak __GI_write
.hidden __GI_write
.type __GI_write, %function
__GI_write:
.fnstart
[...]
.size __GI_write, .-__GI_write
.global write
.set write,__GI_write
From the .i file, I'd expect the weak attribute to be set on write.
FWIW, I'd like write to be weak, because currently it prevents
re-defining it user code and linking statically with libc.a
I've checked that glibc and newlib have weak write.
Since this seems to depend on the threads model, my .config has:
# HAS_NO_THREADS is not set
UCLIBC_HAS_LINUXTHREADS=y
UCLIBC_HAS_THREADS_NATIVE=y
UCLIBC_HAS_THREADS=y
PTHREADS_DEBUG_SUPPORT=y
and having
# UCLIBC_HAS_LINUXTHREADS is not set
has no effect on write's weakness.
What am I missing?
May be it is just not implemented as weak in uClibc-ng/uClibc.
It was weak in our
uClibc port.
I'm trying to understand it is no longer the case now that I rebased
the patches on top of uClibc-ng: is it a problem with uClib-ng or a
mistake of mine?
Is the ARM FDPIC port targeting Linuxthreads or NPTL?
All existing FDPIC targets (Blackfin/FR-V) are using Linuxthreads.
We use NTPL:
> UCLIBC_HAS_THREADS_NATIVE=y
Is it a strict requirement for your test code to
overwrite write()?
That's part of a testsuite. I'm trying to understand
where the problem
is, in case it hides a major problem somewhere.
Maybe we could first import your port and test static
and shared
support and then trying to get write and may be other required
functions to be weak.
Sure. I thought it would be better to have a clean patch
series from
the beginning (well at least as clean as possible)
What does musl in this case?
I don't know.
Do you know if write (and friends) is weak on other ports of uClibc-ng?
Thanks,
Christophe
best regards
Waldemar