Could the Debian ARM list/porters possibly comment upon this bug? Please could you keep buildd-tools-devel and the bug in the CC on any reply. Thanks.
It's not clear to me why this bug has suddenly appeared, and only on armel. There seem to be a few possibilities: 1) schroot is using personality(2) incorrectly, but this is only causing breakage on armel because only armel sets some of the high bits outside the range of PER_MASK 2) there's an armel-specific bug in the glibc personality wrapper and/or headers 3) there's an armel-specific bug in the kernel and/or its headers Presumably any armel-specific bug would be a failure to mask out the high bits with PER_MASK when passing back the return value of personality(2) to userspace. This is assuming that the user is not required to mask it out by hand, but if this is required, it's not a documented part of the interface. Many thanks, Roger On Mon, May 03, 2010 at 10:20:02PM +0100, Roger Leigh wrote: > On 03/05/2010 21:01, Riku Voipio wrote: >> Package: schroot >> Severity: serious >> Version: 1.4.2-1 >> >> schroot FTBFS's on armel due to: >> >> 1) test: test_personality::test_construction (F) line: 51 >> ../../../test/sbuild-personality.cc >> assertion failed >> - Expression: p1.get_name() == "linux" || p1.get_name() == "linux_32bit" || >> p1.get_name() == "linux32" >> >> A quick test on few machines seems to say that: >> >> personality(0xffffffff) returns 0xC00000 on armel. > > Looking at the linux include/linux/personality.h, maybe we need to use > PER_MASK to mask out the high bits. 0xC00000 would imply > > READ_IMPLIES_EXEC | ADDR_LIMIT_32BIT > > where 0xC00000 & PER_MASK = PER_LINUX > > However, the documentation does not mention the need for masking, and > the personality macro in the header implies that the high bits are not > part of the visible personality interface since since they are masked > out. > > Is it possible the glibc headers and/or syscall wrapper are buggy here, > or the armel-specific kernel code? Alternatively, is armel the only > system to set some of the high bits and this is the first time we've > tripped up on this? > > I'll check the glibc header next. Some input from a kernel person would > help here, given the rather sparse documentation! -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
