Subject: Re: --db_more-- in recent sparc64 kernel
To: None <eeh@netbsd.org>
From: Andrey Petrov <petrov@netbsd.org>
List: port-sparc64
Date: 07/13/2001 19:21:00
On Sat, Jul 14, 2001 at 01:33:18AM -0000, eeh@netbsd.org wrote:
>
> There does not seem to be any overlap. There is 813303 bytes between the
> end of the text segment and the beginning of the data segment. There
> is surprizingly little in the data segment. Under 1MB.
Never actually looked into data size.
Size gave not very different.
% size netbsd.good
text data bss dec hex filename
1858366 115840 381808 2356014 23f32e netbsd
% size netbsd.bad
text data bss dec hex filename
3383449 142040 503688 4029177 3d7af9 netbsd.new2
>
> I have seen this sort of thing myself recently. It would appear that the
> linker is fouling up. If I grab one of these corrupt kernel images, stick
> it under gdb, and dump out statically initialized data, say cn_tab, the data
> is corrupt.
What should be there? Both cn_tab and proc0 point to 14xxxxx adresses.
>
>
> Fire up GDB on the umage and see what you have in, say, proc0.
> Also, if there is only one segment, or confusion between segments,
> it is quite possible that writeable data has is read-only because
> it has text protection.
I added debug for locore only and the kernel ended up on TL=1 with
message 'Fast data protection...'
I have another machine with similar setup but different tool-chain and
this kernel builds and boots there. I don't have access to this box
right now so I'll check image tonight.
Yes, it looks that's that a toolchain problem.
Andrey