Index
> Main > Stack Realignment "Techniques"Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8 Next |
| Author |
|
|
system error 02 Sep 2017, 05:02
This is the most INCOMPETENT IDIOT I've ever seen in my existence on this board.
Furs: The registers must be saved the callee No my b1tchslapping question to your INCOMPETENT face: WHO IS CALLEE?? Callee is my code and your code!! Don't you ever get it after I taught you the same thing in over 4 full threads? It's not required by the ABI. It is required by YOUR CODE. It's the user's own requirement and choice if you want to save it or not. So, it is not part of the ABI's requirement. Try scratching XMM15 or R15 in calling a MessageBox (an ABI-compliant API) in your code and see if it returns a seg fault or violates any MS64 ABI! TRY NOW and let everybody here see how incompetent you're in interpreting a simple technical documentation! OMG hahahaha xD |
|||
02 Sep 2017, 05:02 |
|
|
system error 02 Sep 2017, 05:05
And no Furs..... the MS64 ABI never defines, uses or specifies the AVX instruction set.
hahahaha xD |
|||
|
02 Sep 2017, 05:05 |
|
|
system error 02 Sep 2017, 05:46
I think I am done schooling this incompetent idiot. Sorry for terrorizing your thread and making you look like a completely helpless 'expert'! It was fun trolling you anyway. hahahaha xD
|
|||
|
02 Sep 2017, 05:46 |
|
|
Furs 02 Sep 2017, 14:46
lol man, are you seriously so dense to not understand that ABI specifies an interface? Even the name says: Application Binary INTERFACE. This means *both* functions adhering to it must comply to it (an interface establishes rules for both entities so they can talk to each other, BOTH caller and callee).
The ABI doesn't care how you save the registers. It requires that they are unchanged when your function exits, because that's what the calling function expects. So if your function uses them, they *must* be saved as the ABI says, because the caller expects them to be unchanged. Period. An ABI dictates the behavior of both your function AND the caller's (when calling it). They must both *agree* on the same rules. You don't understand shit. Oh and ABI is not API. It's not just Windows API functions that adhere to the ABI. For example, the function I gave as example eventually will be a callback function for a DSP plugin, and the caller obviously expects that XMM6-15 are unchanged when calling my function because it assumes it uses the MS ABI (which says you must save them, contrary to the pure bullshit you said). Frankly who cares about explaining it anyway? GCC generated that code. The GCC you said "is not coded by idiots", so it must be doing it right. That makes you the idiot, here, using your own words and logic. You dare question the non-idiot GCC? 
And yeah we all know the "omg I spoke so much bullshit and got schooled so hard and now I'll just say I was trolling all along hahahahaha!!" cop-out  |
|||
|
02 Sep 2017, 14:46 |
|
|
system error 03 Sep 2017, 07:27
OMG! hahaha. This dude above me is really that incompetent in interpreting a simple technical doc ;D
No Furs, what MS asks you to do is to use your common sense in dealing with non-volatile registers. It's not a specifc requirement. This "common sense" exists across all calling conventions. It also applies to general coding techniques as well. It is NOT a defining characteristics of MS64-ABI. It exists in stdcall, vectorcall, ccall or even in general use of the registers. This "common sense" is translated into pre-school language: "If u want to preserve it and use it later, SAVE IT. If not, don't bother. You're not breaking any conventions if you don't do that"! And I stated to you when I b1tchslapped you in other threads, the requirements for MS-64 ABI are only 3: 1. Stack must be aligned to 16 2. Create shadow space 3. Integers in GPR. Floats in XMM registers, alternating fashion if both exists. Others are just common sense. And NO. MS-64 bit ABI has no official support for AVX instructions and registers like you tried to convince the unsuspecting audience via your "expert garbage" talks!! NOOOOO!! No align-32! No YMM. No "vzeroupper". No no no!! <============= hahahaha xD |
|||
|
03 Sep 2017, 07:27 |
|
|
system error 03 Sep 2017, 08:08
Furs wrote: l[The GCC you said "is not coded by idiots", so it must be doing it right. That makes you the idiot, here, using your own words and logic. You dare question the non-idiot GCC? Unless you come up with your own C-compiler, calling them idiots is not valid, if it comes from your BIG MOUTH. GCC is used by millions of programmers and form the back end of other high-level languages. You??? You don't even know the difference between a signed and unsigned integer. Look how I b1tchslapped your incompetent face in this C-specific thread using a C code! https://board.flatassembler.net/topic.php?t=19904&view=next Your pathetic "expert" solution to Y2038 problem was to change the date from your "DATE" applications of the OS? OMG!! hahahaha xD Wasn't that embarrassing? xD |
|||
|
03 Sep 2017, 08:08 |
|
|
sinsi 03 Sep 2017, 08:15
Quote: ...what MS asks you to do is to use your common sense in dealing with non-volatile registers. Pretty specific actually https://msdn.microsoft.com/en-us/library/6t169e9c.aspx Quote: The registers RBX, RBP, RDI, RSI, RSP, R12, R13, R14, and R15 are considered nonvolatile and must be saved and restored by a function that uses them. |
|||
|
03 Sep 2017, 08:15 |
|
|
system error 03 Sep 2017, 08:35
sinsi wrote:
That recommendation also exists in other calling conventions. Even without calling convention, anybody that uses a register that must be preserved, should make the effort in saving and restoring them. This is common sense, regardless of calling convention or not. If you scratch a non-volatile register and have no intention of preserving them then you don't have to. In both cases, you're not violating any specific requirement of the ABI and will not throw any segmentation fault at you. ABI-compliant APIs DO NOT RELY on the states of the non-volatile registers. That's the other way of saying it. |
|||
|
03 Sep 2017, 08:35 |
|
|
revolution 03 Sep 2017, 08:45
Maybe you are talking in crossed purposes here. There are two sides to the register preservation. The input values to a procedure do not have any defined values in the non-volatile registers. But the output values from a procedure absolutely must preserve the original input values of the non-volatile registers, else you will be sorry. This is actually a requirement of the calling convention. It isn't subject to the whims of "common sense", it proscribes the expected behaviour.
|
|||
|
03 Sep 2017, 08:45 |
|
|
system error 03 Sep 2017, 08:48
revolution wrote: But the output values from a procedure absolutely must preserve the original input values of the non-volatile registers, else you will be sorry. |
|||
|
03 Sep 2017, 08:48 |
|
|
revolution 03 Sep 2017, 08:50
system error wrote:
|
|||
|
03 Sep 2017, 08:50 |
|
|
system error 03 Sep 2017, 08:56
revolution wrote:
It's not a requirement. It's a recommendation for the user's side. Just because you found the word "must" in it doesn't make one a requirement. It's a general way of saving non-volatile registers, convention or not. The techniques is there ever since 8088 era. |
|||
|
03 Sep 2017, 08:56 |
|
|
sinsi 03 Sep 2017, 09:04
Quote: It's not a requirement. That's just wrong. The official MS ABI specs say if you use a nonvolatile register you must preserve it. Common sense would be saving any register you use, not just nonvolatile. |
|||
|
03 Sep 2017, 09:04 |
|
|
revolution 03 Sep 2017, 09:07
system error wrote: It's not a requirement. It's a recommendation for the user's side. |
|||
|
03 Sep 2017, 09:07 |
|
|
system error 03 Sep 2017, 09:15
sinsi wrote: That's just wrong. The official MS ABI specs say if you use a nonvolatile register you must preserve it. revolution wrote:
No. Let's see this pseudocode; Code: mov r15,0xBABE fastcall [MessageBoxA],rcx,rdx,r8,r9 fastcall [printf],msg mov r15,0 mov rcx,0 call [ExitProcess] Now tell me how's whoring up R15 to different values would prevent the MS ABI being implemented and run successfully in this case? Why would I bother saving R15 if I don't want it to be preserved? Am I violating the ABI just because I'm scratching R15 and do not preserve its value? How's my code be in any non-compliant state, if I don't preserve R15? You're reading MSDN without using your common sense or taking everything on face-value. Be SMART. Last edited by system error on 03 Sep 2017, 09:21; edited 1 time in total |
|||
|
03 Sep 2017, 09:15 |
|
|
revolution 03 Sep 2017, 09:20
It is the APIs that preserve R15 for you. The APIs don't know if you need the value in R15 or not, but they will follow the ABI and make sure to return it back to you unchanged. So you can be sure that the value in R15 after those two API calls is still the same.
And you must preserve R15 for any API that calls your code. If you have a callback procedure then be sure to use your "common sense" and preserve all the non-volatile registers. |
|||
|
03 Sep 2017, 09:20 |
|
|
system error 03 Sep 2017, 09:34
revolution wrote: It is the APIs that preserve R15 for you. The APIs don't know if you need the value in R15 or not, but they will follow the ABI and make sure to return it back to you unchanged. So you can be sure that the value in R15 after those two API calls is still the same. That's just a general technique commonly used in stdcall as well. That doesn't make it any more "requirement" in MS-64-bit ABI. Quote: And you must preserve R15 for any API that calls your code. If you have a callback procedure then be sure to use your "common sense" and preserve all the non-volatile registers. No. I don't have to. Whoring up R15 doesn't make any seg fault or to make my code be in any "non-compliant" state. I preserve R15 only where and when I think it should be preserved. The subsequent call to [printf] simply doesn't care if R15 is scratch of not. Geezzz, where are you guys coming from? xD |
|||
|
03 Sep 2017, 09:34 |
|
|
sinsi 03 Sep 2017, 09:39
Try changing RBX (or RBP, RSI, RDI etc.) in your windows procedure, see how far you get before the boom.
|
|||
|
03 Sep 2017, 09:39 |
|
|
system error 03 Sep 2017, 09:49
sinsi wrote: Try changing RBX (or RBP, RSI, RDI etc.) in your windows procedure, see how far you get before the boom. Calling two successive API's MessageBoxA and printf don't require any non-volatiles involved. Why should I bother changing them in the first place? See, this is where you're missing the whole point of "recommendation" vs "requirement". If you don't align the stack to 16, you'll be boomed when calling MessageBoxA If you don't allocate stack space, your'll be boomed in the face ... soon enough. If you use the wrong registers, you'll be boomed as well. That's 3 requirements of MS64 ABI. Violate any of these and you'll be BOOMED! Scratching R15 will not create any boom if you're not interested in using or preserving it. You guys are way funnier than I thought xD |
|||
|
03 Sep 2017, 09:49 |
|
| Goto page Previous 1, 2, 3, 4, 5, 6, 7, 8 Next < Last Thread | Next Thread > |
Forum Rules:
|