IRC channel logs

<stikonas>rickmasters: not sure if you saw but most people here suggested that you wouldn't spend time getting fiwix hard disk working if it's not fun

<stikonas>we'll just try to fit withing limits

<aggi>weird ... // ticks = jiffies; while (ticks == jiffies);

<aggi>how could i have missed this? stupid me.

<aggi>it isn't the only problem however

<aggi>well, i inserted an asm nop instead... then it passes beyond the delay loop, and crashes as usual elsewhere

<aggi>depends, if apic support is present, or not, when it crashes

<aggi>and what should this do other than blocking indefinitely... while (ticks == jiffies); ???

<aggi>anyway... there is something else, fundementally wrong and it seems related to interrupt handling

<aggi>i'll try another day or two... and then see to fiwix kernel instead

<lilyp>could it be that either ticks or jiffies is meant to be volatile?

<muurkha>presumably jiffies is the volatile counter of how many jiffies have passed since kernel boot? I forget how Linux works

<aggi>who knows, the problem is the malfunctioning interrupting handling...

<aggi>and some peculiarities with extern inline definitions, which causes duplicate definition warnings with tcc, and depending on how this is coped with missing symbols with gcc-4.7

<aggi>i'll expand the related macros in i8259.c to see what is going on

<avih>when aggi shows up, someone point him please to https://bellard.org/tcc/tccboot-0.1.tar.gz , specifically the file linux-2.4.26-tcc.patch inside, which seem to patch the kernel around the areas he had problems with (interrupts, asm, etc).

<avih>also, the README https://bellard.org/tcc/tccboot_readme.html seem informative, describes the process, and also addresses some of the issues related to interrupts and asm

<oriansj>gforce_de1977: also one on my backlog along with the Commander X16.

<oriansj>muurkha: well it certainly shifts most of the hardware design into software where changes becomemuch easier to do; as the Transmeta work clearly showed, it has excellent design potential as it wasoneof the few platforms which one could fix defects rather than being forced to patch around buggy hardware.

<oriansj>but I am partial to minimal -> no microcode processors;

<oriansj>and if I wasn't sure, I'd stick to FPGAs until I slowly firm up my ideas. Which is surprisingly hard in the hardware space.

<oriansj>and the most frustrating bit is knowing that there are probably good design secrets out there that you want before you begin.

<muurkha>yeah, my4th definitely doesn't qualify as "minimal to no microcode" :)

<rickmasters>stikonas: thanks, yes, I've seen the messages regarding Fiwix and hard drive.

<rickmasters>stikonas: I did make some progress but I've moved back to using a ram drive for the time being.

<rickmasters>I'm working on an updated PR which may be available today.

<rickmasters>I also spent some time on patches that allow running live-bootstrap from the start using Fiwix, with either ram drive or hard drive.

<rickmasters>Those patches allow for easier testing of different Fiwix kernel builds and switching between ram drive and hard drive.

<rickmasters>With that I'm hoping Mikaku can take a look at the hard drive issues. Mikaku: I'll open an Issue for that soon.

<rickmasters>Mikaku: I've been able to determine that hard drive requests are timing out on Fiwix when running live-bootstrap with qemu.

<rickmasters>Mikaku: The failure rates are greatly affected by changing the WAIT_FOR_DISK definition. I'll provide the details in an Issue I'll file soon.

<Mikaku>rickmasters: ok, I'll be glad to read new issues on this subject

<Mikaku>rickmasters: as I said before, I rebuild several times per week all the FiwixOS packages and I only experience one or two disk timeouts that doesn't affect the whole process

<Mikaku>rebuilding all FiwixOS packages takes more than an hour and has a heavy disk and filesystem use. Sincerely having only a pair of disk timeouts is enough stable for me right now

<Mikaku>rickmasters: in the other hand, I'm finishing the kexec functionality in Fiwix. It doesn't use a system call like in the Linux, so there is no need of userland programs. In fact, I was unable to port to Fiwix the 'kexec-tools' from Linux and that's the reason why the kexec mechanism in Fiwix is different than in Linux

<Mikaku>I'm using Multiboot1 protocol so far, and the Fiwix kernel boots successfully. Once the kexec be integrated completely in the kernel, the next step will be to include support to be able to kexec the Linux kernel which I presume it needs some special tweaks

<Mikaku>having the kexec already working in Fiwix will accelerate things and will make path easier to include support to kexec Linux

<stikonas[m]>It doesn't have to be the same syscall

<Mikaku>stikonas[m]: yes, but having a system call implies having a userland program like in 'kexec-tools'. Since I was unable to port such package because it's too Linux dependent, I decided to take a different path

<stikonas[m]>Yes, I mean mechanism is up to you

<stikonas[m]>In the worst case we could just do full reboot, but that would drop us back to BIOS, so harder to ensure that we'll boot successfully

<stikonas[m]>E.g. if boot order is changed

<Mikaku>yes, I'm aware of the importance of kexec in this project

<Mikaku>that's why I wanted to include such support in Fiwix

<stikonas[m]>But the mechanism is entirely up to you

<Mikaku>so far, I can kexec the Fiwix kernel successfully with almost no effort

<stikonas[m]>E.g. builder-hex0 also doesn't use kexec

<aggi>narrowed down further why/how kernel-2.4 compiled with tcc crashes ... include/asm-i386/current.h

<avih><avih> when aggi shows up, someone point him please to https://bellard.org/tcc/tccboot-0.1.tar.gz , specifically the file linux-2.4.26-tcc.patch inside, which seem to patch the kernel around the areas he had problems with (interrupts, asm, etc).

<avih><avih> also, the README https://bellard.org/tcc/tccboot_readme.html seem informative, describes the process, and also addresses some of the issues related to interrupts and asm

<aggi>kernel/exit.c:do_exit() ... thats the place, which calls task_struct * get_current(void)

<aggi>this obviously points to some gibberish causing -> panic("Attempted to kill the idle task!");

<aggi>when this happens, depends on the kernel-config used (with or without apic.c involved); but it does happen in any case

<aggi>the get_current task call, is some asm

<aggi>the whole process call-flow is just not clarified upon... if the task_struct wasn't correctly saved before, an isr not processed correctly

<aggi>in any case... do_exit() on an errornously initialized task/context is causing the panic()

<aggi>anyhow; what i don't understand is, how the original tccboot.iso could ever have compiled/booted correctly with any tcc-compiler version involved

<aggi>as a consequence, i don't have a reliably identified _baseline_ for kernel/compiler-version to diff/bisect against

<aggi>besides; linux-2.4.26 (bellard), and linux-2.4.37.11 (seyko2) show the _same_ problem

<aggi>2.3.37-11-seyko2 just gets stuck in the delay calibration loop, that's why the do_exit() panic() isn't arrived at without some hacks (altering kconfig or skipping the delay loop calibration)

<aggi>and i can't rule-out, the whole interrupt setup/handling has a problem - it's a nasty side-effect/symptom

<avih>aggi: did you see my links above?

<avih>can anyone read this?

<aggi>avih: yes of cause

<avih>k, so the patch doesn't makes things better?

<aggi>the patch doesn't suffice, nor any tcc-version or compiler-version tested... same problem remains

<avih>k

<aggi>linux-2.4.37-seyko2 already contains all patches, and some other extras

<aggi>i checked all kernel/compiler-versions, diffed all patches, debugged

<aggi>the conclusio with regards to this: tccboot.iso from Bellard may not have worked with any of the publicly available sources

<avih>why not just ask him them?

<avih>surely he knows better than anyone else...

<avih>unless you think that figuring this on your own has good value to you...

<aggi>avih: because i do not know, how to summarize this comprehensively

<aggi>because, i don't have a reliably identified _baseline_ for kernel/compiler-version to diff/bisect against

<avih>you can still describe what you tried and why, together with your results.

<avih>hmm.. looks like the tcc maintainer is considering a new release...

<avih>(current maintainer, not bellard)

<aggi>avih: i am willing to publish the test-setup some place

<aggi>for quick-starting this... it was a notable amount of work, to review and tinify a kconfig, testing all variants and combinations of tcc/gcc preprocessing/compiling/linking in separate stages

<aggi>to keep it as simple as possible

<aggi>the patchset too required cleanup for simplicity

<aggi>and i think 2.4.37.11 kernel may be used instead of the older version, because the bug/problem is the same with each

<avih>right, in the email so you can describe briefly what you tried and why, and conclude that you couldn't find a combination of kernel/tcc/patches which work together and end up in a bootable system. you can provide more details if he requests (or link to a page with more details, if you have one). and maybe that would be enough. maybe he has some sources stached someplace unpublished. maybe he'll recall some hack which needs to be applied and is not at

<avih>the public sources, etc.

<aggi>i think, i must have missed something trivial

<avih>he's still very much interested in linux boot, and afaik his most (not very) recent related project is (the amazing) jslinux

<avih>if you missed something trivial, it would be even easier for him to get you back on track ;)

<aggi>meanwhile, i gave Fiwix a try with tcc-compiler too... no luck, this requires extensive review and some patching too

<aggi>the timer interrupt seems to not fire-up and/or not initialized correctly before too... although this doesn't crash the system, the calibration loop later is stuck

<aggi>and the do_exit panic() too may seem a secondary symptom of interrupt/contexts not configured

<aggi>arch/i386/kernel/entry.S ...

<aggi>i'll dump the asm .S files into binutils-as, instead of i386-tcc... and see what happens

<stikonas>aggi: have you checked rickmasters scripts

<stikonas>he was able to build fiwix using tcc

<rickmasters>aggi: this branch of Fiwix builds with tcc: https://github.com/rick-masters/Fiwix/tree/fiwix-1.4.0-lb1

<rickmasters>Set CCEXE=tcc in the Makefile

<rickmasters>aggi: sorry, forgot to mention you need a small patch to tcc - just two lines

<aggi>rickmasters: thanks for the notice

<rickmasters>aggi: in tccelf.c, after the line "ph->p_paddr = ph->p_vaddr;" add these lines:

<rickmasters> if (ph->p_paddr >= 0xC0000000)

<rickmasters> ph->p_paddr = ph->p_paddr - 0xC0000000;

<aggi>rickmasters: interesting

<aggi>is it several spots which this had to be added to?

<rickmasters>aggi: no just the one spot

<aggi>there is two candidates fill_phdr() and layout_sections()

<rickmasters>sorry, you're right, its the one in layout_sections()

<aggi>ok

<aggi>rickmasters: i don't want to waste your time

<rickmasters>That patch does the same thing as Fiwix's gcc linker script: https://github.com/rick-masters/Fiwix/blob/fiwix-1.4.0-lb1/fiwix.ld

<aggi>it's just, i suspect a similar issue with linux-2.4/tcc; adress-translations and layout having issues (when testing a combination of compiling-linking with tcc and gcc)

<aggi>rickmasters: yes, gcc-linker for kernel too utilizes a linker script, while tcc just sets the base-address

<rickmasters>Right, and Fiwix uses different physical than virtual so the two-line patch sets the physical address appropriately in the elf headers

<aggi>i recall, susematz (testing tcc with linux-4.6), too mentioned some issue while linking the kernel with tcc

<aggi>anyway

<aggi>there was notable changes in tcc related to this tiny diff

<aggi>hence i would be curious, to which tcc-version the patch had to be applied

<aggi>quickly patched tcc-compiler with the proposal, re-compiled linux-2.4.37.11 with it... crash

<aggi>there's a principle issue, the adress-mappings and translations, in conjunction with linking and layouts, is indeterministic with tcc-compiler/linker - with the test-setup described, compiling linux AoT with tcc-toolchain

<aggi>amdmitted, i didn't know what i was doing whan testing the patch, i doubt anyone else knew with certainty

<gforce_de1977>@oriansj: the Commander X16 looks great! (and i just caught myself thinking about bootstrapping GCC a 6502-path on this machine with 2MB RAM 8-)))) https://cx16forum.github.io/faq.html

<gforce_de1977>@oriansj but ofcourse this is also possible with a REU https://en.wikipedia.org/wiki/Commodore_REU and 16MB RAM 8-) with an original Commodore 64

<oriansj>gforce_de1977: well with 8MB, you should be able to bootstrap to M2-Planet without much trouble

<oriansj>Mescc and TCC on a 6502 however would require a good deal of work.

<stikonas[m]>You would still need to optimise cc and M2-Planet

<stikonas[m]>They need well over 8 MiB right now

<stikonas[m]>Probably just in stack usage we are close to 8

<gforce_de1977>the biggest dealbreaker is, that you have to bankswitch 64k - it is not really continuous memory - but lets keep the dream, maybe sometimes somebody will do it...lets concentrate on Motorola 68000 first 8-)

<rickmasters>Mikaku: I have finally filed an Issue for the Fiwix hard drive problem: https://github.com/mikaku/Fiwix/issues/27

<rickmasters>Mikaku: Sorry for the delay but I had to prepare forks to make it somewhat easy for you to reproduce with somewhat recent Fiwix code.

<Mikaku>rickmasters: ok, I'll take a look

<rickmasters>Mikaku: thanks

<Mikaku>rickmasters: I followed the steps in the issue #27 but when I execute the last step it prompts with:

<Mikaku>Bootstrapping x86 -- SysA

<Mikaku>[sudo] password for mikaku:

<Mikaku>after typing the password, I get: Bootstrapping failed

<Mikaku>I don't use 'sudo' in my system at all, I'm from the old school and I still use 'su -' when I need too :-)

<Mikaku>s/too/root/

<rickmasters>Ok, I just assumed you'd have that working - I believe live-bootstrap depends on sudo: https://github.com/fosslinux/live-bootstrap/issues/123

<rickmasters>Give me a few minutes and I'll see what I can do

<Mikaku>ok

<rickmasters>I know it's not ideal but could you do su and then run it?

<rickmasters>If so, then I could tell you how to remove the sudo before the commands

<Mikaku>rickmasters: ok, let me see

<rickmasters>See, it runs mount -t ext2 and that requires root I think

<Mikaku>now it runs and it is downloading a lot of packages

<Mikaku>but it does it in my local disk, not in a virtual disk

<Mikaku>is this correct?

<stikonas>Mikaku: yes, it will first download to local cache

<stikonas>and then creates virtual disk out of it

<Mikaku>stikonas: I see, thanks

<stikonas>(if you are in qemu mode)

<stikonas>which is the mode where kernel is needed

<Mikaku>well, you are using QEMU in a way I've never used before

<stikonas>we do have other modes, e.g. chroot or bwrap mode but those are entirely userspace

<stikonas>oh, how is it different?

<stikonas>I think fossy set it up initially

<stikonas>but I thought it's fairly standard

<Mikaku>I just run 'qemu-system-i386' ...

<rickmasters>that's what the fiwix qemu scripts use

<rickmasters>see bootfiwix-rd and bootfiwix-hd

<rickmasters>It will probably help to get familiar with those scripts. You could modify them to save the file system and then later just run those scripts

<Mikaku>yes, I see it now, thanks

<Mikaku>hmm, it stopped

<Mikaku>ioctl(KVM_CREATE_VM) failed: 16 Device or resource busy

<Mikaku>qemu-system-i386: failed to initialize kvm: Device or resource busy

<Mikaku>Detaching /dev/loop0

<Mikaku>Removing /home/mikaku/github/live-bootstrap/tmp

<Mikaku>(sorry for pasting these lines here)

<Mikaku>I can use a pastebin service

<Mikaku>these error messages appear right after creating a filesystem with mke2fs

<rickmasters>That sounds like a failure of qemu -enable-kvm

<rickmasters>Have you used -enable-kvm with qemu on that machine before?

<Mikaku>of course, every day :-)

<stikonas>hmm, we can use more than 1 KVM client per host, can't we

<Mikaku>I've VirtualBox running FiwixOS building some packages, do you think this could be a problem?

<stikonas>hmm, I thought it shouldn't matter

<Mikaku>yep

<stikonas>at least with qemu you can create multiple VMs

<stikonas>but I have never tried simultaneously using different hypervisors

<Mikaku>let me stop VirtualBox and try it again ...

<rickmasters>The "internet" seemms to think that running VB is the most common reason for that error

<Mikaku>it seems to work this time :-)

<rickmasters> https://bugzilla.redhat.com/show_bug.cgi?id=1277744

<Mikaku>rickmasters: you mean I'm bugged here? :-)

<Mikaku>nice

<Mikaku>well, I see a lot of lines like if some packages are being built

<stikonas>early packages are stage0-posix, those are reasonably fast steps, later mes/mescc starts building libc/itself/tcc. Those are fairly slow steps

<stikonas>(because mes is an interpreter)

<Mikaku>who is building these packages, host or guest?

<stikonas>guest

<stikonas>host is not building anything

<stikonas>(only creates a disk image with sources)

<Mikaku>ok, thanks

<Mikaku>is there a way to login to the guest system using the serial device?

<stikonas>I don't think so

<stikonas>and only towards the end of sysa we get an interactive bash

<stikonas>you could probably hack some steps, inject some other shell from the host (maybe busybox?)

<stikonas>unfortunately qemu mode is the hardest to debug :(

<rickmasters>Mikaku: with significant work one could probably run live-bootstrap on top of FiwixOS

<stikonas>well, in the late stages of the process things are in disk and we also have interactive bash with traps

<stikonas>rickmasters: do we actually need significant work?

<stikonas>what changes on fiwix os?

<stikonas>I guess we need chroot?

<stikonas>but that seems to be supported

<rickmasters>stikonas: I'm not sure, it could probably run as a normal process

<Mikaku>stikonas: chroot is supported but not much tested it

<stikonas>maybe chroot mode would trigger similar issues

<stikonas>I see...

<stikonas>well, bwrap more would not work, I don't think you support user namespaces

<stikonas>but chroot might be worth trying

<stikonas>might be easier to debug it then qemu mode

<stikonas>well, rootfs.py also needs python but it's not hard to create a disk image manually

<stikonas>it's mostly getting two git repos and downloading source tarballs from internet

<rickmasters>stikonas: if it runs as a normal process I think it would eventually start overwriting FiwixOS executables but if the system is disposable maybe its not a problem

<stikonas>oh you mean completely in the system

<stikonas>without any chroot

<rickmasters>right

<stikonas>that could work too in a disposable system

<stikonas>so chroot wouldn't be necessary then

<Mikaku>rickmasters: for the disk drives I use the QEMU line: '-drive file=hda.img,format=raw,if=ide,cache=writeback,index=0'

<rickmasters>I can try that for sure

<Mikaku>ah, I see that writeback is the default cache

<stikonas>so it's mostly a normal drive then

<Mikaku>according qemu manpage, yes

<Mikaku>"The default mode is cache=writeback."

<Mikaku>is there a way to have a separate terminal to see only the kernel messages? I mean, with all the lines scrolling so faster is impossible to see if there was a kernel message in the middle

<Mikaku>(sorry for all those newbie questions)

<Mikaku>I normally use a separate ttyS1 for kernel messages to not miss anything

<Mikaku>specially when building a lot of packages and the screen scrolls so fast

<rickmasters>Mikaku: can that be specified with a kernel option?

<Mikaku>console=/dev/ttyS1

<Mikaku>oh, I see

<Mikaku>you are already using console=/dev/ttyS0

<Mikaku>but the way how QEMU is being used all messages are displayed together in the same terminal

<rickmasters>Mikaku: we run live-bootstrap in text mode so there is no graphics console to work with

<Mikaku>well, "Page Fault at 0x00000000 (reading) with error code 0x00000004 (0b100)"

<Mikaku>Process '/usr/bin/make' with pid 16

<rickmasters>Mikaku: I believe I've seen it fail that way

<Mikaku>yes, this will be hard to debug

<Mikaku>it happened while building binutils-2.30

<rickmasters>Mikaku: Yes, it's difficult because it fails in so many different ways

<aggi>rickmasters: tried the tcc-patch quickly

<aggi>which version of tcc was used with it in your test-setup?

<rickmasters>It was the 0.9.27 release - not the latest mob

<aggi>ok

<Mikaku>rickmasters: yes, it looks like after some heavy use the kernel is choosing an incorrect buffer (from the cache) for a specific block

<rickmasters>Mikaku: I'm curious how you figured that out so quickly

<Mikaku>I'm not completely sure, but a possible cause is that since that page-fault was in user-mode (in 'eip: 0x08078057'), this belongs to the .text section of '/usr/bin/make'. So, the original page that was loaded from the disk during the normal page-demand execution was probably changed erroneously by the contents of another page (from a buffer)

<Mikaku>this is a long-standing bug that happens from time to time during a heavy kernel use

<Mikaku>I have been living with this bug because it not happens really often, but it appears from time to time indeed

<rickmasters>Mikaku: ok, I was speculating that there was a disk timeout on the page-demand and so the executable was not populated

<rickmasters>Mikaku: ... mainly because I saw better behavior with a higher WAIT_FOR_DISK timeout but I also increased MAX_IDE_ERR but I was just guessing

<Mikaku>hmm

<Mikaku>I don't see they are related with that page fault

<Mikaku>if I could re-run this /usr/bin/make again it probably succeed

<Mikaku>but I don't even know how to exit from this QEMU mode, d'oh

<rickmasters>Ok. Maybe there is more than one problem.

<rickmasters>Ctrl-a then x

<Mikaku>nope, it doesn't work

<Mikaku>I'd prefer not use kill but ...

<rickmasters>Ok pushing the keys harder might work (april fools)

<Mikaku>haha

<rickmasters>I've had to use kill from time to time

<stikonas[m]>Strange C-a x works here

<Mikaku>Ctrl-a then x is not working, Ctrl-C neither works

<Mikaku>'kill' did the job, as always

<rickmasters>Sometimes the terminal is borked so "stty sane" can bring it back

<Mikaku>yes, I've had to run 'reset' to sane the terminal

<Mikaku>rickmasters: if I run the command again './rootfs.py --qemu --kernel kernel --kernel-fiwix-hd' it will continue where it stopped or it will start from zero?

<rickmasters>It will start from zero and likely fail when trying to mkdir existing directories

<Mikaku>ok

<rickmasters>as I mentioned, if you modify bootfiwix-hd you can copy the hda.img before launching qemu so you don't have to run the downloads and disk prep again

<Mikaku>ok, thanks

<rickmasters>Of course you'll have to run rootfs.py again but only once to create a master image that you can copy each time you run bootfiwix-hd

<Mikaku>rickmasters: well, unfortunately this is a known bug so I don't need to use live-bootstrap tools to see it. As I said, it also appears to me from time to time when building all FiwixOS packages

<Mikaku>the good news here is that there is not a problem with the disk driver, at least not directly reading/writing as I understood

<Mikaku>as a very talented guy said some time ago, many eyeballs make all bugs shallow :-)

<Mikaku>rickmasters: so, you said that this bug doesn't appear using the ram disk?

<rickmasters>Yes, the ram drive works fine.

<Mikaku>this is really interesting

<Mikaku>I mean, the buffer and page cache doesn't know from where the data comes

<rickmasters>maybe the ram requests are synchronous so there is no opportunity for something else to mess with it

<Mikaku>yes, disk driver puts the process to sleep until the data arrives, this not happens using the ram disk

<aggi>i think i found another bug, inside tcc-compiler (mob branch december/2022) ... can't track/bisect it where this is coming from tcc_error_noabort("'%s' defined twice", name);

<aggi>i'll stick to 0.9.27-version for a little while now

<aggi>anyway

<aggi>rickmasters: fyi, the proposed patch didn't help with linux-2.4.37.11-seyko2/TCC

<rickmasters>aggi: I'm not surprised - it was for Fiwix.

<aggi>yep

<aggi>and this raises some more principle concerns over this; because if i can't clarify upon adress-layout/mappings/translatios with linux-2.4 reliably, in conjunction with any compiler/linker magic

<aggi>rickmasters: i fear this patch may affect/break any ordinary i386-tcc emitted binaries other than fiwix kernel?

<rickmasters>Yes, it's possible but not likely since binaries typically don't use virtual addresses over 0xC0000000.

<aggi>anyway, i may give linux-2.4 another try, together with the tccboot-loader sequence; however, this won't solve the principle issue mentioned either

<rickmasters>And this patch was specific to live-bootstrap which is only used for bootstrapping.

<aggi>rickmasters: no need to excuse; thanks for the hint

<aggi>yet, to confirm the suspicion i have, i had to follow the tccboot-loader sequence, which won't solve the principle issue, and i'm not interested in JIT-compilation of kernel

<rickmasters>aggi: No its a valid issue that is worth raising. If the tcc package built by live-bootstrap is used elsewhere and creates a problem it may need to be rebuilt without that patch after Fiwix is built.

<aggi>allright, i think fiwix and linux-2.4 are affected by the same problem, yet for linux-2.4 i had to confirm this with tccboot-loader (if this changes anything)

<aggi>and, if Fiwix works, this may be very interesting, in any case

<rickmasters>aggi: Well I hope it helps you in some way.

<aggi>for example, i too considered linux-2.2 (which uses some older as86 syntax bootsec/setup asm code, instead of gas), and i am concerned about the binutils/gas-asm

<aggi>rickmasters: i am thinking to terminate, due to principle feasibility issues

<aggi>intersecting with bootstrappable

<rickmasters>aggi: As we both have discovered, tccboot is a demo - not an open source project. I couldn't get it to work with the sources and tools provided.

<rickmasters>The ISO seems to do something that builds and boots linux but it is not at all clear how to built it yourself.

