Hi,
recently i came across a situation were on linux-i386 not only %eax was
altered after a syscall but also %ebx. I tracked this problem down, to
gcc re-using a variable passed to a function.
This was found on a debian system with a 2.4.17 kernel compiled with gcc
2.95.2 and verified on another system, kernel 2.4.18 compiled with 2.95.4
Attached is small program to test for this 'bug'
a syscall gets his data off the stack, the stack looks like:
saved(edx)
saved(ecx)
saved(ebx)
return_addres (somewhere in entry.S)
When the syscall is called.
the register came there through use of 'SAVE_ALL'.
After the syscall returns these registers are restored using RESTORE_ALL
and execution is transferred to userland again.
A short snippet of sys_poll, with irrelavant data removed.
sys_poll(struct pollfd *ufds, .. , ..) {
...
ufds++;
...
}
It seems that gcc in certain cases optimizes in such a way that it changes
the variable ufds as placed on the stack directly. Which results in saved(ebx)
being overwritten and thus in a changed %ebx on return from the system call.
I don't know if this is considered a bug, and if it is, from whom.
If it's not a bug it means low-level userland programs need to be rewritten
to store all registers on a syscall and restore them on return.
It shouldn't be a bug in gcc, since the C-standard doesn't talk about how to
pass variables and stuff. So it seems like a kernel(-gcc-interaction) bug.
To solve this issue 2 solutions spring to mind
1) add a flag to gcc to tell it that it shouldn't do this optimization, this
won't work with the gcc's already out there.
2) When calling a syscall explicitly push all variable an extra time, since
the code in entry.S doesn't know the amount of variables to a syscall it
needs to push all theoretical 6 parameters every time, a not so nice
overhead.
I hope someone can shed some light on this issue, i am not myself reading
the linux-kernel mailing list, and would like to be cc'd if possible (i'll
also check the archives so it's not 100% needed).
Thanks in advance,
Dvorak
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:26 EST