Re: Add private syscalls to support NPTL

[Finn Thain]

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;
 }

[Maxim Kuvyrkov-2]

Finn Thain wrote:
> 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 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:

The patches posted are all against FSF GLIBC, not EGLIBC, so some
conflicts are expected.
...

> 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?

I don't really know, this is the first time I see this failure.

> 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?

The binary will certainly not work, but I remember run-time linker
gracefully exiting with a proper error message when invoked on a system
with unpatched kernel.  I don't think I tested statically linked
binaries on such system.

--
Maxim Kuvyrkov
CodeSourcery
maxim@...
[phone] x724


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Finn Thain]

On Fri, 6 Nov 2009, Maxim Kuvyrkov wrote:

> Finn Thain wrote:
> > 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 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:
>
> The patches posted are all against FSF GLIBC, not EGLIBC, so some
> conflicts are expected. ...

OK. I suppose that means no back-porting of other patches is required.

> > 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?
>
> I don't really know, this is the first time I see this failure.

I found out why it happens.

If you build eglibc with "--enable-kernel=2.6.31" it fails as above.
If you omit that option, it works.

Do you think my patch is a reasonable solution? I don't understand it, I
just copied it from x86 -- "monkey see, monkey do."

I used the eglibc-2.10/EGLIBC.cross-building script to test this. I
configured eglibc with "--enable-add-ons=ports,nptl" to prevent localedef
from breaking the configure step. Package versions were binutils-2.19.51,
gcc-4.4.1 (patched), linux-2.6.31 (patched), eglibc 2_10 branch (patched).

I also tried eglibc trunk but the build failed elsewhere:

../sysdeps/unix/sysv/linux/i386/fcntl.c: In function '__fcntl_nocancel':
../sysdeps/unix/sysv/linux/i386/fcntl.c:133: error: storage size of 'fex' isn't known
../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: 'F_GETOWN_EX' undeclared (first use in this function)
../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: (Each undeclared identifier is reported only once
../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: for each function it appears in.)
../sysdeps/unix/sysv/linux/i386/fcntl.c:136: error: 'F_OWNER_GID' undeclared (first use in this function)
../sysdeps/unix/sysv/linux/i386/fcntl.c:133: warning: unused variable 'fex'
make[2]: *** [/home/fthain/cross-build/m68k/obj/eglibc/io/fcntl.o] Error 1
make[2]: Leaving directory `/home/fthain/cross-build/src/eglibc-trunk-r9191/io'
make[1]: *** [io/subdir_lib] Error 2
make[1]: Leaving directory `/home/fthain/cross-build/src/eglibc-trunk-r9191'
make: *** [all] Error 2

For now I'm content with eglibc-2.10, since that is the version in the
debian archive.

>
> > 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?
>
> The binary will certainly not work,

Right. I see that this is documented in the CodeSourcery G++ Lite m68k
docs.

Finn

> but I remember run-time linker gracefully exiting with a proper error
> message when invoked on a system with unpatched kernel.  I don't think I
> tested statically linked binaries on such system.
>
>


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Brad Boyer]

On Tue, Nov 10, 2009 at 03:07:28PM +1100, Finn Thain wrote:

> I also tried eglibc trunk but the build failed elsewhere:
>
> ../sysdeps/unix/sysv/linux/i386/fcntl.c: In function '__fcntl_nocancel':
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:133: error: storage size of 'fex' isn't known
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: 'F_GETOWN_EX' undeclared (first use in this function)
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: (Each undeclared identifier is reported only once
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:134: error: for each function it appears in.)
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:136: error: 'F_OWNER_GID' undeclared (first use in this function)
> ../sysdeps/unix/sysv/linux/i386/fcntl.c:133: warning: unused variable 'fex'
> make[2]: *** [/home/fthain/cross-build/m68k/obj/eglibc/io/fcntl.o] Error 1
> make[2]: Leaving directory `/home/fthain/cross-build/src/eglibc-trunk-r9191/io'
> make[1]: *** [io/subdir_lib] Error 2
> make[1]: Leaving directory `/home/fthain/cross-build/src/eglibc-trunk-r9191'
> make: *** [all] Error 2
>
> For now I'm content with eglibc-2.10, since that is the version in the
> debian archive.

It looks like this needs a newer version of the kernel headers. That stuff
was added relatively recently:

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ba0a6c9f6fceed11c6a99e8326f0477fe383e6b5