<aggi>well, i can build tccboot (although it's a little more complicated, because i am crosscompiling from HOST=arm/aarch32, as another sanity check if anything is wrong)

<aggi>however, tccboot-loader won't solve the clarification issue of address-layout/mappings/translations and support with tcc-linker, it will only confirm this is what's crashing interrupt-handling with linux-2.4

<aggi>and tccboot-loader can't solve the problem with AoT compilation of linux-2.4 either, it won't solve the GNU gas/16bit/asm related problems, with which the whole procedure is locked against binutils-gas

<aggi>which is one principle criteria, to avoid just them one day, binutils

<rickmasters>I'm not sure I follow everything you are saying but I just couldn't figure out what tools and steps were used to create the tccboot ISO.

<rickmasters>I didn't try contacting the author because I'm shy and didn't want to be a bother and I doubted the author had more to provide.

<rickmasters>Yeah, I was cross compiling from a x86_64 machine which probably didn't help either.

<aggi>rickmasters: allright, i'll re-iterate over tccboot, to compile that one from source entirely; with both linux-2.4.26(100% identical to the sources from Bellard), and linux-2.4.37.11

<rickmasters>All I was able to do was build the Linux kernel without obvious errors. I had no idea how to boot it though.

<rickmasters>But what tcc? It wasn't clear what bellard used. I don't think I was able to just pull it off the ISO because of missing libraries.

<aggi>well, i (cross)-compiled both linux-2.4.26 and linux-2.4.37.11 with various versions of tcc-compiler/linker (for bootsect/setup parts i set AS=i686-binutils-as only); this compiles, this boots, and then kernel crashes related to interrupt handling

<rickmasters>How did you boot it?

<aggi>yes, on the ISO, the tcc-version is stamped 0.9.21, which i suspect may not be identical to the release-tag in git-repositories, due to build-errors i encountered which did require some commits _after_ 0.9.21 was tagged

<aggi>rickmasters: booted as an ISO, syslinux bootloader, that's all confirmed and working, except for the crashes

<aggi>meaning, kernel does execute as it should

<aggi>i'll test tccboot-loader next; to see if this makes any difference, if kernel crashes then, or not

<aggi>if it does crash, then it's a tcc-compiler/version related issue

<rickmasters>That's a good data point. I gave up when I realized it couldn't be booted _at all_ with a recent qemu.

<rickmasters>Since I needed to write the boot loader I was depending on using qemu as a guide but that didn't work out.

<rickmasters>So, unless you have to tccboot-loader source that will be a challenge to figure out

<rickmasters>I was able to boot Fiwix with qemu so I know I could write a boot loader for it and that worked out better from a boot perspective.

<aggi>linux-2.4/tcc os booting on real-hardware even, already tested highmem-support, with 16GiB RAM reported ...; and then crashes...

<aggi>and linux-2.4 has one benefit, over Fiwix: hardware support (USB, ACPI, real-hardware etc...); even when it's not the prime target of bootstrappable

<muurkha>so you couldn't get it to boot in qemu either, aggi?

<aggi>muurkha: i just didn't test with qemu

<aggi>muurkha: and since i follow a strict no-C++ policy, that's why i don't bother with qemu and many other

<muurkha>oh! okay

<aggi>this no-C++ policy affects bootstrapping, of cause: no qemu as mentioned, no >gcc-4.7, hence no aarch64, no risc-v, even u-boot loader is gone due to some transitive dependencies against c++/python-swig

<aggi>furthermore, no llvm/clang (!), just in case

<aggi>and i tightened at other frontlines too: no python, no perl, no bash, no gnu autotools (which one day will leave me without binutils, if i don't re-integrate this similar to oasis linux did)

<muurkha>that's interesting, why don't you like python, perl, and bash?

<aggi>muurkha: there is different issues with each, which can't be solved anymore

<muurkha>this is reminding me of the novel A Void

<aggi>muurkha: i am way beyond void, surprisingly

<aggi>because, there seems other niche fringe projects, concerned with this, related to bootstrapping

<muurkha>cool!

<aggi>with perl gone... the gnu autotools/automake are gone...; that's how i arrived at the idea of oasis linux, which strongly intersects with alot of issues i had encounted surrounding GNU

<aggi>and, it's not their license, it's the problematic bootstrapping why i will abandon GNU-toolchain and GNU-buildsystem

<aggi>yet, this is still blocked: at kernel, libc, and an assembler

<muurkha> https://en.wikipedia.org/wiki/A_Void

<stikonas>well, if we keep fiwix in RAM (as is currently is) hardware support for bootstrapping wouldn't matter too much

<stikonas>it would only matter if you want to use it as a daily driver

<stikonas>but fiwix kernel being small is what makes it a good target for intermediate bootstrap kernel

<stikonas>at least on x86

<aggi>stikonas: yes, that's another difference; i do not consider linux-2.x and tcc-compiler as an intermediate step of bootstrapping; i intend to emit a production-ready system with it, on x86, with decent hardware support

<stikonas>yes, so your goal is a bit different

<aggi>well, Fiwix isn't far away from linux-2.x ;)

<aggi>and the real difference, is the no-c++ policy

<stikonas>yes, but old versions of linux are not very suitable for live-bootstrap

<stikonas>as live-bootstrap avoids pregenerated files

<stikonas>and linux-libre scripts have not existed back then

<aggi>i recall, some early hex0.bin required llvm x86_64? could be worse; i would acept this hex0.bin as pre-generated on my part then.

<aggi>and trust the bootstrapping path to tcc-compiler is clean otherwise.

<aggi>oasis linux showcased, GNU-autotools/automake aren't necessary, tcc/linux/toybox/sbase/ubase won't need them; to avoid just this problem of pre-generated files

<stikonas>aggi: no, hex0 never needed anything

<stikonas>oh I think you are thinking of my prototypes for UEFI

<stikonas>for hex0 stuff we usually write in stages

<stikonas>write some high level prototype

<stikonas>then assembly

<stikonas>then convert to hex2 and then to hex0

<aggi>stikonas: amazing; so earlier bootstrapping stages won't violate the no-c++ policy then

<stikonas>(depending on ISA and some other factors, some stages might be skipped)

<stikonas>there is no C either

<stikonas>it's bootstrapping

<stikonas>so you start with machine code

<stikonas>let me show you hex0 for x86

<aggi>sorry, misunderstanding; i was just confused then over the uefi-related path, which required llvm

<stikonas> https://github.com/oriansj/stage0-posix-x86/blob/master/hex0_x86.hex0

<stikonas>no, it's only for development purposes

<stikonas>it's easier to prototype in C

<stikonas>and for UEFI llvm was helpful as it can output UEFI binaries directly

<stikonas>unlike gcc which needs some hacks

<aggi>ok

<stikonas>but that's for prototype only

<stikonas>2nd prototype was written in assembly

<stikonas>then 3rd was stage0 style M1 assembly

<stikonas>and then actual hex0

<aggi>and that's where i see another blocker, assembly/gas: binutils

<aggi>but i think, you may be talking about a different type of assmbler in early stages

<stikonas>well, 2nd prototype was built with clang but 3rd one is using only M1

<stikonas>but it's easier to write it in stages

<stikonas>e.g. https://git.stikonas.eu/andrius/stage0-uefi/src/branch/main/amd64/Development/hex0.S vs https://git.stikonas.eu/andrius/stage0-uefi/src/branch/main/amd64/Development/hex0.M1

<aggi>i am not sure yet, which assemblers bootstrappable.org requires at which stages

<aggi>i only know, which assembly parts exist for linux/bootloader/libc - and how this locks and blocks against GNU-autotools/binutils

<stikonas>well, hex0 binary builds hex1 then hex2 then M0. You can call M0 a macro assembler

<stikonas>M0 can do replacements like DEFINE add_eax,edi 01F8

<stikonas>and also knows how to encode constant numbers

<stikonas>and everything is described here: https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst

<aggi>i think, i could cross/compile both gcc-4.7 and binutils with tcc... however. the real question are the asm parts themselves

<aggi>which tools are required, and when (to avoid a circular dependency)

<aggi>i too would consider qemu itself such a circular dependency

<aggi>which intersects with hardware-development, and required tooling

<stikonas>well, qemu is not required, it's again a development tool

<stikonas>you can run everything on hardware

<aggi>ok. which hardware, and tooling required for this... that's the context of Z80 or Gigatron TTL type systems; and what can deployed onto those

<aggi>i recall, someone departed to FuzixOS 16bit due to this problem

<aggi>or CP/M

<aggi>however, Z80 parts, and the former soviet clones, are gone almost entirely too, nowadays...

<rickmasters>aggi: for kernel bootstrap you need to "dd" an image to a hard drive and boot it. That obviously requires existing system.

<rickmasters>aggi: You cannot truly bootstrap from scratch. More on that here: https://github.com/ironmeld/boot2now/blob/main/TRUST.md

<aggi>ironically, a relevant compiler, for Z80, SDCC, is written in C++; that's why i abandoned the idea to target Z80 with a C-compiler

<aggi>... ironically, a relevant compiler, for Z80, SDCC, is written in C++; that's why i abandoned the idea to target Z80 with a C-compiler

<rickmasters>It should be possible to get down to a bootstrap HD image of a small binary (smaller than an MBR) followed by only source that can build to a modern OS.

<rickmasters>We're not there yet but we're getting close.

<aggi>with Gigatron TTL however, the situation is different, there it's a binary.rom to accept (which i didn't inspect yet), and some crucial hardware parts are closed (PS/2 and VGA); so you couldn't terminate VT100 with free software and free hardware currently

<aggi>another, Geoff's VT100, too required closed parts, to terminate VT100 at least

<aggi>so, in the end, even when it's a tiniest 512Byte bootloader... it's thrown at hardware, raising questions over "strictness of your bootstrapping strategy"

<aggi>to keep it simple, with simulators/emultators, that's why i set the no-c++ policy blocking against qemu

<stikonas[m]>rickmasters: well, you can bootstrap from scratch but then you need custom made non x86 systems with physical I/O

<aggi>Z80 or Gigatron TTL, too got emulators/simulators, written in C

<stikonas[m]>Like it was done in early days if computing

<aggi>with x86, for ao486, this introduces a GIANT circular dependency graph against Altera tooling and similar...

<aggi>and there was some other i8086 project, deploying onto Altera, with similar problems

<rickmasters>stikonas: I suppose in theory you could build a system without trusting any software but in practice it would be ... difficult

<stikonas>yes, in practice it's difficult, probably more difficult than I'm willing to invest

<stikonas>but some people had to do it once

<stikonas>though probaby not individually but big government projects

<stikonas>those early computers were as big as a few rooms

<aggi>the east-german U880 manufacturing, that's gone entirely nowadays... seems this is one missing piece here

<aggi>because, they too had the whole hardware-manufacturing for this, and the universities

<stikonas>in practice today even manufacturing uses software

<stikonas>probably both C and C++...

<aggi>nowadays, there might be some manufacturing remaining, in Belarus close nearby Chernobyl some place

<oriansj>aggi: well you either can trust software to build hardware/program FPGAs or you need to go to individual gates (I like that plan)

<oriansj>My long term plan is to make Knight hardware real again.

<oriansj>and then you can use that to build up any architecture you desire.

<oriansj>and once you get up to icestorm and then you can just program FPGAs you trust or wait until libresilicon produces FPGAs

<oriansj>or we could build on Sam Zeloof's work and build gates at home for the core logic and buy old core RAM off ebay

<aggi>i remember General Electric and NASA reported similar problems, the latter dumpster diving for i8086 spare parts on ebay

<aggi>and GE relying on weird emulators for their PDP-11 stuff

<aggi>inside nuclear plants

<aggi>among German Railway, i followed other stories of several total outages, since when their X.25 signalling moved onto some virtualized networking

<aggi>X.25 and access to _all_ OSI networking layers down to physical and link layer is another aspect of this

<aggi>direwolf, implemented some software-modem stuff, for this, it's written in C at least, with CMake(c++) build-system clutter around it

<aggi>linux-kernels to retained some X.25 stuff

<aggi>and with posix 32bit, year2038,... that's another todo, with a roll-back to linux-2.x/x86

<aggi>it's just too much

<aggi>few days ago, just another job placement letter of mine was rejected... so why would i care?

<oriansj>well those cases tend to have more to due with certification processes and their associated costs

<oriansj>businesses with shareholders tend to only get away with crazy shit if they can justify it as improving future profits. Bootstrapping and needing old hardware for trust tends to be more of a military thing.

<oriansj>Most crypto-businesses barely get past reproducible builds and only because of dongcarl did bitcoin actually get an actual bootstrappable chain of trust via Guix.

<stikonas>yeah, don't expect to see bootstrappable builds in businesses

<stikonas>even reproducible builds are often not there

<stikonas>sometimes people there want reproducible builds but various obstacles are in a way

<vagrantc>yeah ...

<oriansj>eventually one has to sit down and honestly figure out what level of bootstrap they can trust. Some people find off the shelf Linux distros are fine. Others use live-bootstrap. A handful crazies hit hex0. Even fewer will design their own hardware on FPGA/Individual gates/Individual transistors. Because if you can't do that you'll end up spending a day reading: https://www.dbc.wroc.pl/Content/2070/Drzymala_mineral.pdf and trying to

<oriansj>figure out how to get the yield for Molybdenite from porphyry deposits to 3.8% so that the lead bath separation becomes something that you could skip as your budget isn't unlimited.

<muurkha>that sounds like fun

<muurkha>but can you maybe get away without molybdenum?

<oriansj>muurkha: depends on if you want to buy or build your own optics for photolithography

<muurkha>why optics?

<oriansj>well it appears required for the making of glass of the grade required to do sub 900nm lithography

<muurkha>you could use mirrors or, if you're using a single wavelength, holographic optics

<oriansj>well if you are willing to do the slow route, I believe you can do single atom etching but then it'll take years to make a single wafer

<muurkha>FIB etching? yeah, but not years, days

<muurkha>also by "sub 900nm" do you mean longer wavelengths than 900 nm, like, further from visible? because usually "sub" means "less than", and regular visible light is less than 900 nm in wavelength

<muurkha>and ordinary soda-lime glass or lead glass work pretty well for visible-light optics

<oriansj>muurkha: I was thinking of the lower tech version which one could build at home; speed is a good deal slower

<muurkha>I do know someone with a FIB machine in his garage

<oriansj>neat

<oriansj>not to be confused with: Proton beam writing

<oriansj>although refining tungsten to make a needle for liquid metal ion source generation doesn't sound like an easier problem to solve.

<muurkha>tungsten is a pretty important thing to be able to refine

<muurkha>it's one of those extreme substances: very hard, very dense, very refractory

<muurkha>I think the standard process reduces WO₃?

<oriansj>well it is usually collected from Wolframite (Fe,Mn)WO4 in skarns and in porphyry along with sulphide minerals

<muurkha>right, but to separate the tungsten I think it goes through a WO₃ stage, and that's what's mostly sold from the mines I think

<oriansj>well not the mines but the first phase processing companies

<oriansj>as most ore deposits are no where close to the commercial grade one would want in a smelting process.

<muurkha>I see

<muurkha>what I don't know is how you separate the leachate from the ore into tungstates and other materials

<oriansj>it gets crushed, separated and refined to bulk grade which is then sold and depending on the target metal either gets further refined or used as is.

<oriansj>usually by physical properties such as density, grain size, etc

<muurkha>because if you crush some skarn and leach it with hydrochloric acid you're going to dissolve a lot of other things that don't have tungsten in them

<oriansj>chemical separation is more expensive than just simply separating the bits that float in oil and those that sink given the target specific density

<oriansj>The exact optimal path to isolation is crazy specific as far as I can tell.

<muurkha>oh, so froth flotation gets you most of the way to pure wolframite?

<oriansj>There are whole volumes based on the properties of just a single rock and how to separate it from things it is commonly found with.

<muurkha>and I guess you can probably leach wolframite with lye and leave insoluble hydroxides of iron and manganese behind

<oriansj>well I don't know the exact steps off the top of my head but possibly

<oriansj>one has to remember, depending on the makeup of the waste material in the ore, there are different methods which are more efficient to extract that which you want.

<oriansj>and there are good reasons why one would want a whole team of specialists just to cover the extraction of just a handful of core elements.

<oriansj>If nothing else, a deep look at what is actually required to just get the basics needed to make individual transistors; makes one appreciate and value the huge volume of services provided by civilization at such cheap prices.

<muurkha>there's a tradeoff between efficiency and simplicity

<oriansj>sometimes

<muurkha>usually :)

