How to: Specify the symbol position and loading Behavior

In other words, I have always believed that if the link is static_lib during dll debugging, I can directly step in, and I am tired of having confused the import and export operations when I first played with OGE, the concept of pdb has never been very clear, and it has been a good habit at ordinary times. I have never paid attention to the debugging module panel. As a program that will deal with dll and library every day, I am really ashamed, fortunately, I encountered a problem that I had to solve. After careful consideration, I can see it clearly. Next I will refer to the detailed description on msdn and a dll explanation, introduction to introspection ~~

 

 

 

To debug an application, the debugger requires the symbolic information stored in the PDB file. In some cases, the symbolic information may be in an older DBG file. A symbolic file is required to debug your application and any third-party or system DLL. Symbol files can be stored in the directory on your computer or downloaded from the symbol server.

By default, the debugger loads the symbol file from the position where the EXE is located. To use symbols in other directories or on the symbol server, you must specify the position of Visual Studio.

When you start debugging sessions, Visual Studio automatically loads symbols. You can specify a module for which Visual Studio automatically loads symbols. If you do not select to automatically load symbols for all modules, you can use the Module window to manually load other symbols.

For more information about how to use the symbol server, see How to: use the symbol server. If you use a symbolic server, make sure the server is trusted. Otherwise, you may face security threats.

Directory of the specified symbol File

1. Select "option" from the "Tools" menu ".