If I'm reading the dates correctly, this commit wasn't in 2.6.31.

As a side note, there is already a patch floating around to fix that commit,
which apparently broke stuff.

http://patchwork.kernel.org/patch/56568/

        Brad Boyer
        flar@...


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Maxim Kuvyrkov-2]

Finn Thain wrote:

>
> On Fri, 6 Nov 2009, Maxim Kuvyrkov wrote:
>
>> Finn Thain wrote:
>>> 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 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:
>> The patches posted are all against FSF GLIBC, not EGLIBC, so some
>> conflicts are expected. ...
>
> OK. I suppose that means no back-porting of other patches is required.
>
>>> 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?
>> I don't really know, this is the first time I see this failure.
>
> I found out why it happens.
>
> If you build eglibc with "--enable-kernel=2.6.31" it fails as above.
> If you omit that option, it works.
>
> Do you think my patch is a reasonable solution? I don't understand it, I
> just copied it from x86 -- "monkey see, monkey do."

I can't spot anything wrong in it.

>
> I used the eglibc-2.10/EGLIBC.cross-building script to test this. I
> configured eglibc with "--enable-add-ons=ports,nptl" to prevent localedef
> from breaking the configure step. Package versions were binutils-2.19.51,
> gcc-4.4.1 (patched), linux-2.6.31 (patched), eglibc 2_10 branch (patched).

What hardware / emulator do you use to test the result?  I tested all
the work on ColdFire systems, but I also would like to run some tests on
a usual m68k.

Regards,

--
Maxim Kuvyrkov
CodeSourcery
maxim@...
[phone] x724


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Finn Thain]

On Tue, 10 Nov 2009, Maxim Kuvyrkov wrote:

> Finn Thain wrote:
>
> >
> > Do you think my patch is a reasonable solution? I don't understand it, I
> > just copied it from x86 -- "monkey see, monkey do."
>
> I can't spot anything wrong in it.

Thanks for looking it over. I'll send it upstream.

> >
> > I used the eglibc-2.10/EGLIBC.cross-building script to test this. I
> > configured eglibc with "--enable-add-ons=ports,nptl" to prevent
> > localedef from breaking the configure step. Package versions were
> > binutils-2.19.51, gcc-4.4.1 (patched), linux-2.6.31 (patched), eglibc
> > 2_10 branch (patched).
>
> What hardware / emulator do you use to test the result?  I tested all
> the work on ColdFire systems, but I also would like to run some tests on
> a usual m68k.

I've been testing on 68040 machines. I've not yet tried the test suites.

The latest random test I did was to build the cross toolchain using
patched debian sid source packages. Then I copied sshd and its supporting
libraries etc from an etch-m68k system into the toolchain sysroot, along
with a few old busybox bits and pieces that I had lying around. I then
exported the sysroot with NFS and booted that. After some messing around I
was able to log in with ssh and gather the info below.

So far, so good!

Finn


# cat /proc/cpuinfo
CPU:            68040
MMU:            68040
FPU:            68040
Clocking:       24.6MHz
BogoMips:       16.43
Calibration:    82176 loops
# cat /proc/version
Linux version 2.6.31.5-mac (fthain@nippy) (gcc version 4.4.1 (GCC) ) #2 Wed Nov 11 00:52:38 EST 2009
# /lib/libc.so.6
GNU C Library (EGLIBC) stable release version 2.10.1, by Roland McGrath et al.
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.4.1.
Compiled on a Linux >>2.6.31.5<< system on 2009-11-10.
Available extensions:
        crypt add-on version 2.1 by Michael Glad and others
        GNU Libidn by Simon Josefsson
        Native POSIX Threads Library by Ulrich Drepper et al
        Support for some architectures added on, not maintained in glibc core.
        BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.eglibc.org/issues/>.
