| \u00a0<\/td>\n | <\/td>\n<\/tr>\n | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| return address<\/td>\n | <\/td>\n<\/tr>\n | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
previous r11<\/var><\/td>\n| \u2190 r11<\/var> (frame chain)<\/td>\n<\/tr>\n | \u22ee<\/td>\n | <\/td>\n<\/tr>\n | stack param<\/td>\n | \u2190 sp<\/var><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n | On entry to the function, lr<\/var> contains the return address. After pushing the r4<\/var> through r7<\/var>, r11<\/var>, and lr<\/var> registers, we have<\/p>\n The incoming lr<\/var> is saved on the stack, so we know where to return to when we’re done. The incoming r11<\/var> is the head of the linked list of stack frames, and we push it onto the stack so we can create a new node on the linked list. And we also push four saved registers so that they are available for us to use in the function.<\/p>\n It is not a coincidence that the convention is to use r11<\/var> as the frame pointer. This puts it on the stack right next to the lr<\/var> register, so that the return address is right next to the frame pointer.\u00b9<\/p>\n The next instruction calculates r11<\/var> as sp<\/var> + <\/p>\n And the last step in the prologue is allocating additional space for local variables and outbound parameters.<\/p>\n <\/p>\n Windows does not require that the r11<\/var> register be the head of a linked list of stack frames,\u00b2 but all Windows system components are compiled with frame pointers enabled: It makes debugging a lot easier (since the To return from the function, we run things in reverse:<\/p>\n The The obvious part of the The less obvious part is that we pop the original r11<\/var> back into r11<\/var>, which has the effect of deleting the frame from the linked list of stack frames.<\/p>\n The totally magic part is that we pop the return address (which was originally passed in lr<\/var>) directly into the pc<\/var> register. Writing to the pc<\/var> register acts like a jump instruction, so this jumps to the return address after the work of this instruction is complete.\u00b3<\/p>\n The last thing the The standard prologue looks like this:<\/p>\n I call this the standard prologue because the function unwind metadata is optimized for prologues that take this form.<\/p>\n Next time, we’ll look at some tweaks and optimizations to this general pattern.<\/p>\n \u00b9 Now, there are two other registers in between r11<\/var> and lr<\/var>: We have the intraprocedure call scratch register r12<\/var>, and we have the stack pointer sp<\/var> (also known as r13<\/var>). Fortunately, we can avoid having to push either of these two registers. The intraprocedure call scratch register is a volatile register that is not expected to be preserved, and the stack pointer is preserved either by keeping track of its value through the function (subtracting a frame on entry and adding it back on exit), or recovering it from the frame pointer. You aren’t ever tempted to push the stack pointer because you cannot reliably pop it back anyway.<\/p>\n \u00b2 The documentation is a bit unclear on this. In the discussion of the integer registers, it says<\/p>\n Windows uses r11 for fast-walking of the stack frame. For more information, see the Stack Walking section. Because of this requirement, r11 must point to the topmost link in the chain at all times. Do not use r11 for general purposes\u2014your code will not generate correct stack walks during analysis.<\/p><\/blockquote>\n The use of the words requirement<\/i>, must<\/i> and do not<\/i> imply that using r11<\/var> as the frame pointer is mandatory.<\/p>\n But then when you get to the Stack Walking section, it says<\/p>\n Generally, the r11 register points to the next link in the chain, which is an {r11, lr} pair that specifies the pointer to the previous frame on the stack and the return address. We recommend that your code also enable frame pointers for improved profiling and tracing.<\/p><\/blockquote>\n This time, the use of the words generally<\/i> and recommend<\/i> imply that using r11<\/var> as the frame pointer is merely a suggestion, albeit a strong suggestion.<\/p>\n I’m not sure who is right, but I’m going to assume that the use of r11<\/var> as a frame pointer is strongly recommended<\/i> rather than required<\/i>. I’m interpreting the first paragraph by adding the underlined clarifying words:<\/p>\n Windows uses r11 for fast-walking of the stack frame. For more information, see the Stack Walking section. Because of this requirement in order for fast-walking to work<\/u>, r11 must point to the topmost link in the chain at all times if you want fast-walking to work<\/u>. If you know what’s good for you<\/u>, do not use r11 for general purposes\u2014if you ignore this advice, then<\/u> your code will not generate correct stack walks during analysis.<\/p><\/blockquote>\n \u00b3 It is totally not a coincidence that lr<\/var> and pc<\/var> are adjacent registers. This allows you to push a set of registers including lr<\/var>, and then pop the same set of registers, but substituting pc<\/var> for lr<\/var>.<\/p>\n","protected":false},"excerpt":{"rendered":" Implementing the receiving end of the calling convention.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[2],"class_list":["post-105332","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-history"],"acf":[],"blog_post_summary":" Implementing the receiving end of the calling convention.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105332","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=105332"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105332\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=105332"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=105332"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=105332"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} |