[OpenBIOS] Multiple APIs for ELF file handling

[Mark Cave-Ayland]

Blue Swirl wrote:

>>  Hmmm that could be possible, although in order to commit a compilable
>> build, it means making similar changes all over the arch/ tree before then
>> moving just one copy into libopenbios. So that's a lot of extra work just to
>> then rip it out in a subsequent commit :(  I think I'd much rather try and
>> figure out why my latest SVN development code is failing in the Fcode loader
>> if at all possible.
> 
> How about the other way round then, make the change after merge?

Again, there is a similar situation here. In order to bring the loaders 
into libopenbios, I had to implement the concept of 
"saved-program-state" from the OF spec. Hence all off the loaders (and 
also platform-boot) need to be modified to take this into account :(

>>  For those who are interested, the current SVN build status for me is given
>> below (using cross-compiling where appropriate on x86 Linux):
>>
>>
>>  arch/amd64      : builds openbios-unix only
>>  arch/ppc/briq   : fails to compile with "Error -34 occured." error
>>  arch/ppc/mol    : fails to compile with "undefined word" error
>>  arch/ppc/pearpc : fails to compile with "Error -34 occured." error
>>  arch/ppc/qemu   : builds ok
>>  arch/sparc32    : builds ok
>>  arch/sparc64    : builds ok
>>  arch/x86        : builds ok
>>
>>
>>  So in theory, I should be most of the way there by having a compilable
>> build for the 4 successful platforms above. PPC does look quite broken at
>> the moment though :(  Is there a current maintainer for the PPC code?
> 
> Laurent used to do a lot of PPC stuff, but he hasn't been active for a
> while. Didn't Alexander also get commit access?
> 
> I test ppc/qemu every now and then, but I don't know how to test briq,
> mol or pearpc. Also for x86 and amd64 I only test unix build.

Once of the things that has bugged me for a while has been that 
forthstrap is not particularly helpful when an error occurs. I've added 
some code to help with this, so now forthstrap will report a file name 
and line number if an undefined word is used or a runtime word causes a 
Forth error.

Similary, based on my mini-PPC fault-finding experience, I altered the 
exception handler routine to be a function pointer to allow the handler 
to be changed during bootstrap. This also now allows us to indicate 
whether the error is caused by executing source directly or by executing 
an existing base dictionary.

Now when I try and build PPC pearpc I get this:


Configuring OpenBIOS on amd64 for cross-ppc
Initializing build tree obj-ppc...ok.
Creating target Makefile...ok.
Creating config files...ok.
Building OpenBIOS for ppc
Building...error:
make[1]: Entering directory 
`/home/build/src/openbios/openbios-devel.pre/obj-ppc'
   GEN   target/include/openbios-version.h
   GEN   forth/version.fs
  HOSTCC host/kernel/bootstrap.o
  HOSTCC host/kernel/dict.o
  HOSTCC host/kernel/primitives.o
  HOSTCC host/kernel/stack.o
  HOSTCC forthstrap
   GEN   bootstrap.dict
   GEN   openbios.dict
   GEN   openbios-pearpc.dict
Error executing base dictionary ./openbios.dict: error -34 occured.
make[1]: *** [openbios-pearpc.dict] Error 1
make[1]: Leaving directory 
`/home/build/src/openbios/openbios-devel.pre/obj-ppc'
make: *** [build] Error 1


So it looks like the issue is with something trying to access an unknown 
device in one of the initialisers invoked in openbios.dict. At some 
point I should probably add a mechanism to allow a Forth throw to set an 
error string which can be retrieved by the error handler - but that can 
wait a little while longer.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs