IRC channel logs

2024-12-01.log

back to list of logs

<fossy_>strong agree with stikonas that we should be ELF standards compliant
<fossy_>(with hex0-seed), esp now that we care a lot about kernel bootstrap etc
<stikonas>fossy_: well, oriansj was probably pointing out my last hack in hex0-seed
<stikonas>have you seen it?
<stikonas>but I think it is still compliant
<stikonas>I've overlapped parts of elf header
<stikonas> https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0_x86.hex0#L38 and https://github.com/oriansj/bootstrap-seeds/blob/master/POSIX/x86/hex0_x86.hex0#L46 (note the comment)
<stikonas>so oriansj was a bit worried here
<fossy_>hm, why does this work?
<stikonas>well, because the address of program header table is another entry in elf header file https://github.com/oriansj/bootstrap-seeds/blob/cedec6b8066d1db229b6c77d42d120a23c6980ed/POSIX/x86/hex0_x86.hex0#L25
<stikonas>a bit earlier
<stikonas>and I noticed that 8 bytes are identical data
<fossy_>Oh, I see
<fossy_>ok, that's fine
<stikonas>so if we "move" program header table back to overlap it with some other data from elf header
<stikonas>things should still work
<stikonas>and I've tested it on both linux and builder-hex0
<fossy_>yes, there is no functional difference
<stikonas>well, none of them hardcode elf headers, they parse the required bits
<fossy_>i can't see any reason an elf loader/interpreter wouldn't like that
<fossy_>exactly
<stikonas>fossy_: while you are here, should we now close this issue https://github.com/fosslinux/live-bootstrap/issues/483 ?
<stikonas>I've mentioned it might be failing due to non /usr prefix there
<stikonas>but it's not a bug in live-bootstrap itself anyway
<fossy_>yeah
<fossy_>stikonas: closed it
<oriansj>stikonas: rasm gave me wrong information on instruction encoding regarding the shift instruction (sorry about that) but we might be able to shrink kaem by adding a bss section and dropping the malloc function entirely. as a 1+MB BSS section could probably hold everything the bootstrap-seed kaem would need as we build a different kaem pretty early on.
<stikonas>yeah, that might work
<stikonas>well, most of the current size / algorithm optimizations went to hex0
<stikonas>so there are probably still quite a bit of things that can be optimized in kaem
<matrix_bridge><cosinusoidally> Is there a danger you code golf too much an end up with hex0 and kaem being harder for humans to audit?
<oriansj>cosinusoidally: yes. And one of the reasons why we have a warning with the bootstrap-seeds. "*NEVER TRUST ANYTHING IN HERE*"
<oriansj>the seeds can never *grow* in terms of functionality; only shrink, that way the effort of someone else to make their own seeds will get easier over time.
<oriansj>and the bits in stage0* should always prefer comprehension over all other factors
<oriansj>(pull requests for better comments are also always welcome)
<matrix_bridge><Andrius Štikonas> yes, there is some danger that code can get complicated...
<matrix_bridge><Andrius Štikonas> but at lot of optimizations are not really that hard to follow
<matrix_bridge><Andrius Štikonas> probaby the biggest optimization was slightly different algorithm by goldstein
<matrix_bridge><Andrius Štikonas> as part of that all function calls were either converted to jumps or moved into the required location
<matrix_bridge><Andrius Štikonas> still, reading 181 byte is far simpler than 357 bytes that we had a few years ago
<matrix_bridge><Andrius Štikonas> it's basically halved
<unmush>hmm, I'm trying to fix up some old C code and it has a macro that it seems to want to use as both an lvalue and rvalue, but it includes a cast
<lilyp>if it's a cast to a pointer type, that ought to work
<oriansj>unmush: you can use gcc -E to figure out the expansion if it seems extremely complex or badly written.
<unmush>it's of the form #define MACRO1(X) (type1) MACRO2(X)
<unmush>and it's used as an lvalue - not as a pointer
<unmush>what I've gone with for now is #define MACRO1(X) (* ((type1*) &MACRO2(X)))
<unmush>so far gcc seems to be going along with it
<oriansj>unmush: oh, unxz.c previously had those sorts of macros before; I hate them. (I rewrite whole sections to eliminate them)
<unmush>makes me yearn for common lisp's generalized places
<oriansj>makes me wish C started out with better types, CONSTANTS and didn't include macros at all