(ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

(ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

s_j_newbury (Bugzilla)
I've just tried to upgrade my EABI/NPTL kernel headers to the new exported
2.6.18 headers and rebuilt Glibc.  I am using a very recent Gentoo userspace
with a few local changes.

I had to update my ports snapshot to a more recent version (tried 20061120 and
20061127) from 20060925 (as included in Gentoo glibc-2.5) otherwise the
required headers aren't available to build glibc.  It built OK, but resulted in
a non-working system.  Specifically rm won't remove files, tar complains about
no utime, cp also doesn't work when setting up udev.  Most things do seem to be
working OK, though.

Building glibc-20061127 results in the exact same failure.

I am using a slightly modified kernel-2.6.19-rc4-mm2 (changes are mostly just
my local Zaurus/PXA27x patches).


Steve

Send instant messages to your online friends http://uk.messenger.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

Daniel Jacobowitz-2
On Sat, Dec 02, 2006 at 04:19:48PM +0000, Steven Newbury wrote:

> I've just tried to upgrade my EABI/NPTL kernel headers to the new exported
> 2.6.18 headers and rebuilt Glibc.  I am using a very recent Gentoo userspace
> with a few local changes.
>
> I had to update my ports snapshot to a more recent version (tried 20061120 and
> 20061127) from 20060925 (as included in Gentoo glibc-2.5) otherwise the
> required headers aren't available to build glibc.  It built OK, but resulted in
> a non-working system.  Specifically rm won't remove files, tar complains about
> no utime, cp also doesn't work when setting up udev.  Most things do seem to be
> working OK, though.

Building glibc correctly is hard.  I'd need much more information to
see what's gone wrong.  You'd need to isolate some system call that was
being made incorrectly.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

s_j_newbury (Bugzilla)

--- Daniel Jacobowitz <[hidden email]> wrote:

> On Sat, Dec 02, 2006 at 04:19:48PM +0000, Steven Newbury wrote:
> > I've just tried to upgrade my EABI/NPTL kernel headers to the new exported
> > 2.6.18 headers and rebuilt Glibc.  I am using a very recent Gentoo
> userspace
> > with a few local changes.
> >
> > I had to update my ports snapshot to a more recent version (tried 20061120
> and
> > 20061127) from 20060925 (as included in Gentoo glibc-2.5) otherwise the
> > required headers aren't available to build glibc.  It built OK, but
> resulted in
> > a non-working system.  Specifically rm won't remove files, tar complains
> about
> > no utime, cp also doesn't work when setting up udev.  Most things do seem
> to be
> > working OK, though.
>
> Building glibc correctly is hard.  I'd need much more information to
> see what's gone wrong.  You'd need to isolate some system call that was
> being made incorrectly.

OK.  Attached is the output of strace -f rm <file> of both the previous
glibc+ports20060925 compiled with 2.6.17 headers (I think) and
glibc+ports20061127 compiled with 2.6.18 sanitised headers.  The prior works,
the latter doesn't.

gcc -v output:
Using built-in specs.
Target: arm-iwmmxt-linux-gnueabi
Configured with:
/home/tmp/portage/sys-devel/gcc-4.1.1-r1/work/gcc-4.1.1/configure --prefix=/usr
--bindir=/usr/arm-iwmmxt-linux-gnueabi/gcc-bin/4.1.1
--includedir=/usr/lib/gcc/arm-iwmmxt-linux-gnueabi/4.1.1/include
--datadir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.1
--mandir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.1/man
--infodir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.1/info
--with-gxx-include-dir=/usr/lib/gcc/arm-iwmmxt-linux-gnueabi/4.1.1/include/g++-v4
--host=arm-iwmmxt-linux-gnueabi --build=arm-iwmmxt-linux-gnueabi
--disable-altivec --enable-nls --without-included-gettext --with-system-zlib
--disable-checking --disable-werror --disable-libunwind-exceptions
--disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj
--with-arch=iwmmxt --with-cpu=iwmmxt --enable-languages=c,c++ --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.1 (Gentoo 4.1.1-r1)

rm from coreutils: (GNU coreutils) 6.4

kernel is EABI _only_, OABI support is disabled.

>
> --
> Daniel Jacobowitz
> CodeSourcery
>


Steve

Send instant messages to your online friends http://uk.messenger.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

s_j_newbury (Bugzilla)
Sorry, I forgot the attachments!  Here they are.

--- Steven Newbury <[hidden email]> wrote:

>
> --- Daniel Jacobowitz <[hidden email]> wrote:
>
> > On Sat, Dec 02, 2006 at 04:19:48PM +0000, Steven Newbury wrote:
> > > I've just tried to upgrade my EABI/NPTL kernel headers to the new
> exported
> > > 2.6.18 headers and rebuilt Glibc.  I am using a very recent Gentoo
> > userspace
> > > with a few local changes.
> > >
> > > I had to update my ports snapshot to a more recent version (tried
> 20061120
> > and
> > > 20061127) from 20060925 (as included in Gentoo glibc-2.5) otherwise the
> > > required headers aren't available to build glibc.  It built OK, but
> > resulted in
> > > a non-working system.  Specifically rm won't remove files, tar complains
> > about
> > > no utime, cp also doesn't work when setting up udev.  Most things do seem
> > to be
> > > working OK, though.
> >
> > Building glibc correctly is hard.  I'd need much more information to
> > see what's gone wrong.  You'd need to isolate some system call that was
> > being made incorrectly.
>
> OK.  Attached is the output of strace -f rm <file> of both the previous
> glibc+ports20060925 compiled with 2.6.17 headers (I think) and
> glibc+ports20061127 compiled with 2.6.18 sanitised headers.  The prior works,
> the latter doesn't.
>
> gcc -v output:
> Using built-in specs.
> Target: arm-iwmmxt-linux-gnueabi
> Configured with:
> /home/tmp/portage/sys-devel/gcc-4.1.1-r1/work/gcc-4.1.1/configure
> --prefix=/usr
> --bindir=/usr/arm-iwmmxt-linux-gnueabi/gcc-bin/4.1.1
> --includedir=/usr/lib/gcc/arm-iwmmxt-linux-gnueabi/4.1.1/include
> --datadir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.1
> --mandir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.1/man
> --infodir=/usr/share/gcc-data/arm-iwmmxt-linux-gnueabi/4.1.1/info
>
--with-gxx-include-dir=/usr/lib/gcc/arm-iwmmxt-linux-gnueabi/4.1.1/include/g++-v4

> --host=arm-iwmmxt-linux-gnueabi --build=arm-iwmmxt-linux-gnueabi
> --disable-altivec --enable-nls --without-included-gettext --with-system-zlib
> --disable-checking --disable-werror --disable-libunwind-exceptions
> --disable-multilib --disable-libmudflap --disable-libssp --disable-libgcj
> --with-arch=iwmmxt --with-cpu=iwmmxt --enable-languages=c,c++ --enable-shared
> --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
> Thread model: posix
> gcc version 4.1.1 (Gentoo 4.1.1-r1)
>
> rm from coreutils: (GNU coreutils) 6.4
>
> kernel is EABI _only_, OABI support is disabled.
>
> >
> > --
> > Daniel Jacobowitz
> > CodeSourcery
> >
>
>
> Steve
>
> Send instant messages to your online friends http://uk.messenger.yahoo.com 
>

Steve

Send instant messages to your online friends http://uk.messenger.yahoo.com 

rm-strace.20060925 (2K) Download Attachment
rm-strace.20061127 (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

Daniel Jacobowitz-2
In reply to this post by s_j_newbury (Bugzilla)
On Sun, Dec 03, 2006 at 12:35:52AM +0000, Steven Newbury wrote:
> OK.  Attached is the output of strace -f rm <file> of both the previous
> glibc+ports20060925 compiled with 2.6.17 headers (I think) and
> glibc+ports20061127 compiled with 2.6.18 sanitised headers.  The prior works,
> the latter doesn't.

I have no idea how you've provoked this behavior but you didn't even
get it to call lstat; I think you'll need to debug into that call to
find out what's gone wrong.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

Carlos O'Donell-2
In reply to this post by s_j_newbury (Bugzilla)
On 12/2/06, Steven Newbury <[hidden email]> wrote:
> Sorry, I forgot the attachments!  Here they are.

How did you configure glibc? Not all combinations of --enable-kernel
neccessarily work correctly. There are untested combinations of
__ASSUME_* that just don't work.

I will posit that this is in some way due to __ASSUME_ATFCTS, and the
fact that coreutils 6.4 uses unlinkat.

c.
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

s_j_newbury (Bugzilla)

--- Carlos O'Donell <[hidden email]> wrote:

> On 12/2/06, Steven Newbury <[hidden email]> wrote:
> > Sorry, I forgot the attachments!  Here they are.
>
> How did you configure glibc? Not all combinations of --enable-kernel
> neccessarily work correctly. There are untested combinations of
> __ASSUME_* that just don't work.
=2.6.18
>
> I will posit that this is in some way due to __ASSUME_ATFCTS, and the
> fact that coreutils 6.4 uses unlinkat.
That makes perfect sense why it isn't working given that unlinkat is an empty
function.

What is the correct fix?
>
> c.
>


Steve

Send instant messages to your online friends http://uk.messenger.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

Carlos O'Donell-2
On 12/3/06, Steven Newbury <[hidden email]> wrote:
> What is the correct fix?

For your target arch figure out which kernel version is required to
enable __ASSUME_ATFCTS, and then build with atleast that version in
--enable-kernel.
This is all just speculation, you'll have to verify this yourself.

c.
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

s_j_newbury (Bugzilla)

--- Carlos O'Donell <[hidden email]> wrote:

> On 12/3/06, Steven Newbury <[hidden email]> wrote:
> > What is the correct fix?
>
> For your target arch figure out which kernel version is required to
> enable __ASSUME_ATFCTS, and then build with atleast that version in
> --enable-kernel.
> This is all just speculation, you'll have to verify this yourself.

I've been looking in sysdeps/unix/sysv/linux and
ports/sysdeps/unix/sysv/linux/arm.  The __ASSUME_ATFCTS define is only in the
core glibc kernel-features.h not in the ARM ports addon version.  Should I just
update ports/.../arm/kernel-features.h?  There's no reason to assume these
syscalls haven't been implemented for ARM is there?

I can't get into my kernel sources at the momemnt, my development server is
down... :-(


Steve


       
       
               
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

Daniel Jacobowitz-2
On Sun, Dec 03, 2006 at 09:35:11PM +0000, Steven Newbury wrote:
> I've been looking in sysdeps/unix/sysv/linux and
> ports/sysdeps/unix/sysv/linux/arm.  The __ASSUME_ATFCTS define is only in the
> core glibc kernel-features.h not in the ARM ports addon version.  Should I just
> update ports/.../arm/kernel-features.h?  There's no reason to assume these
> syscalls haven't been implemented for ARM is there?

The common version is used for all platforms in addition to the arm
specific one.  I assume the syscalls are missing for ARM, or at least
for your kernel headers, and that assuming them is incorrect.

--
Daniel Jacobowitz
CodeSourcery
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

s_j_newbury (Bugzilla)

--- Daniel Jacobowitz <[hidden email]> wrote:

> On Sun, Dec 03, 2006 at 09:35:11PM +0000, Steven Newbury wrote:
> > I've been looking in sysdeps/unix/sysv/linux and
> > ports/sysdeps/unix/sysv/linux/arm.  The __ASSUME_ATFCTS define is only in
> the
> > core glibc kernel-features.h not in the ARM ports addon version.  Should I
> just
> > update ports/.../arm/kernel-features.h?  There's no reason to assume these
> > syscalls haven't been implemented for ARM is there?
>
> The common version is used for all platforms in addition to the arm
> specific one.  I assume the syscalls are missing for ARM, or at least
> for your kernel headers, and that assuming them is incorrect.
>
So the correct fix would be to implement the syscalls for ARM, and in the
meantime _not_ define __ASSUME_ATFCTS for ARM in 2.6.18 (2.6.18 is the first
kernel release with support for export of sanitised kernel headers for
userspace), right?


Steve

Send instant messages to your online friends http://uk.messenger.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

s_j_newbury (Bugzilla)

--- Steven Newbury <[hidden email]> wrote:

>
> --- Daniel Jacobowitz <[hidden email]> wrote:
>
> > On Sun, Dec 03, 2006 at 09:35:11PM +0000, Steven Newbury wrote:
> > > I've been looking in sysdeps/unix/sysv/linux and
> > > ports/sysdeps/unix/sysv/linux/arm.  The __ASSUME_ATFCTS define is only in
> > the
> > > core glibc kernel-features.h not in the ARM ports addon version.  Should
> I
> > just
> > > update ports/.../arm/kernel-features.h?  There's no reason to assume
> these
> > > syscalls haven't been implemented for ARM is there?
> >
> > The common version is used for all platforms in addition to the arm
> > specific one.  I assume the syscalls are missing for ARM, or at least
> > for your kernel headers, and that assuming them is incorrect.
> >
> So the correct fix would be to implement the syscalls for ARM, and in the
> meantime _not_ define __ASSUME_ATFCTS for ARM in 2.6.18 (2.6.18 is the first
> kernel release with support for export of sanitised kernel headers for
> userspace), right?
It looks like ARM just got overlooked when the syscalls were hooked up.  There
is nothing arch dependent which is why the generic kernel-features.h doesn't
make any exceptions.

I'll post an email to linux-arm-kernel to see if I can get the syscalls added
to ARM, just adding them myself would be a bit risky once if they end up with
differing numbers...

Steve

Send instant messages to your online friends http://uk.messenger.yahoo.com 
Reply | Threaded
Open this post in threaded view
|

Re: (ARM EABI) ports-20061127 + kernel-headers-2.6.18 == broken system

Daniel Jacobowitz-2
On Mon, Dec 04, 2006 at 02:08:13AM +0000, Steven Newbury wrote:
> I'll post an email to linux-arm-kernel to see if I can get the syscalls added
> to ARM, just adding them myself would be a bit risky once if they end up with
> differing numbers...

Good choice.  Meanwhile, we should #undef __ASSUME_ATFCTS for ARM,
until we know when it will be added.  Does that give you a working
libc?

--
Daniel Jacobowitz
CodeSourcery