Re: booting via bootblock != loadbsd

[Tim Walls <tim.walls%pa.press.net@localhost>]

> Quoting Ignatios Souvatzis (05-Jun-00 23:11:36):
> 
>>> BTW, what is the symbol table in:
>>> "-S  Include kernel symbol table."
> 
>> The one you need to see symbolic values when you start the kernel
>> debugger
>> (ddb).
> 
> ?!?! ... seems to be insider stuff ;))
> 
> Ok, thanks.

Don't worry, it's not that complicated...

Very basically (and I'm sure people will pick me up with corrections,)
when the C compiler allocates a variable (including a function,) it
is basically allocating a memory address - eg. it says 'the variable
numberOfInterrupts is at address 0x1000, the function getNumberOfInts()
is at address 0x1100.

That is fine for the computer, since the compiled code only ever
refers to the variables & functions by their address, not by name -
when you call the function getNumberOfInts(), the compiler translates
that into 'call whatever code is at 0x1100.'


If you have a human trying to debug the code, though, it is practically
impossible to know what's going on given memory addresses only.  So the
compiler can be told to include the symbol table - a big table like

   Symbol               Address
   -----------          -------------
   numberOfInterrupts   0x1000
   getNumberOfInts()    0x1100

This lets a debugger print the symbolic name for variables and functions
rather than the addresses.  So rather than 'Seg fault at 0x1100' you
will get 'Seg fault at getNumberOfInts()'  (If only it was quite
that easy, but you get the idea <grin>.)

The downside, of course, is that your binary ends up being larger...

Hope that helps,
Tim.


(Note that not all languages work like this...  eg. Java ports its 'symbol
table' around with the code all the time; this allows some of its whizzier
features like reflection (runtime class introspection) to work, but also
means that it's very easy to decompile into readable source code!)

-- 
Tim Walls