martin@duskware.de wrote:

> >Synopsis:       can not build libc when running a -current kernel

So this bit me as well :-(

On my alpha, just running:

	ld -x -shared -soname libc.so.12 -o libc.so.12.76 \
	    /usr/lib/crtbeginS.o --whole-archive libc_pic.a \
	    --no-whole-archive /usr/lib/crtendS.o

in the same directory with an old kernel (1.5V, May 23) produced
different output to a new kernel (day old sources).  The libc_pic.a
produced by both kernels was identical (except for an ar(1) datestamp).

A ktrace on the above command against old and new kernel shows _zero_
differences (if kdump had an option not to spit out the PID that
step would have been easier!), so the problem must be in the kernel
somewhere.

Looking at the good and bad libc.so.12.76's, there's three differences:

    0xc6000-0xc7fff	in the read-only data section:
	  9 .rodata       00006e55  00000000000c42c0  00000000000c42c0  000c42c0  2**3
			  CONTENTS, ALLOC, LOAD, READONLY, DATA

	The good file has normal looking C strings, the bad file
	random looking gibberish.  This is a full 8k page starting
	at a page boundary.

    0xcb116-0xcbfff	crossing a couple of sections:
	  9 .rodata       00006e55  00000000000c42c0  00000000000c42c0  000c42c0  2**3
			  CONTENTS, ALLOC, LOAD, READONLY, DATA
	 10 .lit8         00000030  00000000000cb120  00000000000cb120  000cb120  2**4
			  CONTENTS, ALLOC, LOAD, READONLY, DATA
	 11 .note.netbsd.ident 00000018  00000000000cb150  00000000000cb150  000cb150  2**2
			  CONTENTS, ALLOC, LOAD, READONLY, DATA
	 12 .data         00004248  00000000001cb168  00000000001cb168  000cb168  2**3
			  CONTENTS, ALLOC, LOAD, DATA

	This first bit up to 0xcb120 is in the gap between two sections.
	The remainder (0xcb120-0xcbfff) is quite different between the
	two files.  This starts in the middle of page but finishes at a
	page boundary.

    0xd581a-0xd581f 
	 17 .dynamic      00000100  00000000001d5718  00000000001d5718  000d5718  2**3
			  CONTENTS, ALLOC, LOAD, DATA
	 18 .bss          0000cb28  00000000001d5820  00000000001d5820  000d5820  2**4
			  ALLOC
	 19 .comment      00007d78  0000000000000000  0000000000000000  000d5820  2**0
			  CONTENTS, READONLY

	This is in the gap between two sections.

Also, the output between a "ld .." libc.so and a "ktrace ld ..." is
different!  The following byte ranges are different:

    0x19b8a-0x19b8f
    0xc6000-0xc7fff
    0xca000-0xcab29
    0xcb116-0xcbfff
    0xd581a-0xd581f

One diff contains some GNUish output, which doesn't appear in libc_pic.a
or anywhere else in that directory:

	+000cb110 | 7362 696e  0020 2041  206e 756d  6265 7220 | sbin.  A number 
	+000cb120 | 6f66 2063  6f6d 7061  6e69 6573  2061 6e64 | of companies and
	+000cb130 | 2069 6e64  6976 6964  7561 6c73  206f 6666 |  individuals off
	+000cb140 | 6572 2073  7570 706f  7274 2066  6f72 2047 | er support for G
	+000cb150 | 4e55 0a70  726f 6475  6374 732e  2020 4966 | NU.products.  If
	+000cb160 | 2079 6f75  206f 6274  6169 6e65  0000 0000 |  you obtaine....
	+000cb170 | 6520 6269  6e61 7279  2075 7469  6c69 7469 | e binary utiliti
	+000cb180 | 6573 2066  726f 6d20  6120 7375  7070 6f72 | es from a suppor
	+000cb190 | 740a 6f72  6761 6e69  7a61 7469  6f6e 2c20 | t.organization, 
	+000cb1a0 | 7765 2072  6563 6f6d  6d65 6e64  2079 6f75 | we recommend you

I've got no clue what all this proves, other than something is
definitely not right :(

Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD CDs, Support and Service:    http://www.wasabisystems.com/