# cat /proc/649/maps
80000000-80047000 r-xp 00000000 00:0c 84898      /etch-m68k-root/usr/sbin/sshd
80048000-80049000 rw-p 00046000 00:0c 84898      /etch-m68k-root/usr/sbin/sshd
80049000-8006f000 rwxp 00000000 00:00 0          [heap]
c0000000-c0018000 r-xp 00000000 00:0c 115132     /lib/ld-2.10.1.so
c0018000-c0019000 rw-p 00000000 00:00 0
c0019000-c001a000 r--p 00019000 00:0c 115132     /lib/ld-2.10.1.so
c001a000-c001b000 rw-p 0001a000 00:0c 115132     /lib/ld-2.10.1.so
c001b000-c0022000 r-xp 00000000 00:0c 442806     /usr/local/lib/libwrap.so.0.7.6
c0022000-c0023000 ---p 00007000 00:0c 442806     /usr/local/lib/libwrap.so.0.7.6
c0023000-c0024000 rw-p 00006000 00:0c 442806     /usr/local/lib/libwrap.so.0.7.6
c0024000-c0025000 rw-p 00000000 00:00 0
c0025000-c002c000 r-xp 00000000 00:0c 442808     /usr/local/lib/libpam.so.0.79
c002c000-c002d000 ---p 00007000 00:0c 442808     /usr/local/lib/libpam.so.0.79
c002d000-c002f000 rw-p 00006000 00:0c 442808     /usr/local/lib/libpam.so.0.79
c002f000-c0030000 rw-p 00000000 00:00 0
c0030000-c0032000 r-xp 00000000 00:0c 115080     /lib/libdl-2.10.1.so
c0032000-c0033000 ---p 00002000 00:0c 115080     /lib/libdl-2.10.1.so
c0033000-c0034000 r--p 00001000 00:0c 115080     /lib/libdl-2.10.1.so
c0034000-c0035000 rw-p 00002000 00:0c 115080     /lib/libdl-2.10.1.so
c0035000-c0046000 r-xp 00000000 00:0c 442809     /usr/local/lib/libselinux.so.1
c0046000-c0047000 ---p 00011000 00:0c 442809     /usr/local/lib/libselinux.so.1
c0047000-c0048000 rw-p 00010000 00:0c 442809     /usr/local/lib/libselinux.so.1
c0048000-c0049000 rw-p 00000000 00:00 0
c0049000-c0058000 r-xp 00000000 00:0c 115096     /lib/libresolv-2.10.1.so
c0058000-c005a000 ---p 0000f000 00:0c 115096     /lib/libresolv-2.10.1.so
c005a000-c005b000 r--p 0000f000 00:0c 115096     /lib/libresolv-2.10.1.so
c005b000-c005c000 rw-p 00010000 00:0c 115096     /lib/libresolv-2.10.1.so
c005c000-c005e000 rw-p 00000000 00:00 0
c005e000-c016b000 r-xp 00000000 00:0c 442810     /usr/local/lib/libcrypto.so.0.9.8
c016b000-c016c000 ---p 0010d000 00:0c 442810     /usr/local/lib/libcrypto.so.0.9.8
c016c000-c0180000 rw-p 0010c000 00:0c 442810     /usr/local/lib/libcrypto.so.0.9.8
c0180000-c0184000 rw-p 00000000 00:00 0
c0184000-c0186000 r-xp 00000000 00:0c 115130     /lib/libutil-2.10.1.so
c0186000-c0187000 ---p 00002000 00:0c 115130     /lib/libutil-2.10.1.so
c0187000-c0188000 r--p 00001000 00:0c 115130     /lib/libutil-2.10.1.so
c0188000-c0189000 rw-p 00002000 00:0c 115130     /lib/libutil-2.10.1.so
c0189000-c019a000 r-xp 00000000 00:0c 442812     /usr/local/lib/libz.so.1.2.3
c019a000-c019b000 ---p 00011000 00:0c 442812     /usr/local/lib/libz.so.1.2.3
c019b000-c019c000 rw-p 00010000 00:0c 442812     /usr/local/lib/libz.so.1.2.3
c019c000-c019d000 rw-p 00000000 00:00 0
c019d000-c01af000 r-xp 00000000 00:0c 115120     /lib/libnsl-2.10.1.so
c01af000-c01b0000 ---p 00012000 00:0c 115120     /lib/libnsl-2.10.1.so
c01b0000-c01b1000 r--p 00011000 00:0c 115120     /lib/libnsl-2.10.1.so
c01b1000-c01b2000 rw-p 00012000 00:0c 115120     /lib/libnsl-2.10.1.so
c01b2000-c01b4000 rw-p 00000000 00:00 0
c01b4000-c01bd000 r-xp 00000000 00:0c 115088     /lib/libcrypt-2.10.1.so
c01bd000-c01bf000 ---p 00009000 00:0c 115088     /lib/libcrypt-2.10.1.so
c01bf000-c01c0000 r--p 00009000 00:0c 115088     /lib/libcrypt-2.10.1.so
c01c0000-c01c1000 rw-p 0000a000 00:0c 115088     /lib/libcrypt-2.10.1.so
c01c1000-c01e8000 rw-p 00000000 00:00 0
c01e8000-c01ff000 r-xp 00000000 00:0c 442814     /usr/local/lib/libgssapi_krb5.so.2.2
c01ff000-c0200000 ---p 00017000 00:0c 442814     /usr/local/lib/libgssapi_krb5.so.2.2
c0200000-c0201000 rw-p 00016000 00:0c 442814     /usr/local/lib/libgssapi_krb5.so.2.2
c0201000-c0269000 r-xp 00000000 00:0c 442816     /usr/local/lib/libkrb5.so.3.2
c0269000-c026a000 ---p 00068000 00:0c 442816     /usr/local/lib/libkrb5.so.3.2
c026a000-c026d000 rw-p 00067000 00:0c 442816     /usr/local/lib/libkrb5.so.3.2
c026d000-c028d000 r-xp 00000000 00:0c 442822     /usr/local/lib/libk5crypto.so.3.0
c028d000-c028e000 ---p 00020000 00:0c 442822     /usr/local/lib/libk5crypto.so.3.0
c028e000-c0290000 rw-p 0001f000 00:0c 442822     /usr/local/lib/libk5crypto.so.3.0
c0290000-c0292000 r-xp 00000000 00:0c 442818     /usr/local/lib/libcom_err.so.2.1
c0292000-c0293000 ---p 00002000 00:0c 442818     /usr/local/lib/libcom_err.so.2.1
c0293000-c0294000 rw-p 00001000 00:0c 442818     /usr/local/lib/libcom_err.so.2.1
c0294000-c0295000 rw-p 00000000 00:00 0
c0295000-c0298000 r-xp 00000000 00:0c 442820     /usr/local/lib/libkrb5support.so.0.0
c0298000-c0299000 ---p 00003000 00:0c 442820     /usr/local/lib/libkrb5support.so.0.0
c0299000-c029b000 rw-p 00002000 00:0c 442820     /usr/local/lib/libkrb5support.so.0.0
c029b000-c03b7000 r-xp 00000000 00:0c 114361     /lib/libc-2.10.1.so
c03b7000-c03b9000 r--p 0011c000 00:0c 114361     /lib/libc-2.10.1.so
c03b9000-c03bc000 rw-p 0011e000 00:0c 114361     /lib/libc-2.10.1.so
c03bc000-c03bf000 rw-p 00000000 00:00 0
c03bf000-c03f1000 r-xp 00000000 00:0c 442823     /usr/local/lib/libsepol.so.1
c03f1000-c03f2000 ---p 00032000 00:0c 442823     /usr/local/lib/libsepol.so.1
c03f2000-c03f4000 rw-p 00031000 00:0c 442823     /usr/local/lib/libsepol.so.1
c03f4000-c0401000 rw-p 00000000 00:00 0
c0401000-c0407000 r-xp 00000000 00:0c 115126     /lib/libnss_compat-2.10.1.so
c0407000-c0408000 ---p 00006000 00:0c 115126     /lib/libnss_compat-2.10.1.so
c0408000-c0409000 r--p 00005000 00:0c 115126     /lib/libnss_compat-2.10.1.so
c0409000-c040a000 rw-p 00006000 00:0c 115126     /lib/libnss_compat-2.10.1.so
c040a000-c0412000 r-xp 00000000 00:0c 115122     /lib/libnss_nis-2.10.1.so
c0412000-c0413000 ---p 00008000 00:0c 115122     /lib/libnss_nis-2.10.1.so
c0413000-c0414000 r--p 00007000 00:0c 115122     /lib/libnss_nis-2.10.1.so
c0414000-c0415000 rw-p 00008000 00:0c 115122     /lib/libnss_nis-2.10.1.so
c0415000-c041e000 r-xp 00000000 00:0c 115108     /lib/libnss_files-2.10.1.so
c041e000-c0420000 ---p 00009000 00:0c 115108     /lib/libnss_files-2.10.1.so
c0420000-c0421000 r--p 00009000 00:0c 115108     /lib/libnss_files-2.10.1.so
c0421000-c0422000 rw-p 0000a000 00:0c 115108     /lib/libnss_files-2.10.1.so
efcb7000-efccc000 rw-p 00000000 00:00 0          [stack]


--
To UNSUBSCRIBE, email to debian-68k-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...