Building Inferno to run on OpenBSD

[Ethan Long]

Hello, I was wondering if anyone had experience actually building Inferno to run on OpenBSD?

I first tried makemk with mkconfig, and got linking errors trying to make mk. 

I then used the Plan9Port build of mk, when building runt.h, I get a segmentation fault.

Not sure how I might go about this, anyone have any experience/suggestions? 

[da...@boddie.org.uk]

On Wednesday 6 January 2021, Ethan wrote:

Hello, I was wondering if anyone had experience actually building Inferno to run on OpenBSD?

Never tried it, so I guess this is where I learn something. ;-)

I first tried makemk with mkconfig, and got linking errors trying to make mk.

What were the errors?

 

I then used the Plan9Port build of mk, when building runt.h, I get a segmentation fault.

Not sure how I might go about this, anyone have any experience/suggestions? 

Which architecture are you building on? There are some things to fix when building on 64-bit

systems that might not be done in the OpenBSD mkfiles.

David

[Ethan Long]

I built it on amd64, I'll include in depth errors here but I suspect it to be an out of date mkfile and the fact that OpenBSD only supports 64 bit programs. I built it fine on my Plan 9front virtual machine.

I figured out where that the issue occurs when using Plan9Port mk, it happens when the first Limbo compilation occurs. Confirming this, whenever I run limbo I immediately get a segmentation fault. 

Here are the makemk errors:

ld: error: Posix.o is incompatible with /usr/bin/../lib/crt0.o

ld: error: sh.o is incompatible with /usr/bin/../lib/crt0.o 

ld: error: arc.o is incompatible with /usr/bin/../lib/crt0.o

ld: error: archive.o is incompatible with /usr/bin/../lib/crt0.o

ld: error: bufblock.o is incompatible with /usr/bin/../lib/crt0.o

ld: error: env.o is incompatible with /usr/bin/../lib/crt0.o

ld: error: file.o is incompatible with /usr/bin/../lib/crt0.o

.... (goes on for about 20 more entries) 

mk link failed

Here is the segmentation fault when running mk install:

rm -f /home/ethan/src/inferno/OpenBSD/386/bin/limbo && cp o.out /home/ethan/src/inferno/OpenBSD/386/bin/limbo

(cd libinterp; mk install) 

rm -f runt.h && limbo -a -I../module ../module/runt.m > runt.h

Segmentation fault (core dumped) 

The limbo binary itself always segfaults

What should I change in the mk files to get it to work?

--
You received this message because you are subscribed to the Google Groups "inferno-os" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inferno-os+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/inferno-os/4c0cf9c0-b3c7-4e3a-8b4e-2f09436a21fcn%40googlegroups.com.

[David Boddie]

On Thursday 7. January 2021 21.25.41 Ethan Long wrote:
> I built it on amd64, I'll include in depth errors here but I suspect it to
> be an out of date mkfile and the fact that OpenBSD only supports 64 bit
> programs. I built it fine on my Plan 9front virtual machine.

Yes, I think the lack of 32-bit libraries and compatibility is going to make
it impossible to build and run.

> I figured out where that the issue occurs when using Plan9Port mk, it
> happens when the first Limbo compilation occurs. Confirming this, whenever
> I run limbo I immediately get a segmentation fault.
>
> Here are the makemk errors:
> ld: error: Posix.o is incompatible with /usr/bin/../lib/crt0.o
> ld: error: sh.o is incompatible with /usr/bin/../lib/crt0.o
> ld: error: arc.o is incompatible with /usr/bin/../lib/crt0.o
> ld: error: archive.o is incompatible with /usr/bin/../lib/crt0.o
> ld: error: bufblock.o is incompatible with /usr/bin/../lib/crt0.o
> ld: error: env.o is incompatible with /usr/bin/../lib/crt0.o
> ld: error: file.o is incompatible with /usr/bin/../lib/crt0.o
> .... (goes on for about 20 more entries)
> mk link failed

I got past these by removing the -m32 option for the CC and LD definitions in
the makemk.sh file. This allows mk to be built.

