IRC channel logs

<oriansj>muurkha: especially given the massive amount of resources available

<muurkha>oriansj: also, experience

<oriansj>and better source material

<oriansj>and rickmasters is awesome too ^_^

<pder>Yesterday I tried updating live-bootstrap to use mes 0.24.2, and I ran into an issue where `make` would segfault.

<pder>I believe janneke pointed out that he had to rebuild mes libc after tcc. I tried that today, and that seemed to fix the problem.

<pder>Does anyone know why the rebuild is needed? Is it related to the stat64 changes?

<pder>Now I am just trying to figure out a way to do the rebuild of mes libc without duplicating a bunch of code

<stikonas_>pder: after which tcc?

<stikonas>pder: and we do rebuild it a few times already

<pder>rebuilding mes libc is now necessary after tcc 0.9.27

<pder>in tcc-0.9.27.kaem

<stikonas>well, that's not too surprising

<stikonas>earlier we were mixing mes libc build with tcc 0.9.26 with code compiled with tcc 0.9.27

<stikonas>it was more surprising that it worked

<stikonas>perhaps recent mes changes trigger expose incompatibility between tcc 0.9.26 and 27

<stikonas>and in all other cases we rebuild libc immediately after building the compiler

<stikonas>I think this one was the only exception

<stikonas>pder: I guess you'll have to duplicate this then https://github.com/fosslinux/live-bootstrap/blob/master/sysa/tcc-0.9.26/tcc-0.9.26.kaem#L82

<pder>do you have a preference for extracting mes-0.24.2 next to tcc-0.9.27 in the build directory and recreating unified-libc.c, or I can cd into tcc-0.9.26/build/mes-0.24.2 and rebuild the files already there

<stikonas>hmm, not sure...

<stikonas>maybe let's ask fossy

<stikonas>it is slightly ugly to rely on previous build dir

<pder>ill push my changes to a branch so its easier to see what I mean. It felt wrong to be changing to another packages build directory

<stikonas>then let's just copy that piece of code

<stikonas>and do it in the current build directory of tcc 0.9.27

<pder>however duplicating the code that concatenates unifiied-libc.c seems wrong too

<stikonas>pder: you don't have to dulpicate it

<stikonas>just extract it into some file

<stikonas>and include it

<stikonas>it might be cleaner if it's in a separate file

<stikonas>at the very least running a script from another packages src directory is less messy than going into its build directory

<stikonas>or perhaps it should even be extracted into its own package?

<stikonas>strictly speaking its mes-0.24.2 package, just need another build script int it

<rickmasters>Mikaku: I just filed an issue with Fiwix for lseek past end of file. Sorry I don't have a proposed solution this time. Not sure how to fix it.

<stikonas>rickmasters: something in live-bootstrap triggers it?

<rickmasters>stikonas: yes, the GNU Assembler aligns sections by lseek'ing to the start of the next section rather than manually writing pad bytes.

<stikonas>rickmasters: do you know if that's just 2.14a?

<stikonas>or newer one does that too?

<rickmasters>stikonas: i don't know

<stikonas>I might try upgrading binutils

<stikonas>so if that problem goes away, then we might not have to update Fiwix...

<stikonas>it is quite likely that we can get something much newer thatn 2.14a...

<rickmasters>stikonas: well, it's legal behavior and more efficient so I'd be surprised if they redesigned that

<stikonas>maybe not...

<stikonas>still, upgrading binutils would be useful

<stikonas>i.e. if somebody later does riscv or arm live-bootstrap

<stikonas>newer binutils would mean it already supports those arches

<rickmasters>to be honest, gas is so complicated that I haven't even found the code that does it - I basically did an strace in the kernel

<rickmasters>I think I can put in a simple workaround to inject writes on an lseek past EOF but I'm hoping Mikaku will come up with something better.

<rickmasters>it looks like I have a workaround. When a write starts at an offset past current file size I rewind back to current size and inject writes up to the current offset

<rickmasters>stikonas: regarding binutils upgrade, how much of an upgrade?

