IRC channel logs


back to list of logs

***Server sets mode: +nt
<damo22>youpi: what happens if an unhandled case is met in a switch {} but no default exists?
<damo22>will it hang?
<youpi>it just does nothing
<youpi>i.e. default: break; is a no-op semantic-wise
<youpi>but it's a "kill the warnings" compiler-wise
<damo22>we're getting closer
<damo22>i will rebase tonight
<youpi>btw do you have a summer time shift ?
<youpi>we just moved from utc+1 to utc+2 :)
<damo22>i think so, its 11:30 now
<damo22>i dont know when ours kicks in
<damo22>unfortunately, my latest code hangs after "startup"
<damo22>but detects the disk
***azeem_ is now known as azeem
<damo22>i think i had a stack overflow
<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
<youpi>and thus an array of lists
<damo22>ah yes
<damo22>much better idea
<damo22>O(1) lookup
<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>this is exciting!
<damo22>argh my C lists are broken
<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>no im confusing two issues
<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
<damo22>it doesnt do that currently
<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
<damo22>so it can use the register
<youpi>? no, it saves eax
<damo22>why does it pop ecx later then?
<youpi>just to get back the irq number
<damo22>i think the comment is wrong
<youpi>it saves the irq number, then restores it
<youpi>what is wrong here?
<damo22>i think its supposed to push ECX to save the value of the reg so it can use ECX register
<youpi>it's not
<youpi>it's passed the irq number in eax
<youpi>so it saves it
<youpi>that's about it
<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>what about call EXT(ioapic_eoi)
<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
<damo22>ok good
<damo22>im getting there
<youpi>that's the same for the ivect call, actually
<damo22>yeah i need to pushl $0
<damo22>to align the stack
<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>then you have another call
<youpi>and that call will have to align itself
<youpi>so you don't care
<damo22>youpi: i cant spot the error with this patch something is probably wrong with the head or tail of the list
<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>so it's trivial
<youpi>new->next = *head; *head = new
<youpi>draw a picture on paper
<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
<youpi>gnumach won't emit those
<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>that is easier
<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>we already do
<youpi>but as I said, x86_64 still requires some of it iirc
<damo22>requires simd instructions?
<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
<damo22>no linux drivers involved
<damo22>with smp and apic