On Sun, 24 Jun 2018 at 18:37, Waldemar Brodkorb <w...@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
_______________________________________________
devel mailing list
devel@uclibc-ng.org
https://mailman.uclibc-ng.org/cgi-bin/mailman/listinfo/devel
