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

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

[John David Anglin]

This is a transcript of the boot messages on a 735 using the default
CVS config:

kernel(0x0000001), 0x04DFF870, 0x04DFF900, 0x00016A70)
Clear BSS 0x00118470-->0x0012FA80
Boot loader: HP-UX ISL
Warning realmode_setup.c *guessing* where free mem starts!
realmode_setup exiting.

This is better than yesterday when there was no output.  The BSS
region looks ok.  HP-UX ISL is correct.  The address of _end in the
vmlinux object looks reasonable:

_end                |0xc012fa80|extern|data   |$DLT$

Why does realmode_setup have to guess where free mem starts?  Oh, I
think the name of realmode_setup has changed.

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

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

[Paul Bame]

= This is a transcript of the boot messages on a 735 using the default
= CVS config:
= 
= kernel(0x0000001), 0x04DFF870, 0x04DFF900, 0x00016A70)
= Clear BSS 0x00118470-->0x0012FA80
= Boot loader: HP-UX ISL
= Warning realmode_setup.c *guessing* where free mem starts!
= realmode_setup exiting.
= 
= This is better than yesterday when there was no output.  The BSS
= region looks ok.  HP-UX ISL is correct.  The address of _end in the
= vmlinux object looks reasonable:
= 
= _end                |0xc012fa80|extern|data   |$DLT$
= 
= Why does realmode_setup have to guess where free mem starts?

The _end symbol is not a reliable indicator of where
the kernel's memory ends.  And the hpux
bootloader doesn't provide the SOM header from whence this could
theoretically be calculated.  I haven't tried out the _end trick
posted last week, but it looks like it'll work (don't call the symbol
_end if you try it).  As long as your kernel links, the guess is
probably OK for now.

	-P

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

[John David Anglin]

> The _end symbol is not a reliable indicator of where
> the kernel's memory ends.  And the hpux
> bootloader doesn't provide the SOM header from whence this could
> theoretically be calculated.  I haven't tried out the _end trick
> posted last week, but it looks like it'll work (don't call the symbol
> _end if you try it).  As long as your kernel links, the guess is
> probably OK for now.

Ok, I see the problem now.  The section $DLT$ contains a bunch of
undefined common symbols as well as _end.  For example,

boot_cpu_data       |       416|undef |common |$CODE$

The _end defined by the linker is the end of the bss section but not
the end of last section of the kernel.

Why is boot_cpu_data in $CODE$ rather than $DATA$?  There may be
some incorrect .section/.subsection directives somewhere (probably
in the include files).

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

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

[John David Anglin]

> > The _end symbol is not a reliable indicator of where
> > the kernel's memory ends.  And the hpux
> > bootloader doesn't provide the SOM header from whence this could
> > theoretically be calculated.  I haven't tried out the _end trick
> > posted last week, but it looks like it'll work (don't call the symbol
> > _end if you try it).  As long as your kernel links, the guess is
> > probably OK for now.
> 
> Ok, I see the problem now.  The section $DLT$ contains a bunch of
> undefined common symbols as well as _end.  For example,
> 
> boot_cpu_data       |       416|undef |common |$CODE$
> 
> The _end defined by the linker is the end of the bss section but not
> the end of last section of the kernel.

Ok, this is a programing problem.  For objects that don't need external
linkage, declare them static.  For those that do, initialize them!  This
will eliminate those pesky common variables.  For example,

--- setup.c.orig	Fri Nov 12 18:23:50 1999
+++ setup.c	Tue Nov 16 17:46:36 1999
@@ -57,14 +57,14 @@
 
 
 #define COMMAND_LINE_SIZE 1024
-char 	saved_command_line[COMMAND_LINE_SIZE];
+char 	saved_command_line[COMMAND_LINE_SIZE] = {};
 
 #define pdc_wrapper(args...) ({				\
 	real_routine = (void *)PAGE0->mem_pdc;		\
 	real_call(##args);				\
 })
 
-struct cpuinfo_parisc boot_cpu_data;
+struct cpuinfo_parisc boot_cpu_data = {};
 
 extern __initfunc(unsigned long hp700fb_init(unsigned long mem_start));
 extern	void dino_init(void);
@@ -73,7 +73,7 @@
 #endif
 extern void do_inventory(void);
 
-PDC_CALL pdc;
+PDC_CALL pdc = {};
 
 
 void __xchg_called_with_bad_pointer(void)

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

[John David Anglin]