> Here is the segmentation fault when running mk install:
> rm -f /home/ethan/src/inferno/OpenBSD/386/bin/limbo && cp o.out
> /home/ethan/src/inferno/OpenBSD/386/bin/limbo
> (cd libinterp; mk install)
> rm -f runt.h && limbo -a -I../module ../module/runt.m > runt.h
> Segmentation fault (core dumped)
>
> The limbo binary itself always segfaults
>
> What should I change in the mk files to get it to work?

With no -m32 in use, limbo is built but segfaults for me, too.

rm -f runt.h && limbo -a -I../module ../module/runt.m > runt.h

[limbo]38422/162819 sp=ffff3518 inside 7f7fffbf6000-7f7fffff5000: not
MAP_STACK
Segmentation fault (core dumped)

I'm guessing that this is related to assumptions about 32-bit and would
welcome either corrections or verification. ;-)

David

[Jeff Sickel]

Inferno, dis more specifically, is 32-bit only. If you want to run
Inferno on 64-bit systems you need to launch dis in a 32-bit vm.

> --
> You received this message because you are subscribed to the Google Groups "inferno-os" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to inferno-os+...@googlegroups.com.

> To view this discussion on the web, visit https://groups.google.com/d/msgid/inferno-os/9311374.2nIt9XK40a%40aurora.

[clasp126...@icebubble.org]

Jeff Sickel <jeff....@gmail.com> writes:

> Inferno, dis more specifically, is 32-bit only. If you want to run
> Inferno on 64-bit systems you need to launch dis in a 32-bit vm.

