Q: Why this?

[TurkeyMan]

Help me understand this line?

libco/x86.c

Lines 99 to 100 in e18e09d

	stack_top -= 32;
	stack_top &= ~((unsigned long) 15);

libco/amd64.c

Lines 143 to 144 in e18e09d

	stack_top -= 32;
	stack_top &= ~((unsigned long long) 15);

It's obvious why it aligns down by 16 bytes, but why subtract 32? It looks arbitrary; nothing is ever written there (?), so why are we wasting them here?

Also, check the ARM version:

libco/arm.c

Lines 24 to 28 in e18e09d

	static const unsigned long co_swap_function[1024] = {
	0xe8a16ff0, /* stmia r1!, {r4-r11,sp,lr} */
	0xe8b0aff0, /* ldmia r0!, {r4-r11,sp,pc} */
	0xe12fff1e, /* bx lr */
	};

Why is that final bx lr instruction there? The line before loads pc, that should be unreachable code... is there a reason?

[Screwtapello]

Ping @TestudoAquatilis who made the stack alignment changes.

As for the other question, I'm not very familiar with ARM assembly, but from a little research it seems that bx lr switches to/from Thumb mode as necessary, and the PC register points two instructions ahead of the current instruction because of pipelining. Apparently ARM doesn't have delay slots, but maybe it has something functionally similar if you assign directly to the pc register?

[TurkeyMan]

Yeah I wondered if it was essentially a hint to the branch predictor... that was my best guess.

[TestudoAquatilis]

Sorry, I also do not know what the -32 is for (has already been in the code before my commit - introduced in commit 3a1855a).
I just wanted to ensure an aligned stack address.
The state before was aligning the memory size, which was probably correct in most cases given an aligned address from malloc, but you never know.
I remember that I was wondering about the -32 as well, but did not dare to remove it, so I just kept it in there assuming somebody knew what he was doing.

[Screwtapello]

Perhaps it's leaving room for the crash and entrypoint pointers on the stack?