Re: Add private syscalls to support NPTL
On Wed, 28 Oct 2009, Maxim Kuvyrkov wrote:
>...
>
> We [CodeSourcery] have just updated all of our toolchains, and the
> GNU/Linux toolchain is based on EGLIBC 2.10 and has well tested TLS/NPTL
> support. If you are targeting ColdFire you can simply download the
> toolchain at <http://www.codesourcery.com/sgpp/lite/coldfire>.
>
> > I suppose you can't really backport to eglibc 2.10 until the siginfo
> > question is resolved. It appears from the list traffic that the
> > consensus is to adopt the generic struct layout here. Is that the
> > solution that you've used in testing?
>
> I'm not sure if any parts of the m68k kernel port depend on the custom
> layout of siginfo, so I've only fixed the pieces which I'm sure are
> wrong. I.e, I've been testing with this
> <http://marc.info/?l=linux-m68k&m=125447365311948&w=2> patch.
>
> > If so, can you send the patches you been testing?
>
> All the patches are in the mailing lists.
>
> The kernel patches are at
>
> http://marc.info/?l=linux-m68k&m=125447760017098&w=2
For the benefit of anyone playing along at home, I found that the first
attachment ("patch.diff") is already merged in the second attachment
of the same message ("0001-Add-NPTL-support-for-m68k.patch").
> http://marc.info/?l=linux-m68k&m=125447365311948&w=2
>
> The [E]GLIBC patches are at
>
> [M68K/ColdFire patch 1/n] Update sysdep.h
> http://sourceware.org/ml/libc-ports/2009-08/msg00006.html
>
> [M68K/ColdFire patch 2/n] Add CFI information to dl-trampoline.S
> http://sourceware.org/ml/libc-ports/2009-08/msg00007.html
>
> [M68K/ColdFire patch 3/n] Update jmpbuf-unwind.h
> http://sourceware.org/ml/libc-ports/2009-08/msg00008.html
>
> [M68K/ColdFire patch 4/n] Remove kernel headers
> Update by hand to match your kernel
I suppose I don't need to remove or update anything, since I build eglibc
against fresh new kernel headers, from linux-2.6.31 patched with your TLS
patches.
> [M68K/ColdFire patch 5/n] Main NPTL patch
> http://sourceware.org/ml/libc-ports/2009-10/msg00006.html
For the benefit of anyone else attempting this, the first patch in that
email ("Don't bind rtld's vdso pointers to libc symbols") is merged into
the second patch in the same email ("Nptl support for m68k/ColdFire").
I did run into a problem with this second patch. It doesn't apply to the
eglibc_2.10 branch in svn as of yesterday. The following hunk is the
problem:
--- a/sysdeps/unix/sysv/linux/m68k/Versions
+++ b/sysdeps/unix/sysv/linux/m68k/Versions
@@ -31,5 +31,17 @@ libc {
}
GLIBC_2.11 {
fallocate64;
+ __m68k_read_tp;
+ }
+ GLIBC_PRIVATE {
+ __vdso_atomic_cmpxchg_32; __vdso_atomic_barrier;
+ }
+}
+
+ld {
+ GLIBC_PRIVATE {
+ __rtld___vdso_read_tp;
+ __rtld___vdso_atomic_cmpxchg_32;
+ __rtld___vdso_atomic_barrier;
}
}
It appears that another patch is needed, to allow your patch to apply:
http://sourceware.org/ml/libc-ports/2009-05/msg00028.html
And probably this patch too (I used both):
http://sourceware.org/ml/libc-hacker/2009-05/msg00003.html
Should I be using any other patches?
> http://sourceware.org/ml/libc-ports/2009-10/msg00030.html
>
> [M68K/ColdFire patch 6/n] Add TLS relocations to elf/elf.h
> http://sourceware.org/ml/libc-ports/2009-08/msg00012.html
(Trap for the uwary: this patch is for eglibc/libc, the others are for
eglibc/ports.)
> Should I post this one to glibc-alpha@ for the review?
>
> [M68K/ColdFire patch 7/n] Handle libgcc_s.so.2
> http://sourceware.org/bugzilla/show_bug.cgi?id=4457
The two patches attached to that bug are already in the eglibc_2.10
branch, BTW.
>
> Let me know if you find any particular problems with these patches.
>
Using the above patches, I am almost able to compile eglibc_2.10. But
there is an old build failure (since glibc-2.4 I think) when linking
libc.so:
/tmp/build/glibc-m68k-linux-gnu-3/libc_pic.os: In function `fchownat': (.text+0x911c2): undefined reference to `__atfct_seterrno'
/tmp/gcc-4.4.1/lib/gcc/m68k-linux-gnu/4.4.1/../../../../m68k-linux-gnu/bin/ld: /tmp/build/glibc-m68k-linux-gnu-3/libc.so: hidden symbol `__atfct_seterrno' isn't defined
/tmp/gcc-4.4.1/lib/gcc/m68k-linux-gnu/4.4.1/../../../../m68k-linux-gnu/bin/ld: final link failed: Nonrepresentable section on output
collect2: ld returned 1 exit status
make[1]: *** [/tmp/build/glibc-m68k-linux-gnu-3/libc.so] Error 1
make[1]: Leaving directory `/tmp/build/glibc-2.10.1'
make: *** [all] Error 2
To try to fix this issue, I've basically copied this patch:
http://sources.redhat.com/ml/libc-hacker/2006-08/msg00004.html
An m68k version is attached. Can someone have a look at it and tell
whether this is the correct fix or not?
The end result is that I now have a NPTL/TLS m68k toolchain
(binutils-2.19.51 and patched gcc-4.4.1). Thank you for making that
possible. I've not run the test suites yet, but so far it seems to work.
Only, I did find that a statically linked binary (pccardctl) built with
this toolchain segfaults ("unknown errorSegmentation fault") when run
under a linux-2.6.31 kernel that lacks your patches. Is this expected?
Etch-m68k seems to run fine with or without the kernel patches. I've CC'd
the debian-m68k list but I suppose they can't use any of this until both
the siginfo ABI is resolved and eglibc passes its tests on m68k
hardware.
Finn
--- glibc-2.5/ports/sysdeps/unix/sysv/linux/m68k/fchownat.c.orig 2007-09-18 00:25:39.000000000 +1000
+++ glibc-2.5/ports/sysdeps/unix/sysv/linux/m68k/fchownat.c 2007-09-18 00:38:21.000000000 +1000
@@ -40,6 +40,24 @@
int
fchownat (int fd, const char *file, uid_t owner, gid_t group, int flag)
{
+ int result;
+
+#ifdef __NR_fchownat
+# ifndef __ASSUME_ATFCTS
+ if (__have_atfcts >= 0)
+# endif
+ {
+ result = INLINE_SYSCALL (fchownat, 5, fd, file, owner, group, flag);
+# ifndef __ASSUME_ATFCTS
+ if (result == -1 && errno == ENOSYS)
+ __have_atfcts = -1;
+ else
+# endif
+ return result;
+ }
+#endif
+
+#ifndef __ASSUME_ATFCTS
if (flag & ~AT_SYMLINK_NOFOLLOW)
{
__set_errno (EINVAL);
@@ -66,18 +84,17 @@
file = buf;
}
- int result;
INTERNAL_SYSCALL_DECL (err);
-#if __ASSUME_32BITUIDS > 0
+# if __ASSUME_32BITUIDS > 0
if (flag & AT_SYMLINK_NOFOLLOW)
result = INTERNAL_SYSCALL (lchown32, err, 3, CHECK_STRING (file), owner,
group);
else
result = INTERNAL_SYSCALL (chown32, err, 3, CHECK_STRING (file), owner,
group);
-#else
-# ifdef __NR_chown32
+# else
+# ifdef __NR_chown32
if (__libc_missing_32bit_uids <= 0)
{
if (flag & AT_SYMLINK_NOFOLLOW)
@@ -94,7 +111,7 @@
__libc_missing_32bit_uids = 1;
}
-# endif /* __NR_chown32 */
+# endif /* __NR_chown32 */
if (((owner + 1) > (gid_t) ((__kernel_uid_t) -1U))
|| ((group + 1) > (gid_t) ((__kernel_gid_t) -1U)))
@@ -109,7 +126,7 @@
else
result = INTERNAL_SYSCALL (chown, err, 3, CHECK_STRING (file), owner,
group);
-#endif
+# endif
if (__builtin_expect (INTERNAL_SYSCALL_ERROR_P (result, err), 0))
{
@@ -117,6 +134,7 @@
__atfct_seterrno (INTERNAL_SYSCALL_ERRNO (result, err), fd, buf);
result = -1;
}
+#endif
return result;
}
Reply to: