[parisc-linux] Today's boot experience on a 735

[John David Anglin]

> 
> Could someone explain to me what the real problem with the _end symbol 
> is? I can't seem to extract the essence of the problem from all the mail 
> that's flying by.
> 
> The SOM linker is supposed to create the symbol "_etext" at the end of 
> the last text subspace, the symbol "_edata" at the end of the last 
> initialized data subspace, and the symbol "_end" at the end of the last 
> data subspace. It shouldn't matter what the name of the subspace is, or 
> what its sort key is. Common symbols get allocated at the end of the last 
> data subspace, and the "_end" symbol should be at the end of that. If 
> something is being allocated by the linker after "_end", I'd like to 
> understand why.

The SOM linker is not putting "_end" at the end of the last initialized
data subspace.  It is put at the beginning of the $DLT$ subspace which
follows $BSS$.  However, the subspace $DLT$ also contains uninitialized
global common variables.  These objects can be seen to come after _end
if you generate a linker map or examine the kernel with nm.  Any object
that is not explicitly initialized and has global scope ends up in $DLT$.

The kernel needs to determine where its data ends and free memory starts.
Thus, it needs to know where its global common area ends.

Jeff Law suggested that we not use the linker for this, but use the
sort keys to define a subspace that came after $DLT$.  After a little
experimentation trying to define a section $AFTERDLT$, I found that
$DLT$ probably had a sort key of 255 and when I specified a sort key
of 255 for $AFTERDLT$ the linker moved the stuff it was previously
putting into $DLT$ into $AFTERDLT$.  Further, it now sized $AFTERDLT"
and put _end at the end of $AFTERDLT$.  Just what we needed!

I recognize that there is probably a linker bug involved here.  I am
building the kernel with gcc-2.95.2/binutils-2.9.5.  The linker is
/usr/bin/ld:
        92453-07 linker linker ld B.10.33 990520

From the name $DLT$, I thought that it was a section for data linkage
tables.  I am surprised the global common variables are being placed
in $DLT$.  I would have thought they should have been placed in $BSS$.

> You should be able to use "_edata" and "_end" to figure out how much 
> memory to initialize to zero at startup, or you could have the boot 
> loader do that for you -- the information is in the a.out aux header.

I haven't verified this myself but I believe others have determined
that the kernel needs to clear unitialized data itself because of the
various different way it is loaded.

> By the way, the SOM linker does support "scripts" of a sort. They're 
> called k-files (because you use the -k option to specify them), and they 
> allow you to control the placement of your spaces and subspaces within 
> the address space.

That's good to know and it might provide a better way for the kernel to
determine its end.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)