<rickmasters>(funnny that comment of yours didn't show in the main chat area of LimeChat but in the bottom "system" window for some reason...)

<stikonas[m]>rickmasters: not sure yet, I think only depends in what tcc can do

<stikonas[m]>I think I can sort out all other dependencies like newer autotools

<stikonas[m]>Perhaps this will result in dropping some older autotools builds too

<stikonas[m]>I suspect at least 2.20. But perhaps even up-to-date binutils

<stikonas[m]>I haven't tried yet...

<rickmasters>hopefully it won't be a problem. I'm not too worried.

<rickmasters>stikonas: by the way, I've been working on live-bootstrap integration.

<rickmasters>stikonas: I'm now patching and running live-bootstrap with a new "--kernel-bootstrap" option.

<stikonas[m]>Oh good, once that is done it will be easier to test such changes against fiwix

<rickmasters>stikonas: I still have a bit of work before I'll commit it. I'm working through checksum differences right now.

<rickmasters>stikonas: the builder-hex0 file system creation is still in a separate shell script.

<rickmasters>I suppose I'll be porting that to python for consistency.

<Mikaku>rickmasters: Ok, I'll take a look to it, thanks for filing this issue

<rickmasters>Mikaku: sure. Thanks for taking a look. I have a somewhat ugly workaround that I can add to the issue.

<Mikaku>rickmasters: good, any help is welcome

<Mikaku>rickmasters: BTW, you might want to try the latest version of Fiwix (in GitHub) as it comes with DMA support and so disk I/O transfers are now orders of magnitude faster

<rickmasters>Mikaku: I posted the workaround.

<rickmasters>Mikaku: Yes, I'll update soon. I'm working with a snapshot from Feb 3 so I'm not too far behind.

<Mikaku>yes I saw it now, I'll take a look later. I've had a small accident this afternoon running in the mountain and my left hand needs some attention :-), nothing serious though

<Mikaku>Ok

<rickmasters>Mikaku: well take care of yourself :/ there is no rush now as I have a workaround and am no longer blocked

<Mikaku>this is the commit that includes DMA support <https://github.com/mikaku/Fiwix/commit/f9f78adc5eb23f02b25167f021c3da8dd125dceb>

<Mikaku>(Feb 14)

<Mikaku>rickmasters: OK, thanks

<Mikaku>rickmasters: I've been able to run your test program on FiwixOS 3.2 and it works as expected

<Mikaku>I mean, the hole is filled with zeros

<Mikaku>where did you compile this program?

<rickmasters>Mikaku: I was testing with a fairly recent 1.4.0 kernel

<Mikaku>under FiwixOS 3.2?

<rickmasters>Mikakue: yes

<rickmasters>Mikaku: it was a snapshot from Jan 31 (204e594e)

<Mikaku>weird

<rickmasters>Mikaku: which kernel where you using?

<Mikaku>I'm always using the latest in GitHub

<Mikaku>if you can upload that program, I could do more test on it

<Mikaku>the binary, I mean

<Mikaku>I hate when apparently simple bugs are not easily reproducible :-(

<rickmasters>Ok, I'll work on uploading the binary.

<rickmasters>I just tried with latest github code, same result.

<rickmasters>I uploaded the binary. Perhaps you could try a larger lseek offset?

<Mikaku>rickmasters: I'm gonna test it

<Mikaku>rickmasters: yes, I've been working on a llseek() patch, that is changing all lseek() by llseek() which uses two 32bit numbers to form a 64bit value, but I need to do more testing to make sure that it will work on an i386

<Mikaku>thanks for uploading the binary

<rickmasters>Mikaku: You're welcome.

<Mikaku>rickmasters: bad news, I don't see any difference between you binary and mine, the hole is zero-filled :-/

<Mikaku>well, bad news, in the sense that I'm still unable to reproduce the issue

<rickmasters>Mikaku: yeah, that's unfortunate

<Mikaku>it's curious to see that your binary has a different size than mine

<Mikaku>mine: 98449 bytes, yours 95086 bytes

<Mikaku>cat my

<Mikaku>err, sorry

<Mikaku>I don't discard a bug but it will be hard to fix it without having a reproducible scenery

<Mikaku>*scenario

<rickmasters>Mikaku: sorry. My mistake - I'm on FiwixOS 3.1 with 1.4.0 kernel

<Mikaku>rickmasters: well, since it's a statically linked binary, the system where it's running doesn't care much

<Mikaku>only kernel version matters here

<Mikaku>I've been testing it on the official 1.4.0 version (Nov 15, 2022) and I still see a zero-filled hole

<Mikaku>hmm, why the offsets in your 'od' are always zero?

IRC channel logs

2023-02-17.log