I am still trying to get a working 9front setup so I can work on the port. We used Shawn's setup; I am not there yet.
The workflow was as follows: On a Linux machine, QEMU is set up, and another machine running 9front with Acme et al serves 9p. Editing and recompiling in 9front and then (re)running in QEMU works fine that way, but debugging was tedious. On the Linux machine, we stepped through instructions via gdb, and had to reverse lookup the corresponding function. With acid on 9front, we could see the counterpart and come to conclusions. Not ideal, but a start. So I have done a few related things now to help along: - https://github.com/platform-system-interface/p9aout2elf a tool to convert Plan 9 a.out to ELF (*with* symbols!); so far amd64 only, I'm working on RISC-V 64 - https://github.com/radareorg/radare2/pull/24261 WIP support for Plan 9 RISC-V kernels in radare2 Those tools significantly help with debugging, so one gets to see the symbols in gdb and radare2. On Sun, Jun 1, 2025 at 7:43 AM ron minnich <[email protected]> wrote: > charles, you may remember the little toy kernels jmk built for the blue > gene ports ... very handy. Made it easy to get all kinds of things right. > > This is a useful technique in general for ports. > > On Sat, May 31, 2025 at 7:39 PM Charles Forsyth <[email protected]> > wrote: > >> on various RISC targets, data is addressed by offset from a "static >> base" register, REGSB >> in the ?.out.h. the data is shuffled to put smaller items at the start of >> the area that REGSB can map. >> if the processor allows efficient negative offsets from register, the SB >> register typically points into the middle >> of the data, and data items can have negative offsets from SB. the value >> must be set at startup, both kernel and user mode, using a special >> sequence: >> >> MOV/MOVW/MOVD $setSB(SB), Rn >> >> where n is REGSB. see libc/*/main9.s for examples. >> the loader recognises setSB(SB) as being the start-of-data or >> middle-of-data value needed and builds >> an instruction sequence that will initialise Rn accordingly. >> >> On Sat, 31 May 2025 at 18:48, Daniel Maslowski via 9fans <[email protected]> >> wrote: >> >>> The print we managed to do was a uartputs, as I just remembered, not >>> print() just yet. >>> No idea how we would wire up the uartputs with the panic function though. >>> >>> Regarding the actual issue, Moody suggested something about setSB >>> (static base). >>> I have not been able to read up much on it and we called it a day then >>> just by midnight. >>> >>> On Fri, May 30, 2025 at 5:49 PM Ron Minnich <[email protected]> wrote: >>> >>>> I left out a few details ... you needed a panic that could put a >>>> string before print was ready. But you've written the code already ... >>>> >>>> so it was data segment alignment? That was my guess at the time. >>>> >>>> On Fri, May 30, 2025 at 4:15 AM Daniel Maslowski via 9fans >>>> <[email protected]> wrote: >>>> > >>>> > The problem we had was that print hadn't even worked yet, and as we >>>> figured, due to data/text shenanigans. >>>> > A print("hello"); would fail, but a `static char asdf[] = "asdf"; >>>> print(asdf);` would work. (notation might be wrong here, sorry, I'm not >>>> that into C...) >>>> > >>>> > Ron, how would that panic become visible? If the test fails, I would >>>> need to be able to see its result. >>>> > >>>> > On Fri, May 30, 2025 at 6:54 AM Charles Forsyth < >>>> [email protected]> wrote: >>>> >> >>>> >> copy attached >>>> >> uncluttered by extensions >>>> >> apparently ken thompson did the C version for unix (i just added the >>>> types), >>>> >> which makes it an appropriate test for a new compiler and then >>>> kernel port. >>>> >> >>>> >> >>>> >> On Thu, 29 May 2025 at 22:35, Charles Forsyth < >>>> [email protected]> wrote: >>>> >>> >>>> >>> that reminds me that the first kernel-level program i ran on new >>>> ports was wump (hunt the wumpus), >>>> >>> partly to debug similar effects, but also because it's fun if not >>>> just silly >>>> >>> >>>> >>> On Thu, 29 May 2025 at 22:05, Ron Minnich <[email protected]> wrote: >>>> >>>> >>>> >>>> Daniel and Shawn made good progress on the risc-v port, and their >>>> >>>> experience reminded me of a standard test I used to use while doing >>>> >>>> ports. >>>> >>>> >>>> >>>> long story short, for blue gene and other ports (early amd64) we >>>> added >>>> >>>> this test in main >>>> >>>> >>>> >>>> ulong x = 0x12345678; >>>> >>>> >>>> >>>> main() >>>> >>>> { >>>> >>>> if (x != 0x12345678) panic("unaligned data"): >>>> >>>> >>>> >>>> ... >>>> >>>> >>>> >>>> how can this test fail? x is in the data segment, but the >>>> immediate in >>>> >>>> the test is in the text segment. This test is a quick and easy way >>>> to >>>> >>>> check if your data segment is correctly loaded in memory. >>>> >>>> >>>> >>>> In some ports, the data is aligned by code in l.s that moves it. >>>> >>>> >>>> >>>> There are some really nasty, confusing errors that will arise in a >>>> >>>> seemingly working kernel if data is not aligned. >>>> >>>> >>>> >>>> I always add this test when I'm doing a port. It catches a problem >>>> >>>> that is otherwise very confusing, and presents as strings not set >>>> up >>>> >>>> right, variables wrong, etc. >>>> > >>>> > 9fans / 9fans / see discussions + participants + delivery options >>>> Permalink >>> *9fans <https://9fans.topicbox.com/latest>* / 9fans / see discussions > <https://9fans.topicbox.com/groups/9fans> + participants > <https://9fans.topicbox.com/groups/9fans/members> + delivery options > <https://9fans.topicbox.com/groups/9fans/subscription> Permalink > <https://9fans.topicbox.com/groups/9fans/T2fa5d9bbce09411d-Mba06f201e825e33e056aca03> > ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T2fa5d9bbce09411d-M9e8b87746a157e7c3699e0bb Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
