flat assembler
Message board for the users of flat assembler.
Index
> Linux > What calling convention in Linux? |
Author |
|
revolution 19 Apr 2018, 09:25
Can you be more specific about what you are asking?
|
|||
19 Apr 2018, 09:25 |
|
ProMiNick 19 Apr 2018, 11:10
all linux examles on this forum could be simplificated with macros to this form:
Code: format ELF executable 3 ; format ELF64 executable 3 entry start ;settings = nolink(int|syscall)|dylink ;include architecture segment readable executable Start: stackalign16 lincall write, stdout, ADDR msg, msgsize lincall exit, 0 segment readable writeable msg db 'Hello World!', 10 msgsize = $-msg Code: format ELF ; format ELF64 public main ;settings = nolink (int|syscall)|dylink ;include architecture extrn write extrn exit section '.code' executable align 64 main: lincall write, stdout, ADDR msg, msgsize lincall exit, 0 section '.data' writeable align 64 msg db 'Hello World!', 10 msgsize = $-msg but there is no macroses for linux calls provided. Why? And why so few examples for linux? Even in fasm package for linux? Why there is no GUI linux examples? (because in linux there `re different GUI engines?) so, why not realized one or couple of them? _________________ I don`t like to refer by "you" to one person. My soul requires acronim "thou" instead. |
|||
19 Apr 2018, 11:10 |
|
redsock 19 Apr 2018, 20:02
Page 10 of this excellent resource is highly recommended: http://www.agner.org/optimize/calling_conventions.pdf
IMO, a "lincall" macro is overkill since the register order is pretty easy to remember/recognise/identify. |
|||
19 Apr 2018, 20:02 |
|
fasmnewbie 20 Apr 2018, 04:19
It's not easy to standardize anything on Linux beyond the kernel. Kernel services int 80h uses 32-bit fastcall but C uses CDECL. The problem: Any descriptions of the API uses C as the main interface, which in turn was wrapped around fastcall int 80h services.
For 64-bit, the problem is with the "red zone". Red zone is not easy to define with high-level macros (it is still possible, though, if people insist). Red zone is implicit or based rather on assumptions of the last RSP movement following a CALL instruction. This alone opens up countless ways of implemention / interpretations by different people or vendors. If you debug some 64-bit C program, you'll find that C addresses some local data on stack that you did not allocate yourself. That's red zone. Should FASM use this red zone? What would happen if the function itself use the redzone to place its own data? How much stack be allocated off the redzone should there exists LOCALS data beyond 128-byte of such high-level PROC? Now that's the problem: It's too implementation-dependant. You probably need to use many command line switches to deal with PROC's redzone. ELF64 executable don't have such luxury - you need to come up with a fixed PROC setup. That's a nasty portablity problem too, if for example your code is used by others which do / do not observe red zone. Your LOCALS data will suffer due to stack corruptions. Here's a short discussion on how nightmarish it is to implement a standardized high-level proc on 64-bit Linux: https://stackoverflow.com/questions/37941779/why-do-we-need-stack-allocation-when-we-have-a-red-zone So the best and the most practical choice on Linux 64 is to stay low. |
|||
20 Apr 2018, 04:19 |
|
ProMiNick 20 Apr 2018, 13:10
It is not all clear...: StackTop is allways located at [rsp+redzone], but times before that redzone was unexisted, so StackTop was allways pointed by [rsp+0], Now in linux redzone not +0, but +128.
In code: Code: mov [rsp+1],rbx ; redzone in rsp+0 to rsp+128, for preserving used redzone from rsp+1 to rsp+1+sizeof(rsp), so ... ; ...here we have up to 119 stack bytes for calls, passing parameters, interupts and so on before preserved rbx will be erased mov rbx,[rsp+1] If I correct red zone is nice feature. But dangerous for newby programmers. But it has no meaning to macros for linux. In assemblers (not in HLL) addressing relative to esp was allways responsibility of programmer , not of compiler (or macros in it). _________________ I don`t like to refer by "you" to one person. My soul requires acronim "thou" instead. |
|||
20 Apr 2018, 13:10 |
|
revolution 20 Apr 2018, 13:20
I think the red zone is from [RSP-128] to [RSP-1]. [RSP+0] and up is the normal stack zone.
|
|||
20 Apr 2018, 13:20 |
|
ProMiNick 20 Apr 2018, 13:33
continue: Am I correct?:
Int 80h - only for linuxes where enabled 32bit elfs? Int 80h incompatibable with stack in 64 bit? For 64bit Linux syscall more preferable in all cases? with dissabled support of 32 bit it is only choise? sysenter is only for 32 bit Linux, unsupported in all 64 linux? obsolete even in 32 bit versions? And, is there something exept kernel that goes from one linux version to another? I mean some *.so files? |
|||
20 Apr 2018, 13:33 |
|
ProMiNick 20 Apr 2018, 13:55
to Revolution, push,call,int,syscall not overrides [rsp] value. the only way how it can be realized these instructions override [rsp+128] value instead.
Test: where stored value in callee of retaddr in [rsp], or in [rsp+128] for case callee has no rbp frame, has no params, not preserves registers. redzone cant be located in [rsp-128] because in any place we could use redzone push rax mov [rsp],rcx ;rcx redzoned ; rsp points top of redzone not top of stack ... mov rcx,[rsp] ;rcx restored pop rax ; original rax will be restored Last edited by ProMiNick on 20 Apr 2018, 14:04; edited 1 time in total |
|||
20 Apr 2018, 13:55 |
|
revolution 20 Apr 2018, 14:01
ProMiNick wrote: to Revolution, push,call,int,syscall not overrides [rsp] value. the only way how it can be realized these instructions override [rsp+128] value instead. {RSP-c] is below the normal stack and is where the red zone is defined. |
|||
20 Apr 2018, 14:01 |
|
ProMiNick 20 Apr 2018, 14:06
so redzone not hardware feature? it HLL trick?
|
|||
20 Apr 2018, 14:06 |
|
ProMiNick 20 Apr 2018, 14:09
what about code from https://stackoverflow.com/questions/37941779/why-do-we-need-stack-allocation-when-we-have-a-red-zone
if I remove sub rsp,32 and add rsp,32 as they not needed for redzone, and remove rbp frame -not used here - left this Code: function: mov QWORD PTR [rsp], rcx ; copy rcx into our scratch area - this shouldn`t affect ret address mov QWORD PTR [rsp+8], rdx ; copy rdx into our scratch area ; ...do something that clobbers rcx and rdx... mov rcx, [rsp] ; retrieve original value of rcx from our scratch area mov rdx, [rsp+8] ; retrieve original value of rdx from our scratch area ret |
|||
20 Apr 2018, 14:09 |
|
revolution 20 Apr 2018, 14:20
ProMiNick wrote: so redzone not hardware feature? it HLL trick? |
|||
20 Apr 2018, 14:20 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.