Is that actually true? The dis architecture, itself, is a 32-bit
architecture. But it's a virtual machine, which means that it (at least
in theory) should be portable to a wide variety of host architectures.
(That's the whole point of the virtual machine layer.) Is there any
reason why emu couldn't be complied to run (32-bit) Dis code on 64-bit
hardware? Is there any reason why the native Inferno kernel couldn't be
complied to run (32-bit) Dis code on 64-bit hardware?

In fact, given the extra address space available on 64-bit
architectures, I'd imagine some interesting possibilities, i.e.,
potentially running multiple instances of the Dis VM on the same host.

[Go Phone]

Hello,

I am trying to get .dis files to be read on an amd64 machine (9front) to run inferno on an amd64 machine(hosted).

I think I am almost there except for reading the data space of the .dis files. I cannot figure out how to read the offsets into the data space as the offsets could be over pointers or just data.

Any pointers, please?

For the details, It is in the newmp() function, the D2H of the wp variable assumes that it is heap based. But, there seem to be strings being placed as-is into the origmp by the parsemod() function (DEFS).

Thanks

[Ethan Gardener]

On Wed, Jan 13, 2021, at 8:55 PM, clasp126...@icebubble.org wrote:
> Jeff Sickel <jeff....@gmail.com> writes:
>
> > Inferno, dis more specifically, is 32-bit only. If you want to run
> > Inferno on 64-bit systems you need to launch dis in a 32-bit vm.
>
> Is that actually true? The dis architecture, itself, is a 32-bit
> architecture. But it's a virtual machine, which means that it (at least
> in theory) should be portable to a wide variety of host architectures.
> (That's the whole point of the virtual machine layer.) Is there any
> reason why emu couldn't be complied to run (32-bit) Dis code on 64-bit
> hardware? Is there any reason why the native Inferno kernel couldn't be
> complied to run (32-bit) Dis code on 64-bit hardware?

I lived through the introduction of 64-bit PCs, using Linux the whole time. You'd be surprised how many little fixes need to be made when the size of int changes. 9front avoided a lot of work by keeping 32 bit ints. They still had to fix some old code which assumed a pointer can be held in an int. Some interpreters (notably Forth) need a single type which can hold a pointer and integers of some size. I don't know if Dis is one of them.

> In fact, given the extra address space available on 64-bit
> architectures, I'd imagine some interesting possibilities, i.e.,
> potentially running multiple instances of the Dis VM on the same host.

Inferno needs little memory. (Remember, it's a 90s system.) You can run many Dis VMs on a 2GB 32-bit machine. At one point, I ran 4 instances just for IRC: 3 for ircfs bridges and 1 running the ircfs gui.

OT: That was the time I discovered Charon ran much faster on my 466MHz iBook than my 2.4GHz Linux PC. ;) That was because the JIT was disabled for x86 due to a bug which hadn't been fixed. I wonder if it's fixed now. I also vaguely recall it running but crashing under 64-bit Linux which I think had 64-bit ints.

[bhgv]

interpreter - yes. but interpreter should work with the real memory adresses internally inside its virtual machine.

when i moved one x32 system to x64  (don't remember, maybe inferno?) i changed types of registers and containers inside virtual machine and supporting struct from int to long (on x32 long has 32 bits, on x64 - 64 bits and has the form compatible with void*. long long has other internal form then x64-void*)

but not only. not sure if i remember correct, but inferno uses in pair of places 32 bits variable as mask. buuut i'm not sure. to many of strange code i should repire last time.

четверг, 14 января 2021 г. в 04:21:20 UTC+3, clasp126...@icebubble.org:

[Go Phone]

On Fri, Jan 15, 2021 at 2:08 PM bhgv <bhgv....@gmail.com> wrote:

interpreter - yes. but interpreter should work with the real memory adresses internally inside its virtual machine.

when i moved one x32 system to x64  (don't remember, maybe inferno?) i changed types of registers and containers inside virtual machine and supporting struct from int to long (on x32 long has 32 bits, on x64 - 64 bits and has the form compatible with void*. long long has other internal form then x64-void*)

but not only. not sure if i remember correct, but inferno uses in pair of places 32 bits variable as mask. buuut i'm not sure. to many of strange code i should repire last time

This seems to be the doable part.

Translating the dis files is proving to be an onerous task, as the addresses are encoded in the instruction offsets. I can translate the data structures in the dis now.

Is there a way to start inferno without using a .dis file?

Thanks

[clasp126...@icebubble.org]

Go Phone <gopho...@gmail.com> writes:

> Is there a way to start inferno without using a .dis file?

I suppose you could modify emu (or the kernel, if running navitely) to
call a built-in module instead of loading and running emuinit.dis or
osinit.dis. I can't imagine why one would want to do this, unless
either it's either to debug the interpreter/kernel or to run a VERY
lightweight system in which all modules are implemented as built-in
modules.

[bhgv]

> Is there a way to start inferno without using a .dis file?

what do you want to get as a result?

inferno os contain 4 main ideas:

1) protocol 9p2000/styx (maybe all things inside based on it),

2) virtual machine for portability with possibility to relativelly easy add modules on C,

3) new multithread/module-based  language limbo (influence of the oberon is very noticeable. multithreaded oberon in C)

4) module-based internal system

what exactly are you interested in inferno? 9p protocol? you can use it separately. with your preferred language.

for example, full inferno is bad for small devices. size of executable and not always correct work with memory (for example, allocation of large buffers in local variables of functions is quite common. the stack size in small devices is very limited, and there are no memory protection).

it is wiser to use only 9p module, for example, with lua or micropithon.

are you not satisfied with dis-modules/machine? just rewrite the code generator. complex functions inside the dis-machine work like C-modules. +/-/= functions may be rewritten as you like.

> Translating the dis files is proving to be an onerous task, as the addresses are encoded in the instruction offsets. I can translate the data structures in the dis now.

hmm. i run infernos on my x64 linux/windows and android systems.. they work. may you describe what you mean? addresses offset itself is no problem on  x64 system. maybe a memory accessible by limbo will be shorter, but you may expand it with C modules.

i didn't understand very deeply in the format of dis-modules since there were no complaints about their interpretation (jit-compiler is a little outdated, but i'm quite happy with the speed of interpretation). could you show what you mean?

суббота, 16 января 2021 г. в 01:30:23 UTC+3, Go Phone:

[hiro]

> the stack size in
> small devices is very limited, and there are no memory protection

i would make the opposite conclusion. to me this is a great reason to
use inferno on embedded devices: limbo seems like a perfect solution
for platforms without memory protection.

[Charles Forsyth]

