On Sun, 24 Jun 2018 at 18:37, Waldemar Brodkorb wbx@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