Running a callback in C

[IanSeyler]

Hi everyone,

I've added callback functionality to the network handler in BareMetal OS. It's a fairly simple stack modification that can be seen here: https://github.com/ReturnInfinity/BareM ... t.asm#L167

With the callback I can have a user function executed every time the network interrupt finishes. Assembly-based programs that use this feature seem to work correctly but I get sporadic GPFs with C-based applications.

Is my stack modification correct?
Is this the correct way to go about this?
What could be causing the C program to GPF sometimes?

Thanks,
Ian

[Combuster]

Code: Select all

sub rsp, 8			; Subtract 8 since we will copy 8 registers

Byte-sized registers?

[IanSeyler]

I noted that as well. It should have been '8*8'. Setting it to 64 still gives a GPF. Must have just been luck that it works partially.

Are CS and SS 64-bits wide?

[Kevin]

It is likely not the problem that you are hitting here because I assume that you only receive a reply after you have fully sent a packet and are waiting for the next keypress. But if I'm not mistaken, you're basically using signals here and none of your code looks very signal safe, neither the assembly nor the C one.

[gerryg400]

Is this a redzone problem ?

[IanSeyler]

I don't believe this is a redzone problem. I've compiled my C program with and without that flag before and it makes no difference.

In Bochs it looks like 6 64-bit values are pushed to the stack when a hardware interrupt fires:

64-bit RIP
64-bit CS
64-bit Flags
64-bit RSP
64-bit SS
64-bit ???

With my stack modifications I am trying to adjust the stack like this:

64-bit Program Callback IP
64-bit CS
64-bit Flags
64-bit RSP
64-bit SS
64-bit ???
64-bit RIP

This way the callback will be executed after the IRET and the callback will jump back to the initial RIP when it executes RET. Is this method ok?

[siavoshkc]

I noted that as well. It should have been '8*8'. Setting it to 64 still gives a GPF. Must have just been luck that it works partially.

Are CS and SS 64-bits wide?

They are 16 bits wide but stack is aligned on quad word boundaries. So they take 64 bits instead of 16.

[Combuster]

This way the callback will be executed after the IRET and the callback will jump back to the initial RIP when it executes RET. Is this method ok?

Not really, because it doesn't preserve flag/register state of it's own. The callback function will have to have such functionality that saves and restores the required CPU state (= assembler stub)

[jnc100]

I see a number of problems:

Firstly, you are not using a cross compiler so it is difficult to be sure exactly which calling convention is being used. I will assume you are using the x86_64 one. For this, a number of things need to be addressed:

1) the C function being called expects that it can trash various registers. Whilst your ISR may appropriately save and restore all registers, if it then returns to another function instead of the one that was interrupted, the new function (i.e. your C callback) will probably trash some registers that the function which was executing when the interrupt was triggered wasn't expecting.

2) the x86_64 abi also expects the stack to be aligned on a 16 byte boundary upon entry to a C function. You do not guarantee this anywhere.

3) The red zone may or may not be an issue - if you don't disable it, the C callback function will expect to have some stack space available which it doesn't actually have.

Given all of these (which are reasonably difficult to correct with the way you are doing it), I'd suggest two options:

1) run the C callback from within the ISR. Here you have to be sure that the code is safe and won't mess up your ISR state.

2) have the C callback run as a separate (maybe kernel) thread, that is only switched to when the actual ISR (a small stub) sets a flag. This is commonly how microkernels service interrupts, however you need to make sure the actual ISR removes any data from the device to prevent the interrupt being constantly triggered.

Regards,
John.