hmm. i run infernos on my x64 linux/windows and android systems.

The catch is that the time when you can do that is coming to an end. When doing the amd64 Plan 9 port we somewhat anticipated that 14 years ago:

we made Plan 9 treat it as a new 64-bit architecture, not an extended version of the 386. I did keep "int" and "long" as 32 bits, with 64-bit pointers (hence uintptr, originally "uptrint")

because a week trying to live with int as 32 bits and long as 64 bits produced a week of pain, discovering all manner of subtle assumptions about masks and shifting (for instance, there was more).

By contrast, with int and long as 32 bits, the compiler could easily diagnose attempts to assign between them and any pointer type, so the system was then quickly ported.

Anyway, 64-bit operating systems including Windows, Linux and MacOSX are discarding the 32-bit interfaces, even when they took a different original route.

For Inferno, that means that compiling in the equivalent of -m32 is rapidly failing. What to do? The bulk of the Inferno kernel and libraries can be changed, just like Plan 9, to compiler and run in

a 64-bit environment, but with less effort since much of the work on libraries and in the kernel was done for Plan 9 and at least some of that is already in Inferno.

Dis is the problem. It is inherently 32-bit: the size of pointers as 32-bits is built into offsets computed at compile time,

and it also assumes that only 32-bit alignment being needed for pointers. Some of those pointers in the "runtime", as I think was noted for Strings, are well-known to libinterp.

There's also an assumption in the Dis interpreter that it can cast a Dis WORD to (say) a T** and get a T* by indirection, which won't work. Some of those point to run-time structures.

There are a few possibilities:

1. find all the places where T** is used that way in libinterp and dis.c/emu.c etc, and change each instance so it fetches a 32-bit value and converts that to a 64-bit pointer, which requires that all pointers and stack references lie within a 32-bit address space at run-time (eg, by deliberately allocating them there, but beware that it's subtle for stack addresses).
2. maybe easier: create a new Dis64 by changing the Limbo compilers to use 64 bits for pointers (refs), which requires mainly changes to the limbo compilers themselves not only to use 64 bits for Refs (easy) but also to calculate the right offsets in data structures shared with the run-time system (eg, for alt) which is tedious but probably not too hard. Downside is that Dis64 and DIs(32) are incompatible (which doesn't matter to many)
3. hard: replace Dis by another representation that can keep the portability across architectures and also generate native machine code from the start.

I poked at (1) for a bit and started looking at (2). My real goal is (3) at some stage, which I considered in detail 8 years ago, but either (1) or (2) are needed until (3) can be done.

--
You received this message because you are subscribed to the Google Groups "inferno-os" group.
To unsubscribe from this group and stop receiving emails from it, send an email to inferno-os+...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/inferno-os/34b79b06-8085-4085-80c0-49ebbdf158fen%40googlegroups.com.

[Ethan Gardener]

It depends what you call "small". :) I'm with hiro here. I can imagine some tiny devices have a limited stack, but in the vast range of devices too limited for a modern OS, I'm sure there are many which could run Inferno. I've been looking at STM32F7 SoCs. They're embedded devices without a full MMU, but they're much more powerful than the systems Inferno was originally designed to run on. They even have instruction and data caches.

[Go Phone]

There are a few possibilities:

1. find all the places where T** is used that way in libinterp and dis.c/emu.c etc, and change each instance so it fetches a 32-bit value and converts that to a 64-bit pointer, which requires that all pointers and stack references lie within a 32-bit address space at run-time (eg, by deliberately allocating them there, but beware that it's subtle for stack addresses).
2. maybe easier: create a new Dis64 by changing the Limbo compilers to use 64 bits for pointers (refs), which requires mainly changes to the limbo compilers themselves not only to use 64 bits for Refs (easy) but also to calculate the right offsets in data structures shared with the run-time system (eg, for alt) which is tedious but probably not too hard. Downside is that Dis64 and DIs(32) are incompatible (which doesn't matter to many)
3. hard: replace Dis by another representation that can keep the portability across architectures and also generate native machine code from the start.

I poked at (1) for a bit and started looking at (2). My real goal is (3) at some stage, which I considered in detail 8 years ago, but either (1) or (2) are needed until (3) can be done.

Are there any acid libraries for showing the loaded modules (in the memory of the inferno process)?

[fy rgjut]

@hiro @Ethan Gardener

> this is a great reason to use inferno on embedded devices

i would also like to see inferno as a platform for small devices.  but for this it needs:

1) it must work on the basis of FreeRTOS (or have external system functions, interface-adapters for filling with real functions of the desired OS).

2) inferno has a lot of assembler and processor- and OS-dependent places.  they should be replaced with universal to hardware/OS code.  even if they are a little worse.  (stm32f7 is not popular as a platform for iot. high price and lack of wireless interfaces make them uncompetitive).

3) inferno should support SPIFFS/littleFS or has a configurable FS interface. 

