This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Questions and possible optimizations about sysv/linux/[x86_64|i386]/swapcontext.S


Hi, I'm reading the sources of ucontext
<https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/swapcontext.S;h=1110c479fad27829f1b1e480cf7520cf77d795f7;hb=HEAD#l46>
.

According to https://en.wikipedia.org/wiki/X86_calling_conventions#cdecl:

Integer values and memory addresses are returned in the EAX register
> <https://en.wikipedia.org/wiki/Processor_register>, floating point values
> in the ST0 x87 <https://en.wikipedia.org/wiki/X87> register. Registers
> EAX, ECX, and EDX are caller-saved, and the rest are callee-saved. The x87
> <https://en.wikipedia.org/wiki/X87> floating point registers ST0 to ST7
> must be empty (popped or freed) when calling a new function, and ST1 to ST7
> must be empty on exiting a function. ST0 must also be empty when not used
> for returning a value.


And https://en.wikipedia.org/wiki/X86_calling_conventions#System_V_AMD64_ABI
:

If the callee wishes to use registers RBX, RBP, and R12–R15, it must
> restore their original values before returning control to the caller. All
> other registers must be saved by the caller if it wishes to preserve their
> values.


Questions:

1. Since `swapcontext` is a function call, so it maybe not need to
save/restore
(fnstenv,stmxcsr/fldenv,ldmxcsr) the floating-point context. Is this
correct?
If it's wrong, where I could found the detailed calling convention about the
floating-point context ? Or a bug example after the (fnstenv,stmxcsr/fldenv,
ldmxcsr)
part is eliminated?

2. Could the save/restore (fnstenv,stmxcsr/fldenv,ldmxcsr) be eliminated if
all
the functions which uses fpu are leaf-node function (function which do not
call
any other function) ? If it is true, where I could found the detailed
reference?

3. Since `swapcontext` is a function call, so it is only necessary to
save/restore
RBX, RBP, R12–R15, RSP and RIP, the save/restore of RDI, RSI, RDX, RCX, R8
and R8 is quite useless and can be eliminated which could save at least
(6*8*2 = 96)
times memory read/writes in each swapcontext operation (Same optimization
also
exists in i386/swapcontext.S
<https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/i386/setcontext.S;h=a604fca0aceaa17f19f536bac46a1fc305f30860;hb=HEAD#l77>).
Is this correct?

4. In i386/swapcontext.S
<https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/i386/setcontext.S;h=a604fca0aceaa17f19f536bac46a1fc305f30860;hb=HEAD#l54>
:

54
<https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/i386/setcontext.S;h=a604fca0aceaa17f19f536bac46a1fc305f30860;hb=HEAD#l54>
        /* Restore the FS segment register.  We don't touch the GS register
55
<https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/i386/setcontext.S;h=a604fca0aceaa17f19f536bac46a1fc305f30860;hb=HEAD#l55>
           since it is used for threads.  */
56
<https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/i386/setcontext.S;h=a604fca0aceaa17f19f536bac46a1fc305f30860;hb=HEAD#l56>
        movl    oFS(%eax), %ecx
57
<https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/i386/setcontext.S;h=a604fca0aceaa17f19f536bac46a1fc305f30860;hb=HEAD#l57>
        movw    %cx, %fs

But there is no such save/restore about register fs in x86_64/swapcontext.S
<https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/x86_64/swapcontext.S;h=1110c479fad27829f1b1e480cf7520cf77d795f7;hb=HEAD#l46>
.
Is this a bug or it's no need to save/restore the register fs at all ? (The
save/restore of register fs in i386/swapcontext.S
<https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/i386/setcontext.S;h=a604fca0aceaa17f19f536bac46a1fc305f30860;hb=HEAD#l54>
could
also be elimianted
if the later is correct)

Thanks a lot :)

Remus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]