Hi folks,
With my attempt to figure out why the PPC builds aren't working, I've
spent a little more time working on improving the error reporting in
forthstrap. Having had more of an insight as to how forthstrap works, I
figured it might be useful to share my notes on how the process works.
Tracing through the code, I now realise why my first attempt at locating
errors didn't work very well. It seems that forthstrap
(kernel/bootstrap.c) actually has two different modes depending upon
whether a base dictionary is supplied on the command line or not.
- If no base dictionary is supplied, then the input source files are
compiled using the C implementation of the forth interpreter realised by
the interpret_source() function.
- If a base dictionary is supplied, load the base dictionary from disk
and invoke the initialize word in order to run the forth kernel.
From the Makefile it is possible to see that the first time forthstrap
is invoked, no base dictionary is supplied and so a dictionary
containing a basic Forth interpreter is built using the C interpreter
implementation in kernel/bootstrap.c.
On subsequent calls to forthstrap, the previous dictionary is passed in
as a base dictionary. forthstrap loads the dictionary and invokes the
initialize word to run the Forth interpreter. The important part is the
#ifdef...#endif section in kernel/forth.c for the "key" word. What this
does is override the default I/O functions so that the contents of each
input file passed on the command line are piped into the kernel one
character at a time.
By adding a new switch to forthstrap and trapping the "emit" word in a
similar way, it is possible to redirect the console output to a separate
file for debugging purposes. Hence I've added a -c switch to forthstrap
and altered the build system so that for a given base dictionary
foo.dict, a new file call foo.dict-console.log is automatically
generated which shows the Forth words being piped into the kernel.
With these changes in place, the ability to debug a broken build is
considerably increased. Now when I try and build one of the broken PPC
builds (in this case pearpc), I get the following in SVN trunk:
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
../arch/ppc/pearpc/tree.fs:64: no such device.
make[1]: *** [openbios-pearpc.dict] Error 1
make[1]: Leaving directory
`/home/build/src/openbios/openbios-devel.pre/obj-ppc'
make: *** [build] Error 1
Surely enough, at the end of line 63 in arch/ppc/pearpc/tree.fs we see
the following:
" /pci" find-device
Hence it seems as if no /pci node is being created which is breaking the
pearpc build. And just to confirm this, the last few lines of
openbios-pearpc.dict-console.log look like this:
build@zeno:~/src/openbios/openbios-devel.pre$ tail -n 5
obj-ppc/openbios-pearpc.dict-console.log
0 > h# 88201 encode-int " cpu-version" property ok
0 > 0 encode-int " reg" property ok
0 > finish-device ok
0 > ok
0 > " /pci" find-device
Now I've got things to the point where the error reporting works well,
I'll get back to finishing up my loader consolidation patch...
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
Hi all,
I've spent some time today looking at the ELF loader code for each
different architecture, and with a bit of work I believe that I can
modify arch/sparc64/elfload.c so that it can be used across all
architectures.
Looking closer at the source, it can be seen that are actually two sets
of ELF routines: one in arch/*/elfload.c, and another set in
libopenbios/elfload.c which only appears to be used by the PPC code.
I've already manage to refactor the SPARC64 code so it reuses (and also
exposes) the same API for use with the PPC code, except with one
exception: file handles.
In arch/*/elfload.c, the preferred method for using handles is to make
use of the included loadfs.c methods which works with an implicit file
handle (i.e. the file handle isn't passed into any of the functions). In
contrast, the PPC code directly calls the *_io() API (see
find_elf()/elf_readhdrs()) and so requires an explicit file handle to be
passed into each function.
I'm currently leaning towards the PPC method, since loadfs.c seems to be
such a lightweight wrapper that it hardly seems worth keeping. Can
anyone see a reason to keep this before I go and rip it out?
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
Or is it just some kind of routing issue? I seem to get intermittent
pings but no website.
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
> Programmingkid wrote:
>
>> I have recently been able to go further in the build process of OpenBIOS thanks to recent changes. It stop building after forthstrap is made.
>>
>> Here is the error:
>>
>> HOSTCC forthstrap
>> GEN bootstrap.dict
>> panic: segmentation violation at 0x30061c
>> dict=0x100300000 here=0x100300628(dict+0x628) pc=0x0(dict+0xffd00000)
>> dstackcnt=0 rstackcnt=0 instruction=deadbeef
>> dstack: 0x0
>> rstack: 0x0
>> Writing dictionary core file
>> make[1]: *** [bootstrap.dict] Error 1
>>
>> Anyone know how to fix this problem or know what is causing the problem?
>
> Oh really? I didn't realise that an OS X host build was broken, but it's
> good to hear that at least you can get a bit further now. Is this from a
> vanilla SVN checkout? The only reason I ask is that when I was working
> on code patches in forth/bootstrap/bootstrap.fs, it was fairly easy to
> cause forthstrap to segfault due to coding errors.
I always download the "most current snapshot". I never use the SVN checkout.
I have recently been able to go further in the build process of OpenBIOS thanks to recent changes. It stop building after forthstrap is made.
Here is the error:
HOSTCC forthstrap
GEN bootstrap.dict
panic: segmentation violation at 0x30061c
dict=0x100300000 here=0x100300628(dict+0x628) pc=0x0(dict+0xffd00000)
dstackcnt=0 rstackcnt=0 instruction=deadbeef
dstack: 0x0
rstack: 0x0
Writing dictionary core file
make[1]: *** [bootstrap.dict] Error 1
Anyone know how to fix this problem or know what is causing the problem?