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-insights/tutorials/build-insights-function-view.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
@@ -63,7 +63,7 @@ When the build finishes, an Event Trace Log (ETL) file opens. It's saved in the
63
63
In the window for the ETL file, choose the **Functions** tab. It shows the functions that were compiled and the time it took to generate the code for each function. If the amount of code generated for a function is negligible, it won't appear in the list to avoid degrading build event collection performance.
64
64
65
65
:::image type="complex" source="./media/functions-view-before-fix.png" alt-text="Screenshot of the Build Insights Functions view file.":::
66
-
In the Function Name column, performPhysicsCalculations() is highlighted and marked with a fire icon.:::
66
+
In the Function Name column, performPhysicsCalculations() is highlighted and marked with a fire icon.
67
67
:::image-end:::
68
68
69
69
The **Time [sec, %]** column shows how long it took to compile each function in [wall clock responsibility time (WCTR)](https://devblogs.microsoft.com/cppblog/faster-cpp-builds-simplified-a-new-metric-for-time/#:~:text=Today%2C%20we%E2%80%99d%20like%20to%20teach%20you%20about%20a,your%20build%2C%20even%20in%20the%20presence%20of%20parallelism). This metric distributes the wall clock time among functions based on their use of parallel compiler threads. For example, if two different threads are compiling two different functions simultaneously within a one-second period, each function's WCTR is recorded as 0.5 seconds. This reflects each function's proportional share of the total compilation time, taking into account the resources each consumed during parallel execution. Thus, WCTR provides a better measure of the impact each function has on the overall build time in environments where multiple compilation activities occur simultaneously.
@@ -112,7 +112,7 @@ We rerun Build Insights from the main menu by choosing **Build** > **Run Build I
112
112
The build time goes from 25.181 seconds to 13.376 seconds and the `performPhysicsCalculations` function doesn't show up anymore in the **Functions** view because it doesn't contribute enough to the build time to be counted.
113
113
114
114
:::image type="complex" source="./media/functions-view-after-fix.png" alt-text="Screenshot of the 2D vector header file.":::
115
-
In the Function Name column, performPhysicsCalculations() is highlighted and marked with a fire icon.:::
115
+
In the Function Name column, performPhysicsCalculations() is highlighted and marked with a fire icon.
116
116
:::image-end:::
117
117
118
118
The Diagnostics Session time is the overall time it took do the build plus any overhead for gathering the Build Insights data.
@@ -29,11 +28,8 @@ On functions that the compiler recognizes as subject to buffer overrun problems,
29
28
A buffer overrun security check is performed on a *GS buffer*. A GS buffer can be one of these:
30
29
31
30
- An array that is larger than 4 bytes, has more than two elements, and has an element type that is not a pointer type.
32
-
33
31
- A data structure whose size is more than 8 bytes and contains no pointers.
34
-
35
-
- A buffer allocated by using the [_alloca](../../c-runtime-library/reference/alloca.md) function.
36
-
32
+
- A buffer allocated by using the [`_alloca`](../../c-runtime-library/reference/alloca.md) function.
37
33
- Any class or structure that contains a GS buffer.
38
34
39
35
For example, the following statements declare GS buffers.
@@ -57,16 +53,14 @@ struct { int a; int b; };
57
53
58
54
## Initialize the Security Cookie
59
55
60
-
The **/GS** compiler option requires that the security cookie be initialized before any function that uses the cookie is run. The security cookie must be initialized immediately on entry to an EXE or DLL. This is done automatically if you use the default VCRuntime entry points: mainCRTStartup, wmainCRTStartup, WinMainCRTStartup, wWinMainCRTStartup, or _DllMainCRTStartup. If you use an alternate entry point, you must manually initialize the security cookie by calling [__security_init_cookie](../../c-runtime-library/reference/security-init-cookie.md).
56
+
The **/GS** compiler option requires that the security cookie be initialized before any function that uses the cookie is run. The security cookie must be initialized immediately on entry to an EXE or DLL. This is done automatically if you use the default VCRuntime entry points: `mainCRTStartup`, `wmainCRTStartup`, `WinMainCRTStartup`, `wWinMainCRTStartup`, or `_DllMainCRTStartup`. If you use an alternate entry point, you must manually initialize the security cookie by calling [`__security_init_cookie`](../../c-runtime-library/reference/security-init-cookie.md).
61
57
62
58
## What Is Protected
63
59
64
60
The **/GS** compiler option protects the following items:
65
61
66
62
- The return address of a function call.
67
-
68
63
- The address of an exception handler for a function.
69
-
70
64
- Vulnerable function parameters.
71
65
72
66
On all platforms, **/GS** attempts to detect buffer overruns into the return address. Buffer overruns are more easily exploited on platforms such as x86 and x64, which use calling conventions that store the return address of a function call on the stack.
@@ -80,15 +74,10 @@ A vulnerable parameter is allocated before the cookie and local variables. A buf
80
74
The compiler does not make copies of vulnerable parameters in the following situations:
81
75
82
76
- Functions that do not contain a GS buffer.
83
-
84
-
- Optimizations ([/O options](o-options-optimize-code.md)) are not enabled.
85
-
77
+
- Optimizations ([`/O` options](o-options-optimize-code.md)) are not enabled.
86
78
- Functions that have a variable argument list (...).
87
-
88
79
- Functions that are marked with [naked](../../cpp/naked-cpp.md).
89
-
90
80
- Functions that contain inline assembly code in the first statement.
91
-
92
81
- A parameter is used only in ways that are less likely to be exploitable in the event of a buffer overrun.
93
82
94
83
## What Is Not Protected
@@ -100,9 +89,7 @@ Even if you use **/GS**, always try to write secure code that has no buffer over
100
89
### To set this compiler option in Visual Studio
101
90
102
91
1. Open the project's **Property Pages** dialog box. For details, see [Set C++ compiler and build properties in Visual Studio](../working-with-project-properties.md).
0 commit comments