IRC channel logs

<stikonas>oriansj: hmm, I'm not too sure if we can get size of right hand size of equality...

<stikonas>I was looking at variable_load function

<stikonas>and we have access to current_target->size

<stikonas>but I think that's LHS

<stikonas>but in case of uint_16 a = uint8 value, we don't want to read 16 bits...

<stikonas>although, if we can't do anything, then maybe we'll have to live with program source level workarounds

<stikonas>which might be better than no support at all

<oriansj>well we only read into a register and write a subset of that register to memory

<oriansj>so the right side is what we are reading into the register and the left side is what we are writing into memory

<stikonas>oriansj: actually, I'm checking what we have now. It might already be enough for my UEFI purposes

<stikonas>even if more advanced operation don't work...

<stikonas>(for UEFI we mostly care about storing it)

<stikonas>hmm, yes, it actually works with minor workaround on UEFI side

<stikonas>hmm, debian pastebin considers my code spam

<muurkha>ugh

<stikonas>well, I have a HTTP server, will just upload it there

<stikonas>so something like this seems to work https://stikonas.eu/files/bootstrap/struct.txt

<oriansj>device_path += sizeof(struct efi_device_path_protocol); only works on M2-planet and definitely not C

<stikonas>oriansj: oh yes, I'm aware of that

<stikonas>in C you need += 1

<stikonas>or better device_path[1]->type

<stikonas>but I think that [1]->type does not yet work in UEFI

<stikonas>well, I can try...

<oriansj>well we can fix that

<stikonas>let me first test it

<stikonas>it might just work

<oriansj>and add a test for it

<stikonas>no, doesn't work...

<stikonas>ok, so there are two TODOs then

<stikonas>and need to finish porting remaining loading/storing to load/store_value

<stikonas>oriansj: I think we have an extra dereference when we use [1]->

<stikonas>which we should not be doing

<oriansj>easy to test for that case and remove it

<stikonas>yeah, I think I am alraedy doing some test for "." case

<stikonas>it might be similar

<oriansj>probably

<stikonas>well, I might look into it after I get spawning to work in uefi

<stikonas>which should be close to working...

<stikonas>oriansj: https://github.com/oriansj/M2libc/pull/27/files

<stikonas>(spawn function for UEFI)

<stikonas>and kaem changes: https://github.com/oriansj/mescc-tools/pull/39

<stikonas>hmm there is a minor bug in the first PR

<stikonas>all / in argv get converted to \

<stikonas>or maybe not so minor

<stikonas>hmm, maybe let me mark it as draft for now

<stikonas>kaem PR can be merged though

<oriansj>stikonas: your kaem pull has been merged

<stikonas[m]>Thanks

<stikonas[m]>I'll sort out m2libc tomorrow

<stikonas[m]>But it's starting to work

<stikonas[m]>kaem was able to run another kaem that then ran hex2.efi --version

<oriansj>very nice

<rickmasters>Here is another update on running live-bootstrap on the Fiwix kernel.

<rickmasters>he good news is that I have been able to build every package up to and including gcc-4.0.4 pass1.

<rickmasters>So, it is only ten packages away from building Linux.

<rickmasters>The bad news is that there is an intermittent kernel failure around removing directories that remains unresolved.

<rickmasters>Also, there was a failure in automake-2.64 deep inside autoconf, for which I put in a small temporary workaround until I can figure it out.

<rickmasters>I'm stuck now on a kernel read error when checksumming the linux tar file, probably due to its size.

<rickmasters>I'm working on that right not but I don't have a lot to go on yet.

<rickmasters>In summary, I think I'm making good progress but I suspect the kernel issues that I've run into might take longer to resolve.

<stikonas>oriansj: I've now updated https://github.com/oriansj/M2libc/pull/27 not to convert / to \

<oriansj>rickmasters: glad to hear good progress; honestly more than I expected to see in such a short period of time.

IRC channel logs

2022-12-05.log