IRC channel logs
2024-02-29.log
back to list of logs
<webczat>trying to compile uclibc-ng, try #123456789. or not really because haven't tried since two days ago. :) <webczat>what do you do before first compiling musl after tcc to grab linux headers? I mean I did something and have them but that required commenting out usage of some scripts. which means i am not yet sure if they work <webczat>and gave up, will really do musl. uclibc maybe could be compiled if I could create a config file manually, othervise i doubt it. <webczat>because "make config" requires things like regex... <webczat>stikonas: musl can be compiled without? <matrix_bridge><Andrius Štikonas> Yes, though obviously not all software later will build <matrix_bridge><Andrius Štikonas> But we defer linux-headers till after gcc <webczat>neither uclibc and glibc can, and I thought musl also can't. maybe I've even tried... <webczat>stikonas: okay. in general it seems you can do them after tcc-musl. <webczat>there are no compiler problems. there are mes libc problems. <webczat>after I build musl I get general protection fault on any program I build. unsure why. i removed code that failed in tcc asm, but i doubt it's being used. <webczat>something related to breaking thread local storage? <stikonas>hmm, there is a patch in live-bootstrap to disable thread local storage for musl <webczat>stikonas: the interesting thing: the programs I built with tcc against this musl segfault on the bootstrap kernel I have. however, not on the working kernel of my laptop os. i mean i can literally transport the binary out of that bootstrap system without recompiling and run it <webczat>thought it's the tls because I changed the syscall asm from call *%%gs:16 to int $128, the former was not working under tcc. but if the binary runs on other computer, not sure what is going on <webczat>stikonas: my bootstrap kernel is manually configured linux 6.7 which might possibly have something important disabled <stikonas>we haven't tested disabled tls with linux 6.7 <stikonas>at leats I'm not aware of anybody doing that <stikonas>but if it works with an older one, I don't see why it wouldn't work with 6.7 <stikonas>actually we do run userspace bootstrap too <webczat>stikonas: i haven't really tried to disable it at first. but had to change the syscall invocation because of tcc. <webczat>also manually configured but i haven't tried to make it skinny <stikonas>hmm, perhaps something crucial is indeed disabled... <webczat>i probably need to transport my artifacts out and recompile the kernel. <webczat>stikonas: i had disabled i386 vsyscall table. but it's only a guess that it's the reason for the problems I had <webczat>still unsure and have to run this first <webczat>just discovered that if you want your 32 bit musl to work on a linux kernel, you must never even think about disabling modify_ldt syscall when configuring that kernel, othervise your musl will segfault with a general protection fault and you'll be left wondering what you've done to it so that it miscompiled. <webczat>when in fact it just executed a specific crash logic using a hlt instruction which is illegal in userspace <webczat>it's because of the tls logic. so in theory disabling tls would also help if done correctly. <webczat>unless I am not quite correct, but... <webczat>no i am not wrong except that it tries to use set_thread_area and fails which is weird by itself. <webczat>if anyone is compiling the 32 bit musl with tcc on linux I'd be happy to get them to strace a binary with empty main function. to confirm this also happens for you. either tcc bug or musl bug or a consequence of asm changes needed for it to compile. <webczat>and when I get to it I'll recompile musl with gcc. <matrix_bridge><Andrius Štikonas> rickmasters is probably the person who knows most about set_thread_area <webczat>well i generally started poking around #musl channel too. might be that this is actually a tcc bug, because it tries to call set_thread_area, then fails miserably because the passed structure is wrong <webczat>and then tries modify_ldt which shouldn't be used in the first place :) but happily succeeds. <webczat>unless you compile it out, then it's a fatal error and causes an intentional crash logic <webczat>the passed structure has an entry field which should be set to -1 but is set to some other value which is close but not quite... didn't look at it's bit representation <webczat>hmm it seems like it loads wrong value. <oriansj>webczat: well local label references being wrong woud either be a linking error or a serious miscompile