Collecting Data in Dynamic Library Mode

The Link Latency Detection tool packages are available on Kunpeng and x86 servers. After the packages are decompressed, the dynamic library librecord.so is generated in the decompression directory. This dynamic library is loaded through the LD_PRELOAD environment variable when applications are running, allowing it to collect POSIX function and parameter information.

• The dynamic library is compatible with both x86 and Kunpeng architectures and requires Glibc 2.17 or later.
• To use the dynamic library to collect data, you must start the dynamic library together with the user application.
• The tool does not collect variable parameter functions in common scenarios. For the variable parameter functions in the compatibility list, only the first three parameters (fcntl, fcntl64, and ioctl) required for compatibility analysis are collected.
• The execution durations of inline functions cannot be collected.

Syntax

Executing librecord.so depends on the libglib-2.0.so and libgobject-2.0.so files distributed in the same package. Therefore, set LD_LIBRARY_PATH to include the directories of the two dynamic libraries. This setting prevents the "undefined symbol" error caused by the failure to find the dependent libraries.

LD_LIBRARY_PATH=/directory/of/:$LD_LIBRARY_PATH LD_PRELOAD=/path/to/librecord.so [Environment variable 1=Argument 1] ... [Environment variable n=Argument n] executable args

To collect runtime data, you need to specify the dynamic library path, configure environment variables, and the path to the binary file to be collected. You can configure one or more environment variables, among which RECORD_CONF is mandatory. Separate multiple environment variables using spaces.

• /directory/of/: directory where librecord.so, libglib-2.0.so, and libgobject-2.0.so are located.
• /path/to/: path to the librecord.so file.
• executable: Mandatory. Replace it with the actual path to the binary file to be collected.
• args: Replace it with the argument required by the binary file.

pthread_create
fork
socket
bind
_Z4funcv
_Z7computei

In the configuration file, each row contains only one column of data, which is the specified function name. POSIX functions are pthread_create, fork, socket, and bind. Custom functions are _Z4funcv and _Z7computei.

Custom functions are named according to the following rules:

• For a binary file generated from C++ compilation, function names are rewritten by the Mangled Name mechanism. You can run the nm binary_file or readelf -s binary_file command to view the rewritten function name.
• For a binary file generated from C compilation, use the original function names.

Mangled Name: A mechanism used by the compiler to rename functions and variables. It is mainly used to resolve name conflicts and ensure that each symbolic name is globally unique after compilation.

1 36149310 3081497 3081497 3081504 3081497 2740656
2 35935130 3081504 3081497
0 _Z4funcv 34587450 34714230 126780
0 bind 34739850 34746540 6690 0 3 4 P1{sin_family:2,sin_port:0,sin_addr:{s_addr:16777343}} 16
0 _Z7computei 36486452 36916330 429878
3 1798

Each line in the data file indicates a data packet. The first digit of a data packet indicates the data packet type:

• 0: Function information.

  Spaces are used as delimiters. The parameters in this type of data packet are used for subsequent compatibility analysis. The timestamp and function name are used for drawing sequence diagrams.

  • POSIX functions:

    0 <Function name> <Entry timestamp> <Exit timestamp> <Execution duration> <Return value> <Number of parameters> <Parameter data 1> <Parameter data 2> ...

  • Custom functions:

    0 <Function name> <Enter timestamp> <Exit timestamp> <Execution duration>

  

  The parameter data can be a value or pointer. The format of a pointer parameter is as follows:

  • Null pointer: P0 indicates that the pointer is null.
  • Integer pointer: P1 indicates that the pointer is not null, followed by the integer value to which the pointer in {} points, for example, P1{16}.
  • Structure pointer: P1 indicates that the pointer is not null, followed by the structure data to which the pointer points. The structure field is enclosed by {}, and its format is {Member name 1:Formatted data of member 1,Member name 2:Formatted data of member 2...}. If a member in a structure is also a structure, it is formatted in the same format.
• 1: process information
  Information such as process IDs in data packets of this type is mainly used to represent the relationship between processes during the creation of a sequence diagram. Spaces are used as separators.

   1 <Timestamp> <Process ID> <Process group ID> <Thread ID> <Thread group ID> <Parent process ID>

• 2: thread creation information
  Information such as thread IDs in data packets of this type is mainly used to represent the relationship between threads during the creation of a sequence diagram. Spaces are used as separators.

  2 <Timestamp> <Current thread ID> <Parent thread ID>

• 3: user-mode time consumption information of a process

  Spaces are used as separators. Data packets of this type are recorded in the last line of the data file corresponding to the main thread of each process. These data packets provide statistics (unit: ns) for network I/O feature analysis.

  3 <User-mode time consumption information of a process>