You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/build/aggregates-and-unions.md
+2-2Lines changed: 2 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -49,8 +49,8 @@ The following aggregate alignment rules apply:
49
49
50
50
- It is possible to align data in such a way as to be greater than the alignment requirements as long as the previous rules are maintained.
51
51
52
-
- An individual compiler may adjust the packing of a structure for size reasons. For example [/Zp (Struct Member Alignment)](../build/reference/zp-struct-member-alignment.md) allows for adjusting the packing of structures.
52
+
- An individual compiler may adjust the packing of a structure for size reasons. For example [/Zp (Struct Member Alignment)](reference/zp-struct-member-alignment.md) allows for adjusting the packing of structures.
53
53
54
54
## See Also
55
55
56
-
[Types and Storage](../build/types-and-storage.md)
[_alloca](../c-runtime-library/reference/alloca.md) is required to be 16-byte aligned and additionally required to use a frame pointer.
10
10
11
-
The stack that is allocated needs to include space below it for parameters of subsequently called functions, as discussed in [Stack Allocation](../build/stack-allocation.md).
11
+
The stack that is allocated needs to include space below it for parameters of subsequently called functions, as discussed in [Stack Allocation](stack-allocation.md).
For frame chained functions, the fp and lr pair can be saved at any position in the local variable area depending on optimization considerations. The goal is to maximize the number of locals that can be reached by one single instruction based on frame pointer (r29) or stack pointer (sp). However for `alloca` functions, it must be chained and r29 must point to the bottom of stack. To allow for better register-pair-addressing-mode coverage, nonvolatile register aave areas are positioned at the top of the Local area stack. Here are examples that illustrate several of the most efficient prolog sequences. For the sake of clarity and better cache locality, the order of storing callee-saved registers in all canonical prologs is in "growing up" order. `#framesz` below represents the size of entire stack (excluding alloca area). `#localsz` and `#outsz` denote local area size (including the save area for the \<r29, lr> pair) and outgoing parameter size, respectively.
52
52
@@ -181,7 +181,7 @@ The .pdata records are an ordered array of fixed-length items which describe eve
181
181
182
182
Each .pdata record for ARM64 is 8 bytes in length. The general format of the each record places the 32-bit RVA of the function start in the first word, followed by a second with that contains either a pointer to a variable-length .xdata block, or a packed word describing a canonical function unwinding sequence.
183
183
184
-

184
+

185
185
186
186
The fields are as follows:
187
187
@@ -197,7 +197,7 @@ The fields are as follows:
197
197
198
198
When the packed unwind format is insufficient to describe the unwinding of a function, a variable-length .xdata record must be created. The address of this record is stored in the second word of the .pdata record. The format of the .xdata is a packed variable-length set of words:
199
199
200
-

200
+

201
201
202
202
This data is broken into four sections:
203
203
@@ -328,7 +328,7 @@ For functions whose prologs and epilogs follow the canonical form described belo
328
328
329
329
The format of a .pdata record with packed unwind data looks like this:
330
330
331
-

331
+

332
332
333
333
The fields are as follows:
334
334
@@ -621,4 +621,4 @@ Note: EpilogStart Index [4] points to the middle of Prolog unwind code (partiall
621
621
## See also
622
622
623
623
[Overview of ARM64 ABI conventions](arm64-windows-abi-conventions.md)<br/>
Copy file name to clipboardExpand all lines: docs/build/arm64-windows-abi-conventions.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -197,7 +197,7 @@ The default kernel mode stack in Windows is six pages (24k). Pay extra attention
197
197
198
198
## Stack walking
199
199
200
-
Code within Windows is compiled with frame pointers enabled ([/Oy-](../build/reference/oy-frame-pointer-omission.md)) to enable fast stack walking. The upshot of this is that x29 (fp) in general points to the next link in the chain, which is an {fp,lr} pair indicating the pointer to the previous frame on the stack and the return address. Third-party code is encouraged to enable frame pointers as well in order to allow for improved profiling and tracing.
200
+
Code within Windows is compiled with frame pointers enabled ([/Oy-](reference/oy-frame-pointer-omission.md)) to enable fast stack walking. The upshot of this is that x29 (fp) in general points to the next link in the chain, which is an {fp,lr} pair indicating the pointer to the previous frame on the stack and the return address. Third-party code is encouraged to enable frame pointers as well in order to allow for improved profiling and tracing.
201
201
202
202
## Exception unwinding
203
203
@@ -215,5 +215,5 @@ Note that the cycle counter here is a true cycle counter, not a wall clock, and
215
215
216
216
## See also
217
217
218
-
[Common Visual C++ ARM Migration Issues](../build/common-visual-cpp-arm-migration-issues.md)<br/>
An isolated application depends only on side-by-side assemblies and binds to its dependencies using a manifest. It is not required for your application to be fully isolated in order to run properly on Windows; however, by investing in making your application fully isolated, you may save time if you need to service your application in the future. For more information on the advantages of making your application fully isolated, see [Isolated Applications](/windows/desktop/SbsCs/isolated-applications).
10
10
11
-
When you build your native C/C++ application using Visual C++, by default the Visual Studio project system generates a manifest file that describes your application's dependencies on Visual C++ libraries. If these are the only dependencies your application has, then it becomes an isolated application as soon as it is rebuilt with Visual Studio. If your application is using other libraries at runtime, then you may need to rebuild those libraries as side-by-side assemblies following the steps described in [Building C/C++ Side-by-side Assemblies](../build/building-c-cpp-side-by-side-assemblies.md).
11
+
When you build your native C/C++ application using Visual C++, by default the Visual Studio project system generates a manifest file that describes your application's dependencies on Visual C++ libraries. If these are the only dependencies your application has, then it becomes an isolated application as soon as it is rebuilt with Visual Studio. If your application is using other libraries at runtime, then you may need to rebuild those libraries as side-by-side assemblies following the steps described in [Building C/C++ Side-by-side Assemblies](building-c-cpp-side-by-side-assemblies.md).
12
12
13
13
## See Also
14
14
15
-
[Concepts of Isolated Applications and Side-by-side Assemblies](../build/concepts-of-isolated-applications-and-side-by-side-assemblies.md)<br/>
16
-
[Building C/C++ Isolated Applications and Side-by-side Assemblies](../build/building-c-cpp-isolated-applications-and-side-by-side-assemblies.md)
15
+
[Concepts of Isolated Applications and Side-by-side Assemblies](concepts-of-isolated-applications-and-side-by-side-assemblies.md)<br/>
16
+
[Building C/C++ Isolated Applications and Side-by-side Assemblies](building-c-cpp-isolated-applications-and-side-by-side-assemblies.md)
0 commit comments