Subject: Re: kern/13353: can not build libc when running a -current kernel
To: None <martin@duskware.de>
From: Simon Burge <simonb@wasabisystems.com>
List: netbsd-bugs
Date: 07/03/2001 15:27:23
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/