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