<oriansj>sometimes the simple method is efficient enough that is just the process used. Eg Bauxite Al(OH)3 for Aluminum extraction

<muurkha>but people have been extracting tungsten on an industrial basis for something like 150 years, so you can do it with 150-year-old knowledge

<muurkha>you probably couldn't be economically competitive with those methods today, and they might not be acceptably safe

<muurkha>bauxite as found on the ground has impurities too

<oriansj>if you have a copy of that 150-year-old knowledge and know how to understand it

<muurkha>that's why the red mud problem exists

<muurkha>yes, but what I mean is, refining tungsten doesn't depend on all the stuff discovered in the 20th century to work at all

<muurkha>there are some pretty generic purification procedures that will work on most materials

<oriansj>I get that point; I was more towards computers are a product of only very social civilizations.

<muurkha>like, you can dissolve them in nitric or hydrochloric acid, neutralize the acid with lye, then recrystallize the nitrate or chloride of the metal

<muurkha>well, so far computers are only a product of one civilization

<muurkha>it happened to be very social, so it makes them in a very social way

<oriansj>and I don't know of a non-social way to get even a fraction of the way to a VIC-20

<muurkha>it's hard to imagine a non-social way to even survive in the wild

<muurkha>a few people have done it, like the Man of the Hole, or Alexander Selkirk

