cvs commit: src Makefile.inc1 src/gnu/lib Makefile src/gnu/lib/csu Makefile src/gnu/lib/libssp Makefile src/lib/csu Makefile.inc src/lib/libc Makefile src/lib/libstand Makefile src/lib/libthr Makefile src/libexec/rtld-elf Makefile src/release Makefile ...

[Bernd Walter]

On Thu, Jul 17, 2008 at 04:09:05PM +0200, Bernd Walter wrote:
> On Wed, Jul 16, 2008 at 12:54:46AM +0200, Bernd Walter wrote:
> > On Wed, Jul 16, 2008 at 02:13:22AM +0400, Stanislav Sedov wrote:
> > > On Tue, 15 Jul 2008 23:05:14 +0200
> > > Bernd Walter <ticso at cicely7.cicely.de> mentioned:
> > > 
> > > > On Mon, Jul 14, 2008 at 11:48:09PM +0400, Stanislav Sedov wrote:
> > > > > On Fri, 11 Jul 2008 23:19:09 +0200
> > > > > Jeremie Le Hen <jeremie at le-hen.org> mentioned:
> > > > > 
> > > > > > Would you mind testing it with WITHOUT_SSP= at the top of lib/libc/Makefile?
> > > > > > 
> > > > > 
> > > > > I'll try tomorrow. Currently, I have no access to the board.
> > > > 
> > > > Is it this kind of problem:
> > > > ipfw2 (+ipv6) initialized, divert enabled, nat enabled, rule-based forwarding enabled, default to accept, logging unlimited
> > > > SD CARD: 1023934464 bytes
> > > > mmcsd0: <mmc or sd flash card> on mmc0
> > > > mmc0: setting transfer rate to 30.000MHz
> > > > Trying to mount root from ufs:/dev/mmcsd0s1a
> > > > pid 20 (sh), uid 0: exited on signal 11
> > > > Jul 15 23:01:14 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode
> > > > Enter full pathname of shell or RETURN for /bin/sh: 
> > > > 
> > > > This happens for me with recent kernel and few days old 7-stable
> > > > userland, so it shouldn't have anything to do with installed libc.
> > > > 
> > > 
> > > Seems to be the same problem. However, it seems that just using libc
> > > compiled w/out SSP solves it, although I haven't tested the entire
> > > world yet.
> > 
> > Mmm...
> > But don't have the SSP change at all, since I still have a 7-stable
> > userland.
> > Static compiled binaries (/rescue) works fine.
> 
> Strange enough disabling SSP did make a difference, but I still have
> problems at some point:
> 
> Trying to mount root from ufs:/dev/mmcsd0s1a
> Loading configuration files.
> usb_new_device: set address 2 failed - trying a port reset
> No suitable dump device was found.
> usb_new_device: set address 2 failed - trying a port reset
> Entropy harvesting: interrupts ethernet point_to_pointusb_new_device: set address 2 failed - trying a port reset
> usbd_new_device: addr=2, getting first desc failed
> uhub_explore: usb_new_device failed, error=IOERROR
> uhub0: device problem (IOERROR), disabling port 2
>  kickstart.
> swapon: adding /dev/mmcsd0s1b as swap device
> Starting file system checks:
> /dev/mmcsd0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS
> /dev/mmcsd0s1a: clean, 264157 free (25021 frags, 29892 blocks, 6.0% fragmentation)
> pid 59 (mount), uid 0: exited on signal 11 (core dumped)
> Segmentation fault (core dumped)
> Mounting root filesystem rw failed, startup aborted
> ERROR: ABORTING BOOT (sending SIGTERM to parent)!
> Jul 17 16:04:26 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode
> Enter full pathname of shell or RETURN for /bin/sh: 
> 
> I'll try more recent code.
> Maybe I got something bad.

No change - with SSP all dynamic linked binaries fail the same as the
7-stable did.
Without SSP only some binaries fail, but those are the same.
And of course since my 7-stable binaries were failing as well this
sounds like a kernel thing and not a userland one.

What comes to mind after reading the original commit when reading the
compiler options used:
cc -mlittle-endian -c -O2 -pipe -fno-strict-aliasing -mcpu=arm9 -std=c99  -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc  -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=arm9 -ffreestanding -fstack-protector -Werror  ../../../arm/at91/at91_twi.c
The original message says that -fstack-protector shouldn't be used for
the kernel.
So why it is there?
I never explicitly enabled it anywhere.

-- 
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.