> > > The _end symbol is not a reliable indicator of where
> > > the kernel's memory ends.  And the hpux
> > > bootloader doesn't provide the SOM header from whence this could
> > > theoretically be calculated.  I haven't tried out the _end trick
> > > posted last week, but it looks like it'll work (don't call the symbol
> > > _end if you try it).  As long as your kernel links, the guess is
> > > probably OK for now.
> > 
> > Ok, I see the problem now.  The section $DLT$ contains a bunch of
> > undefined common symbols as well as _end.  For example,
> > 
> > boot_cpu_data       |       416|undef |common |$CODE$
> > 
> > The _end defined by the linker is the end of the bss section but not
> > the end of last section of the kernel.
> 
> Ok, this is a programing problem.  For objects that don't need external
> linkage, declare them static.  For those that do, initialize them!  This
> will eliminate those pesky common variables.  For example,

The problem of uninitialized global data is present throughout the kernel.
Initializing these objects might make the kernel unnecessarily larger.  Thus,
I thought I would try the suggestion of Jeff Law.  However, after a little
experimentaion, I found that there isn't a sort key that will put the
$AFTERDLT$ section after the $DLT$ section.  However, I think the following
solution will do the job.  Try it out.  It might depend on linker version
or who knows what else.

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

;    theend.S

;    Copyright (C) 1999 John David Anglin
;
;    This program is free software; you can redistribute it and/or modify
;    it under the terms of the GNU General Public License as published by
;    the Free Software Foundation; either version 2, or (at your option)
;    any later version.

;    This program is distributed in the hope that it will be useful,
;    but WITHOUT ANY WARRANTY; without even the implied warranty of
;    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
;    GNU General Public License for more details.

;    You should have received a copy of the GNU General Public License
;    along with this program; if not, write to the Free Software
;    Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

;    Wierd hack to force the linker to define _end correctly.

;    The sort key of 255 causes the linker to rename the $DLT$
;    section to $AFTERDLT$ and size it.  As a result, the _end
;    symbol defined by the linker correctly reflects the end of
;    the undefined common section.

	.space $PRIVATE$
	.subspa $AFTERDLT$,QUAD=1,ALIGN=8,ACCESS=31,ZERO,SORT=255
	.globl _start_dlt
_start_dlt:

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

[Jeffrey A Law]

  In message <199911170204.VAA11108@hiauly1.hia.nrc.ca>you write:
  > experimentaion, I found that there isn't a sort key that will put the
  > $AFTERDLT$ section after the $DLT$ section.  However, I think the following
  > solution will do the job.  Try it out.  It might depend on linker version
  > or who knows what else.
There's always a way.

Create a .o file which contains a DLT & AFTERDLT section.  Make sure the
DLT section appears first in the object file (I'm assuming they have the
same sort keys).  Referece that .o first on the link line.

jeff

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

[John David Anglin]

>   In message <199911170204.VAA11108@hiauly1.hia.nrc.ca>you write:
>   > experimentaion, I found that there isn't a sort key that will put the
>   > $AFTERDLT$ section after the $DLT$ section.  However, I think the following
>   > solution will do the job.  Try it out.  It might depend on linker version
>   > or who knows what else.
> There's always a way.
> 
> Create a .o file which contains a DLT & AFTERDLT section.  Make sure the
> DLT section appears first in the object file (I'm assuming they have the
> same sort keys).  Referece that .o first on the link line.

As I noted, it appears to work as is.  Do you know why the DLT section
disappeared when I used the sort key of 255 for AFTERDLT?  Although
I haven't tried it, it may not be possible to create an object file with
both DLT and AFTERDLT sections.

Dave

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

[Jeffrey A Law]

  In message <199911170248.VAA15412@hiauly1.hia.nrc.ca>you write:
  > > 
  > > Create a .o file which contains a DLT & AFTERDLT section.  Make sure the
  > > DLT section appears first in the object file (I'm assuming they have the
  > > same sort keys).  Referece that .o first on the link line.
  > 
  > As I noted, it appears to work as is.
Yea, but you appear to be depending on highly suspicious behavior.    The
trick of ordering subspaces in the first .o on the link line to provide an
ordering for the subspaces in the final executable relies on documented
behavior of the HP linker.


  > you know why the DLT section
  > disappeared when I used the sort key of 255 for AFTERDLT?  Although
  > I haven't tried it, it may not be possible to create an object file with
  > both DLT and AFTERDLT sections.
Not really.  I do know that we had major problems with pxdb (post-link 
processor
on HPs) mysteriously removing subspaces with sort keys of 255 in the past.

jeff

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

[Philipp Rumpf]

> Yea, but you appear to be depending on highly suspicious behavior.    The
> trick of ordering subspaces in the first .o on the link line to provide an
> ordering for the subspaces in the final executable relies on documented
> behavior of the HP linker.

After reading the whole discussion, I have to admit I really don't understand
what the problem is.  Maybe the boot loader doesn't tell us where the kernel
ends, but do we really want to know ?  We know that everything after the start
of the BSS section is our memory, and no-one is going to expect any nonzero
value beyond it.