<oriansj>to refine ore (literally any of them) while defending from outside parties

<muurkha>or Ishi

<muurkha>but if you somehow have basic survival covered, John Plant has succeeded in refining iron from ore in only a few years from scratch

<muurkha>A mechanical computer device might count as a fraction of the way to a VIC-20, even if it could only be clocked at 100 Hz, no?

<oriansj>hmmm depending on how you define a fraction in the context, there are paper computers that are turing complete

<muurkha>you can build a relatively conventional bit-serial CPU in something like 700 NAND gates, and there are plausible mechanical computing devices that work in higher radices

<oriansj>granted

<oriansj>I was thinking more Dr Stone reboot but completely alone; how far could one really get.

<muurkha>Dr. Stone is not intended to be realistic

<oriansj>agreed

<muurkha>I think you could probably build a mechanical computer with 128 moving parts, not counting the memory

<oriansj>but as a thought experiment to the question of how much could one achieve on that path entirely alone

<oriansj>well one would have to build the tools to build the tools to build the parts

<oriansj>and making a screw is a very hard thing to do by hand.

<muurkha>yeah, that's what's interesting about Plant's experiment

<muurkha>I don't think it is, actually

<muurkha>I mean it depends on your starting point, but a wire plus a dowel gives you a screw

<oriansj>well a dowl depends on a lathe

<muurkha>yes, and a wire probalby depends on drawing dies

<muurkha>you wrap the wire around the dowel in a helix; the wire thickness sets the thread pitch

<muurkha>once you have one screw, you can use it to make more screws with the same pitch pretty easily

<oriansj>you also had to have pulled the wire to approximately a uniform thickness

<muurkha>drawing dies make sure the thickness is uniform

<muurkha>the size of the hole in the last die

<muurkha>lathes date back to at least Old Kingdom Egypt; Grandpa Amu demonstrated how to build one out of wood

<muurkha>are you familiar with Grandpa Amu's woodworking videos?

<muurkha>you'd probably enjoy them

<oriansj>nope; never heardof them before

<muurkha>I think he uploaded them originally to Youku but they're on YouTube now too

<oriansj>I'll add it to my queue

<muurkha>they're relaxing, similar to Primitive Technology

<muurkha>not exciting and engaging like How To Make Everything or Real Engineering

<oriansj>the problem of too much good content out there

<oriansj>hard to find the gems

<muurkha>memory and reliability are problems

<muurkha>electricity helps a lot because it allows your computing device to run 30 times faster at a given scale and power budget

<muurkha>but it's totally plausible that you could build a mechanical computer out of spiderwebs that would run at several MHz, for example, as fast as TTL

