***Server sets mode: +nt
<damo22>youpi: what happens if an unhandled case is met in a switch {} but no default exists? <youpi>i.e. default: break; is a no-op semantic-wise <youpi>but it's a "kill the warnings" compiler-wise <youpi>btw do you have a summer time shift ? <youpi>we just moved from utc+1 to utc+2 :) <damo22>unfortunately, my latest code hangs after "startup" ***azeem_ is now known as azeem
<damo22>i think i fixed the problem but now i reliably get timeouts and that WDC error in qemu <damo22>maybe i need to remove the timeout i added in rump ahci <damo22>"youpi: Can't this be an NINTR array? Otherwise it's painful to go through the list to find the entry for the irq line." how will that work if we want to support multiple handlers for sharing the same irq? <youpi>instead of having just one user_intr_handlers you can use an array <damo22>i think its working, but qemu has a bug <damo22>i cant test on real hw yet because my irq mapping is not 1:1 <damo22>When returning struct/class, the calling code allocates space and passes a pointer to this space via a hidden parameter on the stack. The called function writes the return value to this address. Stack aligned on 16-byte boundary due to a bug. <damo22>i guess i have to clean up the stack in the calling code <youpi>better not return a struct, but either return a pointer to struct, or make the caller explicitly provide the poniter to the struct <damo22>i have found a bug in the interrupt.S <damo22>apparently you have to align the stack to 16 byte boundaries when using GCC <damo22>and calling from the stack in IA32 mode <youpi>though the 16-byte alignment is very recent <youpi>only needed when you build with an sse-enabled compiler <damo22>also, it does pushl %eax but should be pushing ecx <youpi>normally gnumach doesn't use sse instructions <damo22>because its whole purpose is to save the reg ECX <youpi>just to get back the irq number <youpi>it saves the irq number, then restores it <damo22>i think its supposed to push ECX to save the value of the reg so it can use ECX register <youpi>it's passed the irq number in eax <youpi>in these low-level assembly there is no things like caller/caller-saved convention <damo22>ok but dont you have to push to the stack the args? <youpi>in these low-level assembly there is no things like argument passing convention <damo22>i may as well push 16 byte aligned <damo22>i need to pass it an argument, the irq <youpi>when you are calling a C function you have to properly respect the calling convention, yes <youpi>that's the same for the ivect call, actually <damo22>and then realign it after the call <damo22>but if it interrupts before the cli i need to fix the stack before that <youpi>"interrupts before the cli"? <damo22>what if it interrupts in the interrupt handler <youpi>and that call will have to align itself <youpi>in user_irq_handler, don't make prev = the head, it won't work if it's the first entry that needs to be removed. Make it prev = &user_intr_handlers[id], and then pre v= &handler->next <youpi>so you can do *prev = handler->next <youpi>again, you don't need to separate out if (!old) <youpi>you can actually simply put the entry at the head of the list <youpi>new->next = *head; *head = new <youpi>to make sure you have your pointers correctly <youpi>never hope to be able to do this correctly just in your head, that never works 100% even for confirmed programmers <youpi>(and studying books about basic algorithms on lists etc. do help a lot) <damo22>Hurd server bootstrap: ext2fs[part:2:device:wd0] exec startupHANG <damo22>same as before, but rebased and cleaned up <damo22>hmm is the stack aligned at the time of calling ENTRY(interrupt) ? <youpi>I don't know, but I don't think you want to maintain alignment over all assembly code <youpi>and rather just realign just before calling C functions <youpi>there are too many small things that C assumes, like the direction flag <damo22>but how do i align the stack from scratch <youpi>so better just make them correct in the interrupt.S place only <youpi>you can save the previous value in ebp and realign esp <damo22>wouldnt it be better to ensure the interrupt entrypoint is called with an aligned stack? <youpi>that'd mean having to make sure all the assembly stuff is respecting it <damo22>then you dont have to repeatedly align the stack in the interrupt handler <youpi>that's way simpler just to fix it in one known place <youpi>aligning %esp is a trivial operation <youpi>mantaining stack alignment is maintenance overhead <damo22>i read somewhere you only need to align the stack to 16 bytes if the compiler is allowed to introduce SIMD instructions <youpi>yes, that's what I meant above: sse instructions <damo22>if we keep that disabled, we dont have to worry about that <youpi>but on x86_64 there is some additional requirements for stack alignment <youpi>and it's better for perofmrnace anyway <youpi>better simply check the system V abi reference document <damo22>but the calling convention on x86_64 does not require pushing args to the stack <youpi>yes for x86_64 you'll have to set in registers, not on the stack <damo22>then you dont have to align the stack at all for calling C functions <youpi>you still have to align the stack <youpi>for the callee to have its esp aligned before putting local variables <youpi>the alignment is not really for args, but for local variables etc. <youpi>(even if yes some args may need the alignment too, but that's rare) <damo22>can we just keep SIMD out of gnumach entirely? <youpi>but as I said, x86_64 still requires some of it iirc <youpi>no , requires some alignment <damo22>i sent in patches again, but i gtg to sleep <damo22>the 2 patches i sent boots to startup