4) inferno should has simply way to change fisical media/basic protocol to interchange with external world by 9p (WiFi, bluetooth, uart, i2c, spi etc)

5) jit compiler only takes the the place. it don't support for example esp32 and in future risc-V. i think riscV will be the most popular IoT platform in future.

it has other necessary things like

void fooo(int some_params) {

...

   char buff[ 100 ]; <-- buffers as local variables are very dangerous in embedded systems. they should be malloced

...

..or good GUI system for embedded terminals. with Tk bell labs was wrong.

but all these possible. these only need programmers who want to do. as for me alone i have too little free time. i ported 9p driver to lua as lua is highly and easy portable and embedable.

also i tryed to port full inferno OS to freeRTOS/SPIFFS. buut i have too low time to this.

today inferno is not ready to run on IoT device. and have no future on Mac (and other todays desktop) because of very not good look of its GUI.

so is here someone who want and will do inferno ready to be IoT OS?

воскресенье, 17 января 2021 г. в 16:35:25 UTC+3, 23h...@gmail.com:

[hiro]

that's a very long todo list.

i'm not sure all the points are warranted, I'm missing most of the reasoning.
also remember: fashion changes very fast. risc-VI anyone? safe-VII ?

what is the overlap with rtos, i don't understand? if you want rtos
why play with inferno at all? i prefer inferno precisely bec. i'd like
to avoid rtos

IoT is anyway just marketing, you can find "IoT" amd64 boxes nowadays,
and what have you. use a more specific term perhaps?

GUI is just subjective, i think it's better to start with something
functional and make it pretty later than the other way around. tk
works just fine, and it's well integrated into limbo.

if you want to program a website with pretty animations and webgl GUI,
there's no need to call it iot.

> --
> You received this message because you are subscribed to the Google Groups
> "inferno-os" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to inferno-os+...@googlegroups.com.
> To view this discussion on the web, visit

> https://groups.google.com/d/msgid/inferno-os/2920a796-1a14-4f6a-ad59-62a37143cd12n%40googlegroups.com.
>

[da...@boddie.org.uk]

On Wednesday, 20 January 2021, fy rgjut wrote:

@hiro @Ethan Gardener

5) jit compiler only takes the the place. it don't support for example esp32 and in future risc-V. i think riscV will be the most popular IoT platform in future.

At least there is support for RISC-V in the toolchain now, which is a start:

https://bitbucket.org/inferno-os/inferno-os/pull-requests/8/add-toolchain-and-libmach-support-for

I realise that adding JIT support for a new architecture is an adventure in itself for novices like myself.

[clasp126...@icebubble.org]

Go Phone <gopho...@gmail.com> writes:

> Are there any acid libraries for showing the loaded modules (in the memory
> of the inferno process)?

acid? I know that Inferno has a graphical debugger, wm/deb. You might
be able to use it over 9P from another instance of emu.

[clasp126...@icebubble.org]

hiro <23h...@gmail.com> writes:

> i'm not sure all the points are warranted, I'm missing most of the reasoning.
> also remember: fashion changes very fast. risc-VI anyone? safe-VII ?
>
> what is the overlap with rtos, i don't understand? if you want rtos
> why play with inferno at all? i prefer inferno precisely bec. i'd like
> to avoid rtos