<fossy>rickmasters: is there anything else *you* think is missing from #272 before merge (I am reviewing right now)?

<fossy>obviously, sysa -> sysb is still missing, i haven't decided on whether i think that should be needed before merge

<fossy>(leaning towards no, and using a reboot instead in the interim)

<fossy>(but before 1.0 release, add kexec)

<gforce_de1977>aggi: U880 - https://en.wikipedia.org/wiki/U880 - i know a now ~50 years old woman in my hometown which was involved in cloning / dissecting / reverse-engineering the Z80 line by line - maybe she can explain me some more details

<gforce_de1977>aggi: are you from germany? (i just ask because of a job offer, i work remotely as sysadmin for a company in hamburg)

<oriansj>muurkha: spider webs would be a new one for me; I've seen the crab based computer though.

<rickmasters>fossy: thank you for reviewing https://github.com/fosslinux/live-bootstrap/pull/272

<rickmasters>fossy: as mentioned in the Issue, the checksumming fixes revealed that the checksums of the tcc-0.9.26 binaries are different under builder-hex0

<rickmasters>so, that's the biggest remaining problem to resolve before merge.

<muurkha>oriansj: crab-based computer?

<muurkha>spider silk is typically 1–5μm in diameter; Willard Wigan has used it in his sculptures when he needs thin ropes

<rickmasters>fossy: I've resolved the checksum differences.

<rickmasters>The builder-hex0 kernel was returning the current directory with a trailing slash which ended up in the debug strings of tcc-0.9.26

<rickmasters>All tcc-0.9.26 stages are compiled with -g so it was only an issue for those binaries.

<rickmasters>Anyway I'll try to provide an update to the PR soon, including your other feedback as well.

<stikonas[m]>Removing -g might have been simpler...

<rickmasters>stikonas: Oh definitely but fixing builder-hex0 felt like the right thing to do to avoid any future problems.

<stikonas>yeah, longer term your solution is better...

<stikonas>I also want to try to see if I can get tcc to output trampoline code...

<stikonas>testing some stuff now

<stikonas>maybe tcc can't do that...

<stikonas>rickmasters: mayeb we should coordinate with janneke regarding base address?

<stikonas>it would make things simpler if we didn't have to patch it\

<rickmasters>yes, that should be upstreamed

<stikonas>rickmasters: I've left another comment, it should be possible to use alias for tcc

<stikonas>rather than using very long build lines over and over again...

<rickmasters>stikonas: oh that would be great. I tried using a master variable but failed. I'll try alias

<stikonas>yes, I've added alias to kaem after I got tired of huge walls of text when building mes

<stikonas>it's only supported by full kaem (not kaem-minimal) but that should be fine

<oriansj>muurkha: https://hackaday.com/2012/09/28/making-logic-gates-out-of-crabs/

<oriansj>one only needs about 16 Billion crabs to play doom

<stikonas>hmm, I'v

<stikonas>I've managed to get as to segfault...

<stikonas> https://stikonas.eu/files/cc_x86.S seems to crash it (it's not a valid GAS file but still)

<oriansj>well if cc_x86.S crashes an assembler, you don't have much to go to reduce that crash to a tiny test

<stikonas[m]>I can probably make it abit smaller

<stikonas[m]>We'll see tomorrow...

<stikonas[m]>Then I can report it to bugzilla

<stikonas[m]>Having a tiny test to submit would be better...

<muurkha>oriansj: aha

<fossy>yeah, assemblers shouldnt segfault on bad code..

<muurkha>or good code either

<muurkha>but that's less controversial usually

<fossy>:D

<muurkha>oriansj: they didn't make a not gate, or even an and-not (abjunction) gate

<muurkha>(abjunction is "falsehood-preserving" in the sense that if all the inputs to a circuit made out of abjunction gates are false, the output will always be false, which is a convenient property in cases like this where the alternative would be to manufacture crabs out of nothing; nevertheless in the presence of a source of truth it's just as functionally complete as nand or nor)

<oriansj>well a crab spawning circuit is probably more complex than a silicon transistor

<muurkha>perhaps less reliable too

<aggi>so, decided to take the route of tccboot quickly, and picked v0.9.27 for this... surprise... the headers/defines changed since v0.9.22 which complicates this further

<aggi>tccboot-0.1 is not compatible with tcc-0.9.27; this isn't a problem which couldn't be solved, it just complicates the test-setup considerably, and the amount of test-cases to verify

<aggi>another problem, i did verify userspace-compilation/linking with a most recent tcc (git HEAD dec-2021), and i am not willing to rollback to a 20year old development branch

<aggi>ok, i'll have to repair tccboot for tcc-0.9.27 or later then, which isn't trivial

<aggi>probably

<aggi>ok... i'll skip the tccboot-bootstrapping part; it's just too much fiddling currently, to support tcc-0.9.27 with tccboot-0.1

<stikonas>oriansj: so I've isolated minimal example that triggers that crash https://paste.debian.net/1276228/ This is probably good enough for bug report

<stikonas>I guess it chokes on "comment" (as ; is not really a comment but still, crash shouldn't happen)

<stikonas>oh it's a = a that crashes it...

<stikonas>probably goes into recursion

<stikonas>slightly smaller example then https://paste.debian.net/1276229/

<oriansj>it should have just stopped at a is not defined.

<oriansj>that class of bug should have been found with the most basic of fuzzing

<stikonas>hmm, I'm not actually sure what = even means in gas context...

<stikonas>but yes, this is a fairly simple reproducer

<oriansj>it is variable assignment (in this case a variable named a)

<stikonas>ok, reported it here https://sourceware.org/bugzilla/show_bug.cgi?id=30308

<aggi>i think this is missing when tcc compiles/links the kernel -> linux-2.4.37/arch/i386/vmlinux.lds: __start___ex_table = .;

<fossy>rickmasters: can I confirm that it is correct for all your contributions in #272 to be MIT licensed (different to the rest of the repo which is GPL, but since these are substantative contributions, particularly builder-hex0, i don't mind if it stays MIT)

<aggi>i'll try something else; compiling tccboot-0.1 with an original/old version of tcc-0.9.21|22 ... which _should_ behave identical to what the original tccboot.iso/kernel-2.4.26

<aggi>meaning, the jit-compiled kernel must not crash, and i narrowed down where it crashes, and probably why (missing/mis-placed __ex_table, entry.S)

<aggi>the objdump of entry.S.o either tcc-compiled or gcc-compiled differ considerably, which may or may not be relevant, depending on if i can re-produce the _original_ status of tccboot-0.1 from source

<aggi>and then, i can precisely ask Bellard, what errors i may have made

IRC channel logs

2023-03-31.log