While memsetting the whole memory after the start of the BSS section might be
overkill, it certainly will eliminate some otherwise unreproducable bugs.
Maybe limit it to some barrier that will be sane for the foreseeable future
(say, 16 MB) (and do print a warning / panic if _end is even higher), but it
shouldn't be a problem just doing it the stupid way now and do it right when
we have ELF, no ?

	Philipp Rumpf

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

[John David Anglin]

> 
> > Yea, but you appear to be depending on highly suspicious behavior.    The
> > trick of ordering subspaces in the first .o on the link line to provide an
> > ordering for the subspaces in the final executable relies on documented
> > behavior of the HP linker.
> 
> After reading the whole discussion, I have to admit I really don't understand
> what the problem is.  Maybe the boot loader doesn't tell us where the kernel
> ends, but do we really want to know ?  We know that everything after the start
> of the BSS section is our memory, and no-one is going to expect any nonzero
> value beyond it.

The problem is the kernel can't determine how big its common data section
is and therefore where free memory should start.  There are quite a few
big structures and arrays throughout the linux code that are global and
not initiallized.  Without the trick, _end is located at the end of the
bss section.  When "theend" is linked in, _end moves to the end of
unitialized common data and the kernel can easily determine where free
memory starts.

The current hack to determine the start of free memory is to use a symbol
that is near the end of the common data and add a fudge amount to it.
This failed for me recently when I built a configuration without network
support and the symbol was no longer defined.  The size of the common
data varies depending on kernel configuration as well.

Uninitialized common data can be avoided by using static or explicitly
initializing the data object (puts data into $DATA$ instead of $DLT$).
However, if you explicitly initialize, the size of the kernel will grow.
I know some systems still allow installation from floppies.  The kernel
might get too big for this if all common data were explicitly initialized.

Memory from the start of the bss section to the end of the common data
should be zeroed.  I presume other free memory will be initialized when
it is used.

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

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

[Philipp Rumpf]

> The problem is the kernel can't determine how big its common data section
> is and therefore where free memory should start.

Okay, I didn't take into account we actually want to know where our free
memory starts  -  sometimes being stupid doesn't help.

> There are quite a few big structures and arrays throughout the linux code
> that are global and not initiallized.
> Uninitialized common data can be avoided by using static or explicitly
> initializing the data object (puts data into $DATA$ instead of $DLT$).

> Without the trick, _end is located at the end of the
> bss section.  When "theend" is linked in, _end moves to the end of
> unitialized common data and the kernel can easily determine where free
> memory starts.

Okay, this is a SOM-specific bug around a missing feature of the SOM linker
(i.e. not supporting linker scripts) (tell me if I'm wrong).

> The current hack to determine the start of free memory is to use a symbol
> that is near the end of the common data and add a fudge amount to it.

> This failed for me recently when I built a configuration without network
> support and the symbol was no longer defined.  The size of the common
> data varies depending on kernel configuration as well.

Yeah, this code needs to go / change.

> However, if you explicitly initialize, the size of the kernel will grow.
> I know some systems still allow installation from floppies.  The kernel

PARISC systems ?

> Memory from the start of the bss section to the end of the common data
> should be zeroed.  I presume other free memory will be initialized when
> it is used.

yup, Linux doesn't need to have all available memory zero'd out on boot.

	Philipp Rumpf

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

[John David Anglin]

>   > you know why the DLT section
>   > disappeared when I used the sort key of 255 for AFTERDLT?  Although
>   > I haven't tried it, it may not be possible to create an object file with
>   > both DLT and AFTERDLT sections.
> Not really.  I do know that we had major problems with pxdb (post-link 
> processor
> on HPs) mysteriously removing subspaces with sort keys of 255 in the past.

I did a little testing with your second suggestion.  What happens
is DLT is empty except for the one symbol that I created in it.  The linker
always goes last and it seems to dump the common symbols into the last
section with sort key 255.  I think DLT was deleted because it was
empty.

Is there a solution that doesn't rely on this obscure linker behaviour?
I think that if gas were modified to allocate common symbols in a special
section, then we wouldn't have this problem.  However, I think this would
require that common symbols would always have to be fixed in size. While
this is normal practice in C, the assembler would not work with fortran
where it is normal practice to have common blocks of varying size.

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

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

[Cary Coutant]

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.

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.

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.

-cary

Re: [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

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

[Philipp Rumpf]

> > 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.

The problem is we need to know where free memory starts for our memory
allocator - who does the BSS clearing is another issue.

> > 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.

Is anyone reasonably fluent in whatever language ld uses ?

	Philipp Rumpf