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/active-technology-and-dlls.md
+12-10Lines changed: 12 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,13 +12,15 @@ ms.author: "corob"
12
12
ms.workload: ["cplusplus"]
13
13
---
14
14
# Active Technology and DLLs
15
-
Active technology allows object servers to be completely implemented inside a DLL. This type of server is called an in-process server. MFC does not completely support in-process servers for all the features of visual editing, mainly because Active technology does not provide a way for a server to hook into the container's main message loop. MFC requires access to the container application's message loop to handle accelerator keys and idle-time processing.
16
-
17
-
If you are writing an Automation server and your server has no user interface, you can make your server an in-process server and put it completely into a DLL.
[DLLs in Visual C++](../build/dlls-in-visual-cpp.md)
15
+
16
+
Active technology allows object servers to be completely implemented inside a DLL. This type of server is called an in-process server. MFC does not completely support in-process servers for all the features of visual editing, mainly because Active technology does not provide a way for a server to hook into the container's main message loop. MFC requires access to the container application's message loop to handle accelerator keys and idle-time processing.
17
+
18
+
If you are writing an Automation server and your server has no user interface, you can make your server an in-process server and put it completely into a DLL.
Copy file name to clipboardExpand all lines: docs/build/aggregates-and-unions.md
+49-47Lines changed: 49 additions & 47 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,50 +12,52 @@ ms.author: "corob"
12
12
ms.workload: ["cplusplus"]
13
13
---
14
14
# Aggregates and Unions
15
-
Other types, such as arrays, structs, and unions, have stricter alignment requirements that ensure consistent aggregate and union storage and data retrieval. Here are the definitions for array, structure, and union:
16
-
17
-
- Array
18
-
19
-
Contains an ordered group of adjacent data objects. Each object is called an element. All elements within an array have the same size and data type.
20
-
21
-
- Structure
22
-
23
-
Contains an ordered group of data objects. Unlike the elements of an array, the data objects within a structure can have different data types and sizes. Each data object in a structure is called a member.
24
-
25
-
- Union
26
-
27
-
An object that holds any one of a set of named members. The members of the named set can be of any type. The storage allocated for a union is equal to the storage required for the largest member of that union, plus any padding required for alignment.
28
-
29
-
The following table shows the strongly suggested alignment for the scalar members of unions and structures.
- The alignment of an array is the same as the alignment of one of the elements of the array.
51
-
52
-
- The alignment of the beginning of a structure or a union is the maximum alignment of any individual member. Each member within the structure or union must be placed at its proper alignment as defined in the previous table, which may require implicit internal padding, depending on the previous member.
53
-
54
-
- Structure size must be an integral multiple of its alignment, which may require padding after the last member. Since structures and unions can be grouped in arrays, each array element of a structure or union must begin and end at the proper alignment previously determined.
55
-
56
-
- 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.
57
-
58
-
- 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.
59
-
60
-
## See Also
61
-
[Types and Storage](../build/types-and-storage.md)
15
+
16
+
Other types, such as arrays, structs, and unions, have stricter alignment requirements that ensure consistent aggregate and union storage and data retrieval. Here are the definitions for array, structure, and union:
17
+
18
+
- Array
19
+
20
+
Contains an ordered group of adjacent data objects. Each object is called an element. All elements within an array have the same size and data type.
21
+
22
+
- Structure
23
+
24
+
Contains an ordered group of data objects. Unlike the elements of an array, the data objects within a structure can have different data types and sizes. Each data object in a structure is called a member.
25
+
26
+
- Union
27
+
28
+
An object that holds any one of a set of named members. The members of the named set can be of any type. The storage allocated for a union is equal to the storage required for the largest member of that union, plus any padding required for alignment.
29
+
30
+
The following table shows the strongly suggested alignment for the scalar members of unions and structures.
- The alignment of an array is the same as the alignment of one of the elements of the array.
52
+
53
+
- The alignment of the beginning of a structure or a union is the maximum alignment of any individual member. Each member within the structure or union must be placed at its proper alignment as defined in the previous table, which may require implicit internal padding, depending on the previous member.
54
+
55
+
- Structure size must be an integral multiple of its alignment, which may require padding after the last member. Since structures and unions can be grouped in arrays, each array element of a structure or union must begin and end at the proper alignment previously determined.
56
+
57
+
- 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.
58
+
59
+
- 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.
60
+
61
+
## See Also
62
+
63
+
[Types and Storage](../build/types-and-storage.md)
Copy file name to clipboardExpand all lines: docs/build/alloca.md
+8-6Lines changed: 8 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,9 +11,11 @@ ms.author: "corob"
11
11
ms.workload: ["cplusplus"]
12
12
---
13
13
# alloca
14
-
[_alloca](../c-runtime-library/reference/alloca.md) is required to be 16-byte aligned and additionally required to use a frame pointer.
15
-
16
-
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).
17
-
18
-
## See Also
19
-
[Stack Usage](../build/stack-usage.md)
14
+
15
+
[_alloca](../c-runtime-library/reference/alloca.md) is required to be 16-byte aligned and additionally required to use a frame pointer.
16
+
17
+
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).
Copy file name to clipboardExpand all lines: docs/build/arm-exception-handling.md
+35-35Lines changed: 35 additions & 35 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -166,26 +166,26 @@ When the packed unwind format is insufficient to describe the unwinding of a fun
166
166
1. A 1 or 2-word header that describes the overall size of the .xdata structure and provides key function data. The second word is only present if the *Epilogue Count* and *Code Words* fields are both set to 0. The fields are broken out in this table:
167
167
168
168
|Word|Bits|Purpose|
169
-
|----------|----------|-------------|
170
-
|0|0-17|*Function Length* is an 18-bit field that indicates the total length of the function in bytes, divided by 2. If a function is larger than 512 KB, then multiple .pdata and .xdata records must be used to describe the function. For details, see the Large Functions section in this document.|
171
-
|0|18-19|*Vers* is a 2-bit field that describes the version of the remaining xdata. Only version 0 is currently defined; values of 1-3 are reserved.|
172
-
|0|20|*X* is a 1-bit field that indicates the presence (1) or absence (0) of exception data.|
173
-
|0|21|*E* is a 1-bit field that indicates that information that describes a single epilogue is packed into the header (1) rather than requiring additional scope words later (0).|
174
-
|0|22|*F* is a 1-bit field that indicates that this record describes a function fragment (1) or a full function (0). A fragment implies that there is no prologue and that all prologue processing should be ignored.|
175
-
|0|23-27|*Epilogue Count* is a 5-bit field that has two meanings, depending on the state of the *E* bit:<br /><br /> - If *E* is 0, this field is a count of the total number of exception scopes described in section 3. If more than 31 scopes exist in the function, then this field and the *Code Words* field must both be set to 0 to indicate that an extension word is required.<br />- If *E* is 1, this field specifies the index of the first unwind code that describes the only epilogue.|
176
-
|0|28-31|*Code Words* is a 4-bit field that specifies the number of 32-bit words required to contain all of the unwind codes in section 4. If more than 15 words are required for more than 63 unwind code bytes, this field and the *Epilogue Count* field must both be set to 0 to indicate that an extension word is required.|
177
-
|1|0-15|*Extended Epilogue Count* is a 16-bit field that provides more space for encoding an unusually large number of epilogues. The extension word that contains this field is only present if the *Epilogue Count* and *Code Words* fields in the first header word are both set to 0.|
178
-
|1|16-23|*Extended Code Words* is an 8-bit field that provides more space for encoding an unusually large number of unwind code words. The extension word that contains this field is only present if the *Epilogue Count* and *Code Words* fields in the first header word are both set to 0.|
179
-
|1|24-31|Reserved|
169
+
|----------|----------|-------------|
170
+
|0|0-17|*Function Length* is an 18-bit field that indicates the total length of the function in bytes, divided by 2. If a function is larger than 512 KB, then multiple .pdata and .xdata records must be used to describe the function. For details, see the Large Functions section in this document.|
171
+
|0|18-19|*Vers* is a 2-bit field that describes the version of the remaining xdata. Only version 0 is currently defined; values of 1-3 are reserved.|
172
+
|0|20|*X* is a 1-bit field that indicates the presence (1) or absence (0) of exception data.|
173
+
|0|21|*E* is a 1-bit field that indicates that information that describes a single epilogue is packed into the header (1) rather than requiring additional scope words later (0).|
174
+
|0|22|*F* is a 1-bit field that indicates that this record describes a function fragment (1) or a full function (0). A fragment implies that there is no prologue and that all prologue processing should be ignored.|
175
+
|0|23-27|*Epilogue Count* is a 5-bit field that has two meanings, depending on the state of the *E* bit:<br /><br /> - If *E* is 0, this field is a count of the total number of exception scopes described in section 3. If more than 31 scopes exist in the function, then this field and the *Code Words* field must both be set to 0 to indicate that an extension word is required.<br />- If *E* is 1, this field specifies the index of the first unwind code that describes the only epilogue.|
176
+
|0|28-31|*Code Words* is a 4-bit field that specifies the number of 32-bit words required to contain all of the unwind codes in section 4. If more than 15 words are required for more than 63 unwind code bytes, this field and the *Epilogue Count* field must both be set to 0 to indicate that an extension word is required.|
177
+
|1|0-15|*Extended Epilogue Count* is a 16-bit field that provides more space for encoding an unusually large number of epilogues. The extension word that contains this field is only present if the *Epilogue Count* and *Code Words* fields in the first header word are both set to 0.|
178
+
|1|16-23|*Extended Code Words* is an 8-bit field that provides more space for encoding an unusually large number of unwind code words. The extension word that contains this field is only present if the *Epilogue Count* and *Code Words* fields in the first header word are both set to 0.|
179
+
|1|24-31|Reserved|
180
180
181
181
2. After the exception data (if the *E* bit in the header was set to 0) is a list of information about epilogue scopes, which are packed one to a word and stored in order of increasing starting offset. Each scope contains these fields:
182
182
183
183
|Bits|Purpose|
184
-
|----------|-------------|
185
-
|0-17|*Epilogue Start Offset* is an 18-bit field that describes the offset of the epilogue, in bytes divided by 2, relative to the start of the function.|
186
-
|18-19|*Res* is a 2-bit field reserved for future expansion. Its value must be 0.|
187
-
|20-23|*Condition* is a 4-bit field that gives the condition under which the epilogue is executed. For unconditional epilogues, it should be set to 0xE, which indicates "always". (An epilogue must be entirely conditional or entirely unconditional, and in Thumb-2 mode, the epilogue begins with the first instruction after the IT opcode.)|
188
-
|24-31|*Epilogue Start Index* is an 8-bit field that indicates the byte index of the first unwind code that describes this epilogue.|
184
+
|----------|-------------|
185
+
|0-17|*Epilogue Start Offset* is an 18-bit field that describes the offset of the epilogue, in bytes divided by 2, relative to the start of the function.|
186
+
|18-19|*Res* is a 2-bit field reserved for future expansion. Its value must be 0.|
187
+
|20-23|*Condition* is a 4-bit field that gives the condition under which the epilogue is executed. For unconditional epilogues, it should be set to 0xE, which indicates "always". (An epilogue must be entirely conditional or entirely unconditional, and in Thumb-2 mode, the epilogue begins with the first instruction after the IT opcode.)|
188
+
|24-31|*Epilogue Start Index* is an 8-bit field that indicates the byte index of the first unwind code that describes this epilogue.|
189
189
190
190
3. After the list of epilogue scopes comes an array of bytes that contain unwind codes, which are described in detail in the Unwind Codes section in this article. This array is padded at the end to the nearest full word boundary. The bytes are stored in little-endian order so that they can be directly fetched in little-endian mode.
191
191
@@ -349,16 +349,16 @@ A more complex special case of function fragments is *shrink-wrapping*, a techni
349
349
350
350
```asm
351
351
ShrinkWrappedFunction
352
-
push {r4, lr} ; A: save minimal non-volatiles
353
-
sub sp, sp, #0x100 ; A: allocate all stack space up front
354
-
... ; A:
355
-
add r0, sp, #0xE4 ; A: prepare to do the inner save
356
-
stm r0, {r5-r11} ; A: save remaining non-volatiles
357
-
... ; B:
358
-
add r0, sp, #0xE4 ; B: prepare to do the inner restore
Shrink-wrapped functions are typically expected to pre-allocate the space for the extra register saves in the regular prologue, and then perform the register saves by using `str` or `stm` instead of `push`. This keeps all stack-pointer manipulation in the function’s original prologue.
@@ -377,14 +377,14 @@ An alternative approach can also work if the stack manipulation done before ente
377
377
378
378
```asm
379
379
ShrinkWrappedFunction
380
-
push {r4, lr} ; A: save minimal non-volatile registers
381
-
sub sp, sp, #0xE0 ; A: allocate minimal stack space up front
382
-
... ; A:
383
-
push {r4-r9} ; A: save remaining non-volatiles
384
-
... ; B:
385
-
pop {r4-r9} ; B: restore remaining non-volatiles
386
-
... ; C:
387
-
pop {r4, pc} ; C: restore non-volatile registers
380
+
push {r4, lr} ; A: save minimal non-volatile registers
381
+
sub sp, sp, #0xE0 ; A: allocate minimal stack space up front
382
+
... ; A:
383
+
push {r4-r9} ; A: save remaining non-volatiles
384
+
... ; B:
385
+
pop {r4-r9} ; B: restore remaining non-volatiles
386
+
... ; C:
387
+
pop {r4, pc} ; C: restore non-volatile registers
388
388
```
389
389
390
390
The key here is that on each instruction boundary, the stack is fully consistent with the unwind codes for the region. If an unwind occurs before the inner push in this example, it is considered part of region A, and only the region A prologue is unwound. If the unwind occurs after the inner push, it is considered part of region B, which has no prologue, but has unwind codes that describe both the inner push and the original prologue from region A. Similar logic holds for the inner pop.
@@ -741,4 +741,4 @@ Function:
741
741
## See also
742
742
743
743
[Overview of ARM ABI Conventions](../build/overview-of-arm-abi-conventions.md)<br/>
744
-
[Common Visual C++ ARM Migration Issues](../build/common-visual-cpp-arm-migration-issues.md)
744
+
[Common Visual C++ ARM Migration Issues](../build/common-visual-cpp-arm-migration-issues.md)
0 commit comments