fy rgjut's message is a bit hard to understand, but I think he/she's
suggesting porting the Inferno kernel to (some/any) standard, well-
supported framework for embedded systems. That way, any platform
supported by the framework would automatically be supported by Inferno.

I once mused about the idea of porting Inferno to something like the
Mach microkernel. That way, Inferno could be run natively on any
hardware that could run Mach.

It saves having to spin a new port (or modify an existing port) each
time a new architecture or variant comes out.

[Oleksandr Iakovliev]

If you guys want Inferno OS in the IoT world then you probably need to get it up and running on Raspberry Picos :) as very first point

https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-now-on-sale/

четверг, 21 января 2021 г. в 04:24:45 UTC+1, clasp126...@icebubble.org:

[Ethan Gardener]

On Wed, Jan 20, 2021, at 2:00 PM, fy rgjut wrote:
> @hiro @Ethan Gardener
>
> > this is a great reason to use inferno on embedded devices
>
> i would also like to see inferno as a platform for small devices. but for this it needs:
>
> 1) it must work on the basis of FreeRTOS (or have external system functions, interface-adapters for filling with real functions of the desired OS).

I hope the porting work gets easier or someone joins you in it. :)

> 2) inferno has a lot of assembler and processor- and OS-dependent places. they should be replaced with universal to hardware/OS code. even if they are a little worse. (stm32f7 is not popular as a platform for iot. high price and lack of wireless interfaces make them uncompetitive).

Thanks for the note on stm32f7. I might look around for another device, but for what I want stm32f7 seems about right.

> 3) inferno should support SPIFFS/littleFS or has a configurable FS interface.

So... you need a bridge too? Inferno has had filesystem bridges before. Op for example.

> 4) inferno should has simply way to change fisical media/basic protocol to interchange with external world by 9p (WiFi, bluetooth, uart, i2c, spi etc)

If Inferno's dial strings are like Plan 9's, (I think they are,) then the "simple way" exists; it just needs some drivers. A full Plan 9 dial string may be 'tcp!foo.net!8643', or formerly 'il!foo.net!8643' to use Plan 9's own replacement for tcp. It's a flexible syntax. The first part, the protocol, may imply other parts. For example, 'http!bar.com' is the same as 'tcp!bar.com!80'. I'm sure drivers could be written so that you could use dial strings like 'uart!0' or 'spi!3'.

> 5) jit compiler only takes the the place. it don't support for example esp32 and in future risc-V. i think riscV will be the most popular IoT platform in future.

Sounds like programmers are needed... except riscv is done? idk

> it has other necessary things like
>
> void fooo(int some_params) {
> ...
> char buff[ 100 ]; <-- buffers as local variables are very dangerous in embedded systems. they should be malloced
> ...

I assume you're concerned about stack smashing? It's good to think of that, but it could be avoided if the code makes sure never to over-fill the buffer. In fact, code should always make sure never to overfill the buffer and not rely on the uncertain security of just putting the buffer somewhere else.

> ..or good GUI system for embedded terminals. with Tk bell labs was wrong.

Tk was an excellent choice at the time - the 90s - and still has good points. It's very easy to work with, as traditional toolkits go. I'm almost sure you could make a full mobile-style UI with it; I was impressed with the flexibility of its packers (layout tools). You can build widgets out of the (extremely powerful) canvas widget to replace buttons and things.

> but all these possible. these only need programmers who want to do. as for me alone i have too little free time. i ported 9p driver to lua as lua is highly and easy portable and embedable.
> also i tryed to port full inferno OS to freeRTOS/SPIFFS. buut i have too low time to this.

Good stuff. Limited time is everyone's enemy, except for ones like me who have limited energy and focus instead.

> today inferno is not ready to run on IoT device. and have no future on Mac (and other todays desktop) because of very not good look of its GUI.

Have you seen bhgv's inferno for Android? (Should also build on other systems.) It's not a complete change of look, but some details are changed.

> so is here someone who want and will do inferno ready to be IoT OS?

Oh I'd help with lots of projects if I could, but I'm struggling with my own stuff. Sorry. ;)