2. In the "options" dialog box, open the "debug" node and click "symbol ".

   On the symbol page, there is a box indicating the location of the symbol file (. pdb. There are four icons above the box.

3. Click the folder icon.

   The editable text is displayed in the "symbol file (. pdb) Position" box.

4. Type the directory path. The statement ends to help you find the correct format.

   To perform remote debugging, the symbolic file and symbol server cache of the hosted code must be located on a remote computer. The local code's symbol file and symbol server cache must be located on the local computer.

5. If you want to use the symbols on the remote symbol server, you can improve performance by specifying a local directory where the symbols can be copied. To perform this operation, enter a path in the "cache symbol in this directory" box. If you debug a program on a remote computer, the cache directory refers to the directory on the remote computer.

6. Click OK ".

Remove the path name from the symbolic path list

1. As described above, open the "options" dialog box and find the "symbol" page.

2. In the "symbol file (. pdb) location" box, select a path.

3. Click the red "X" icon.

4. Click OK ".

Symbol to be automatically loaded

1. As described above, open the "options" dialog box and find the "symbol" page.

2. Under "automatically load symbols for the following modules", click "all modules except exclusion modules" or "only specified modules ".

3. If you select "all modules except exclusion module", you can click "specify excluded modules ".

   The "symbols to be excluded from automatic loading" dialog box appears.

   Click the document icon to add a module to the module list, or select a module in the module list, and then click the X icon to remove it.

   After completing the preceding operations, click OK ".

4. If you select "only specified module", you can click "specify module ".

   The "symbol to be automatically loaded" dialog box appears.

   Click the document icon to add a module to the module list, or select a module in the module list, and then click the X icon to remove it.

   By default, the symbols in the directory where the application module is located are always loaded. To stop this default behavior, clear "always load the symbol next to the module ".

   After completing the preceding operations, click OK ".

5. Click OK ".

Manually load symbols

You can manually load symbols from the Module window. This feature is not available in Visual Basic, Visual C #, or Web Developer learning edition.

Manually load symbols

1. In the Module window, right-click, point to "load symbol", and then click "symbol path" or "Microsoft symbol server ".

   The debugger searches for the symbol path or symbol server to find the symbol. If the debugger does not find a symbol, the "Search symbol" dialog box is displayed.

2. In the "Search for symbols" dialog box, locate the symbol file to be loaded and click "OK ".

   The symbol file is a. pdb file or. dbg file.

 

Appendix:

 

Dynamic link library (DLL) programming principle in Win32 Environment
Author: Li Xin
Submitted by: eastvc released on: 2003-12-10 14:08:40
Source: http://www.swm.com.cn/
Large applications are composed of many modules that complete relatively independent functions and collaborate with each other to complete the work of the entire software system. Some modules may have common functions and will still be used when constructing other software systems. When constructing a software system, if the source code of all modules is statically compiled into the entire application EXE file, some problems will occur: one drawback is that the size of the application is increased, it occupies more disk space and consumes a large amount of memory space during program running, resulting in a waste of system resources. Another drawback is that when writing large EXE programs, all source code must be adjusted during each modification and reconstruction, which increases the complexity of the compilation process and is not conducive to periodic unit tests.
Windows provides a completely different and effective programming and running environment. You can create an independent program module as a smaller DLL (Dynamic Linkable Library) file, they can be compiled and tested separately. During runtime, the system will load the EXE program to the memory space only when it does need to call these DLL modules. This method not only reduces the size of the EXE file and the need for memory space, but also enables these DLL modules to be used by multiple applications at the same time. Microsoft Windows itself implements some major system functions in the form of DLL modules. For example, some basic functions of IE are implemented by DLL files, which can be called and integrated by other applications.
Generally, a DLL is a disk file with a DLL extension. It consists of global data, service functions, and resources and is loaded into the virtual space of the process by the system at runtime, become part of the calling process. If there is no conflict with other DLL, the file is usually mapped to the same address of the virtual space of the process. The DLL module contains various export functions to provide external services. When Windows loads the DLL module, it matches the process function call with the export function of the DLL file.
In the Win32 environment, each process copies its own read/write global variables. To share memory with other processes, you must use a memory ing file or declare a shared data segment. The stack memory required by the DLL module is allocated from the stack of the running process.
DLL is more and more easy to write. Win32 has greatly simplified its programming mode and has many support from AppWizard and MFC class libraries.
1. Matching of Export and Import Functions
The DLL file contains an export function table. These export functions are associated with the external world by their symbolic names and integers called identifiers. The function table also contains the address of the function in the DLL. When an application loads the DLL module, it does not know the actual address of the called function, but it knows the symbol name and ID number of the function. When the DLL module is loaded during the dynamic link process, a table corresponding to the function call and function address is dynamically created. If you re-compile and recreate the DLL file, you do not need to modify the application unless you change the symbolic name and parameter sequence of the export function.
Simple DLL files only provide export functions for applications. In addition to providing export functions, complicated DLL files also call functions in other DLL files. In this way, a special DLL can have both the import function and the import function. This is not a problem because the dynamic link process can handle cross-related situations.
In the DLL code, the export function must be explicitly declared as follows:
_ Declspec (dllexport) int MyFunction (int n );
However, you can also list the export functions in the module definition (DEF) file, but this will often cause more trouble. In terms of applications, it is required to explicitly declare the corresponding input functions as follows:
_ Declspec (dllimport) int MyFuncition (int n );
Only the import and export declarations do not allow function calls within the application to be linked to the corresponding DLL file. The project of the application must specify the required input Library (LIB file) for the linked program ). In addition, the application must contain at least one call to the DLL function.
2. establish a link with the DLL module
The application import function can be linked to the export function in the DLL file in two ways: implicit link and explicit link. The so-called implicit link means that the actual storage path of the DLL file does not need to be specified in the application, and the programmer does not need to care about the actual loading of the DLL file. The explicit link is the opposite.
The implicit link method is used. When a programmer creates a DLL file, the link program automatically generates a corresponding LIB import file. This file contains the symbolic name and optional Identification Number of each DLL export function, but does not contain the actual code. The LIB file is compiled into the application project as an alternative DLL file. When programmers compile and generate an application through static links, the calling functions in the application match the exported symbols in the LIB file. These symbols or identifiers enter the generated EXE file. The LIB file also contains the corresponding DLL file name (but not the full path name), and the link program stores it in the EXE file. When a DLL file needs to be loaded while the application is running, Windows will find and load the DLL based on the information, and then use the symbolic name or identification number to achieve dynamic links to the DLL function.
Explicit links are suitable for integrated development languages (such as VB. With the explicit link, the programmer does not need to use the import file, but directly calls the Win32 LoadLibary function and specifies the DLL path as the parameter. LoadLibary returns the HINSTANCE parameter, which is used by the application to call the GetProcAddress function. The GetProcAddress function converts the symbolic name or identification number to the internal address of the DLL. Assume there is a DLL file for exporting the following functions:
Extern "C" _ declspec (dllexport) double SquareRoot (double d );
The following is an example of an explicit link from the application to the export function:
Typedef double (SQRTPROC) (double );
HINSTANCE hInstance;
SQRTPROC * pFunction;
VERIFY (hInstance =: LoadLibrary ("c: \ winnt \ system32 \ mydll. dll "));
VERIFY (pFunction = (SQRTPROC *): GetProcAddress (hInstance, "SquareRoot "));
Double d = (* pFunction) (81.0); // call this DLL Function
In the implicit link mode, all DLL files called by the application will be loaded into the memory when the application EXE file is loaded. However, if the explicit link mode is used, programmers can decide when to load or not load DLL files. The explicit link determines the DLL file to be loaded at runtime. For example, a DLL module with string resources can be loaded in English, while another can be loaded in Spanish. The application loads the corresponding DLL file after selecting the appropriate language.
3. Use the symbolic name link and the identification number Link
In the Win16 environment, the symbolic name link efficiency is low, and the identification number link is the main link method at that time. In the Win32 environment, the efficiency of symbolic link is improved. Microsoft currently recommends the use of symbolic links. However, the DLL version in the MFC library still uses the identification number link. A typical MFC program may be linked to hundreds of mfc dll functions. The EXE file of the application that uses the identification code link is relatively small, because it does not need to contain the long string symbol name of the import function.
4. Write the DllMain Function
The DllMain function is the default entry point of the DLL module. This function is called when Windows loads the DLL module. The system first calls the constructor of the global object and then calls the global function DLLMain. The DLLMain function is called not only when the DLL link is loaded to the process, but also when the DLL module is separated from the process (and other times. The following is an example of the Framework DLLMain function.
HINSTANCE g_hInstance;
Extern "C" int APIENTRY DllMain (HINSTANCE hInstance, DWORD dwReason, LPVOID lpReserved)
{
If (dwReason = DLL_PROCESS_ATTACH)
{
TRACE0 ("EX22A. DLL Initializing! \ N ");
// Perform initialization here
}
Else if (dwReason = DLL_PROCESS_DETACH)
{
TRACE0 ("EX22A. DLL Terminating! \ N ");
// Clear the job here
}
Return 1; // success
}
If the programmer has not compiled a DLLMain function for the DLL module, the system will introduce a default DLLMain function version from other runtime libraries without any operation. The DLLMain function is also called when a single thread is started and terminated. As indicated by the dwReason parameter.
5. module handle
Each DLL module in a process is identified by a globally unique 32-byte HINSTANCE handle. The process itself has an HINSTANCE handle. All these module handles are valid only within a specific process. They represent the starting address of the DLL or EXE module in the process virtual space. In Win32, the values of HINSTANCE and HMODULE are the same. You can replace these two types. The process module handle is almost always equal to 0x400000, while the default DLL module load address handle is 0x10000000. If the program uses several DLL modules at the same time, each has a different HINSTANCE value. This is because different base addresses are specified when the DLL file is created, or the DLL code is relocated by the loader.
The module handle is particularly important for loading resources. The FindResource function of Win32 contains an HINSTANCE parameter. Both EXE and DLL have their own resources. If the application needs resources from the DLL, specify this parameter as the module handle of the DLL. If you need resources in the EXE file, specify the module handle of the EXE.
But before using these handles, how do you get them? To obtain the EXE module handle, call the Win32 function GetModuleHandle with the Null parameter. If the DLL module handle is required, call the Win32 function GetModuleHandle with the DLL file name as the parameter.
6. How does the application find the DLL file?
If the application uses the LoadLibrary explicit link, you can specify the complete path of the DLL file in this function parameter. If you do not specify a path or perform an implicit link, Windows will follow the search order below to locate the DLL:
1. directory containing the EXE file,
2. current working directory of the process,
3. Windows System directory,
4. Windows Directory,
5. A series of directories listed in the Path environment variable.
There is a trap that is prone to errors. If you use VC ++ for project development and create a project for the DLL module, copy the generated DLL file to the system directory, and call the DLL module from the application. So far, everything is normal. After some modifications are made to the DLL module, a new DLL file is generated again, but you forgot to copy the new DLL file to the system directory. The next time you run the application, it still loads the DLL file of the old version. Be careful!
7. debug the DLL Program
Microsoft VC ++ is an effective tool for developing and testing DLL. You only need to run the debugging program from the DLL project. When you perform this operation for the first time, the debug program will ask you about the path of the EXE file. After that, each time a DLL is run in the debugging program, the debugging program automatically loads the EXE file. Then the EXE file uses the above search sequence to find the DLL file, which means you must set the Path environment variable to make it include the disk Path of the DLL file, alternatively, you can copy the DLL file to the directory path in the search sequence.