Automatic signaling encoding and decoding method and system based on DWARF debugging information

Abstract

The invention provides a signaling automatic coding and decoding method and system based on DWARF debugging information, and relates to the technical field of communication. The method comprises the following steps: analyzing DWARF debugging information generated by compiling, and constructing a protocol type dictionary; based on the protocol type dictionary, starting from a top node of a target signaling message, and by replacing a non-termination type reference with a complete definition, expanding the structure of the target signaling message into a signaling structure tree; performing flattened path traversal on the signaling structure tree to generate a field path and basic type mapping table; automatically generating a coding function and a decoding function through a preset code template according to the field path and a basic type mapping table; wherein the decoding function is used for converting a protocol structure instance of a to-be-decoded signaling into a semantic key value pair containing a field name and a field value, and the encoding function is used for converting the to-be-encoded semantic key value pair and filling the protocol structure instance with the semantic key value pair.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to an automated signaling encoding and decoding method and system based on DWARF debugging information. Background Technology

[0002] In the 5G core network, the encoding and decoding of Non-Access Stratum (NAS) and NG Application Protocol (NGAP) signaling are fundamental to implementing control plane functions. Currently, NGAP signaling is typically described according to the ASN.1 standard and uses a dedicated compiler to generate static structures and encoding / decoding functions; NAS signaling generally adopts the TLV (Type-Length-Value) format, requiring manual writing or templated code for parsing. Regardless of the method used, the relevant technologies all use predefined structures as intermediate carriers to achieve the conversion between binary streams and structures.

[0003] However, these methods have significant limitations. Decoding only yields a structure object filled with numerical values, lacking semantic information such as field names and hierarchical relationships. Accessing specific signaling fields requires manual programming to access structure members layer by layer, a cumbersome process tightly coupled with the underlying implementation, hindering automated processing and analysis. Furthermore, the decoding results cannot be directly understood and utilized by log systems, testing tools, or intelligent analysis models, limiting operational efficiency and intelligence levels. Therefore, these technologies struggle to meet the demands for efficient, flexible, and semantic processing of signaling in communication networks. Summary of the Invention

[0004] In view of the above problems, embodiments of this application provide a signaling automated encoding and decoding method and system based on DWARF debugging information, so as to overcome the above problems or at least partially solve the above problems.

[0005] A first aspect of this application discloses an automated signaling encoding and decoding method based on DWARF debugging information, the method comprising: Parse the compiled DWARF debugging information and construct a protocol type dictionary, which includes the complete definitions and reference relationships of basic types, structures, unions, arrays, and aliases; Based on the protocol type dictionary, starting from the top-level node of the target signaling message, the structure of the target signaling message is expanded into a signaling structure tree by replacing non-terminating type references with complete definitions; The signaling structure tree is flattened and path traversal is performed to generate a field path and basic type mapping table. Each record in the field path and basic type mapping table is associated with a complete access path and basic type of a terminating field. Based on the field path and basic type mapping table, encoding and decoding functions are automatically generated using a preset code template. The decoding function is used to convert the protocol structure instance of the signaling to be decoded into semantic key-value pairs containing field names and field values, and the encoding function is used to convert and populate the semantic key-value pairs to be encoded into the protocol structure instance.

[0006] Optionally, the compiled DWARF debugging information is parsed to construct a protocol type dictionary, including: The DWARF debug information text is scanned sequentially to identify the compilation unit information line, type label line, and attribute line; Record the tag type, level depth, and address identifier of the type tag row, and store the attribute row associated with the type tag row into the node record; wherein, the attribute information of the node record includes at least one of the following: name, byte size, type reference address, member offset, bit field information, and array upper bound; Construct a node list and address index table based on all node records; The definition node of the target type is found from the node list, and the type reference structure of the node is recursively parsed based on the address index table to restore the complete type definition; Aggregate all the restored type definitions to obtain the protocol type dictionary.

[0007] Optionally, the type reference structure of the node is recursively parsed based on the address index table to restore the complete type definition, including: For basic types, record the type name and size in bytes; For a structure or union, record the overall byte size and recursively parse the type references of each member to form a member list, which includes member name, byte offset and type information; For aliases, record the mapping relationship between the alias and the underlying real type; For arrays, record the array element type and length information for each dimension.

[0008] Optionally, based on the protocol type dictionary, starting from the top-level node of the target signaling message, the structure of the target signaling message is expanded into a signaling structure tree by replacing non-terminating type references with complete definitions, including: Starting with the name of the target signaling message, retrieve the corresponding type definition from the protocol type dictionary; The signaling structure tree is obtained by recursively expanding the type definition. The recursive expansion includes: when encountering a type reference entry, determining the referenced type name; if the referenced type name is a terminating type, stopping the expansion of the reference entry; if the referenced type name is a non-terminating type, searching for the complete definition in the protocol type dictionary and replacing the reference entry, and continuing to perform recursive expansion on the replaced content until no more non-terminating type references need to be expanded are contained.

[0009] Optionally, during the recursive expansion process, the member types of structures and unions are recursively expanded; aliases are replaced with the underlying real types they point to; and arrays are expanded into composite representations containing element type and dimension information.

[0010] Optionally, a flattened path traversal is performed on the signaling structure tree to generate a field path-to-basic type mapping table, including: The signaling structure tree is recursively traversed using a preset interface prefix as the root path. During the recursive traversal, the current path is expanded according to the type of the current node using the corresponding rules: If the current node is a structure, the current path is expanded to current path - member name; If the current node is a union, the members of each branch of the union are statically expanded to form parallel paths starting from the current path and the branch member name; If the current node is an array, and the element type of the array is a terminating type, then the entire array is treated as a whole field, and the current path is marked as a pointer; if the element type of the array is a non-terminating type, then path items with subscript indices are generated according to the array dimension, and each path item is recursively traversed. If the current node contains pointer semantics, pointer notation is used in the current path; When the recursive traversal reaches the terminal type node, a record is generated, which contains the field path from the root path to the terminal type node, as well as the basic type information of the terminal type node; By aggregating all generated records, a mapping table between the field paths and the basic types is formed.

[0011] Optionally, based on the field path and the basic type mapping table, encoding and decoding functions are automatically generated using a pre-defined code template, including: Read the configuration file to obtain the prefix, structure name, and function name of the target signaling message; Based on the prefix, filter out field records belonging to the same signaling message from the field path and basic type mapping table; Iterate through the filtered field records, select the corresponding code generation rule based on the basic type in each record, convert the field path into access or assignment statements for protocol structure members, and assemble them into the encoding function template or decoding function template respectively.

[0012] Optionally, based on the basic type in each record, select the corresponding code generation rule, including: When generating the decoding function, for integer fields, code is generated to convert their values ​​to strings and insert them into the key-value pair mapping table; for character array or byte array fields, code is generated to convert their contents to strings and then insert them into the mapping table. When generating the encoding function, for integer fields, code is generated to extract string values ​​from the key-value pair mapping table, convert them to the corresponding numeric type, and then assign them to the structure members; for character array or byte array fields, code is generated to convert the string values ​​and copy them into the structure array members.

[0013] Optionally, the field path is converted into an access or assignment statement to a protocol structure member, including: If a control field exists in the field path that indicates the length or validity of subsequent fields, when generating access or assignment statements for the corresponding data fields, conditional judgments or length calculation logic that depend on the value of the control field will be automatically inserted.

[0014] A second aspect of this application discloses a signaling automated encoding and decoding system based on DWARF debugging information, the system comprising: The protocol structure extraction module is used to parse the compiled DWARF debugging information and construct a protocol type dictionary. Based on the protocol type dictionary, starting from the top-level node of the target signaling message, the structure of the target signaling message is expanded into a signaling structure tree by replacing non-terminal type references with complete definitions. The protocol type dictionary includes complete definitions and reference relationships of basic types, structures, unions, arrays, and aliases. The path processing module is used to perform flattened path traversal on the signaling structure tree and generate a field path and basic type mapping table. Each record in the field path and basic type mapping table is associated with a complete access path and basic type of a terminating field. The code generation module is used to automatically generate encoding and decoding functions based on the field path and basic type mapping table and a preset code template. The decoding function is used to convert the protocol structure instance of the signaling to be decoded into semantic key-value pairs containing field names and field values, and the encoding function is used to convert and fill the semantic key-value pairs to be encoded into the protocol structure instance.

[0015] A third aspect of this application discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the signaling automated encoding and decoding method based on DWARF debugging information described in the first aspect of this application.

[0016] A fourth aspect of this application discloses a readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the signaling automated encoding and decoding method based on DWARF debugging information described in the first aspect of this application.

[0017] A fifth aspect of this application discloses a computer program product, including a computer program that, when executed by a processor, implements the steps of the signaling automated encoding and decoding method based on DWARF debugging information described in the first aspect of this application.

[0018] The embodiments of this application have the following advantages: In this embodiment, by parsing the compiled DWARF debugging information, a protocol type dictionary is constructed, and the structure of the target signaling message is expanded into a signaling structure tree. This accurately and completely restores the original definition of the protocol structure, ensuring the semantic correctness of subsequent processing, and eliminating the need for manual maintenance or writing of structure description files. Furthermore, by performing a flattened path traversal on the signaling structure tree, a mapping table between field paths and basic types is generated, transforming the complex nested protocol structure into a flattened representation that can be directly enumerated and accessed. This provides a precise and unambiguous input foundation for automated code generation.

[0019] Based on the mapping table between field paths and basic types, and by automatically generating encoding and decoding functions using pre-defined templates, this method achieves bidirectional automated conversion between protocol structure instances and semantic key-value pairs containing field names and values. Therefore, this method changes the cumbersome pattern of manually encoding and accessing structure members, reducing development and maintenance costs. Simultaneously, the output semantic key-value pairs are directly readable and can be directly understood and utilized by log systems, automated testing tools, or upper-level analysis models, significantly improving the accessibility and reusability of signaling data. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1This is a flowchart illustrating the steps of an automated signaling encoding and decoding method based on DWARF debugging information provided in an embodiment of this application. Figure 2 This is a flowchart of an automated signaling decoding method based on DWARF debugging information provided in an embodiment of this application; Figure 3 This is a flowchart illustrating an automated signaling encoding method based on DWARF debugging information provided in an embodiment of this application; Figure 4 This is a schematic diagram of a signaling automated encoding and decoding system based on DWARF debugging information provided in an embodiment of this application; Figure 5 This is an embodiment of an electronic device provided in this application. Detailed Implementation

[0022] To make the above-mentioned objectives, features, and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0023] To better understand the technical solution of this application, the relevant technical concepts and current status are explained below.

[0024] In 5G core network systems, NAS and NGAP protocols are crucial for control plane signaling interaction. The NAS protocol is used for signaling between terminals and the core network, such as registration and session management, and its messages use a TLV (Type-Length-Value) structure. The NGAP protocol is used for signaling between base stations and the core network, described using ASN.1 (Abstract Syntax Notation On) language and encoded in binary using PER (Packed Encoding Rules).

[0025] Currently, both types of protocol encoding and decoding implementations are based on static structures. The protocol encoding and decoding process generally follows the following steps: (1) Structure definition: Each protocol information element is defined in the source code in the form of a structure (struct) or union (union). The field order, bit width, type, etc. are all determined according to the 3GPP standard. (2) Encoding process: The protocol stack calls a handwritten function to fill the field values ​​in the structure into the buffer according to the protocol rules (byte order, bit length, optional fields) to generate binary signaling messages. (3) Decoding process: The protocol stack reads the byte stream from the received binary message, parses it according to the field order and fills it into the corresponding structure to obtain the protocol object.

[0026] Specifically, for NGAP, an ASN.1 compiler is typically used to compile standard files into predefined structures and corresponding encoding / decoding functions. The structures and functions generated by this method rely on compile-time definitions, and the output is a static structure object without semantics; individual field values ​​are obtained by accessing the structure's member variables. For NAS, TLV parsing is often implemented manually or using template code. Since the NAS protocol does not adopt the ASN.1 definition, various vendors and open-source implementations generally implement TLV structure parsing manually or using templated code; for example, defining C structures and field offset tables according to standard specifications, and using macros or function templates to complete the step-by-step parsing of fields. It is evident that regardless of the method used, the relevant technologies convert between binary streams and structures, and the decoded output is merely a structure instance filled with numerical values.

[0027] In summary, the relevant 5GNAS and NGAP codec technologies have the following two main shortcomings: First, field access is highly dependent on manual intervention, resulting in high parsing and usage costs. After completing signaling decoding, the codec library can only output the result as a compile-time defined structure object. If upper-level logic or developers need to access a specific field value, they must manually reference the structure members and read the internal variables layer by layer. If all fields need to be read, manual reading is required. Similarly, the encoding technology also relies on predefined structures, requiring all fields to be assigned values ​​one by one before encoding. In complex nested structures, this approach is extremely cumbersome, requiring not only understanding the structure hierarchy but also repeated modification and compilation of the code. The high degree of manual dependence and maintenance costs make it extremely unfavorable for automated calls and rapid verification.

[0028] Secondly, the output lacks semantic information, making direct semantic-level access impossible. Related technologies can only achieve reversible conversion between binary code streams and structures, but lack the ability to automatically extract and restore structures and semantic key-value pairs, and also lack a general structure mapping description mechanism. The output is only the "value" layer data of the structure, not in "key-value" pair form. In other words, after decoding, the program only obtains field values, but cannot carry field names or semantic tags, causing the upper-layer system to be unable to directly identify the business meaning of each field, making direct semantic-level field access difficult. After parsing the results, the mapping relationship between field names and values ​​still needs to be manually established, which is prone to errors and limits the ability to link with AI models, testing systems, configuration management, and other modules, making it difficult to meet the needs of automated processing and intelligent analysis.

[0029] To overcome the limitations of related technologies, this application provides an automated signaling encoding and decoding method based on DWARF debugging information. The technical concept is as follows: Utilizing compiler-generated DWARF (Debugging with Attributed Record Formats, a standard debugging information format used in compilers to describe types, variables, functions, etc. in source code to assist debuggers) debugging information as the source of protocol structure description, an automated mapping and code generation system from low-level structures to high-level semantics is constructed. By parsing the complete types contained in the DWARF debugging information, the precise memory layout and nesting relationships of all complex types such as structures, unions, and arrays in the signaling message are automatically extracted and reconstructed into a unified, machine-readable protocol structure description (i.e., a signaling structure tree). Subsequently, through path-based techniques, the signaling structure tree is flattened into a set of enumerable field mapping tables containing complete access paths and basic types. Ultimately, based on this mapping table and predefined code templates, encoding and decoding functions with standard interfaces are automatically generated. This establishes a stable, efficient, bidirectional, and reversible conversion channel between binary structure instances of signaling and semantic key-value pairs carrying explicit field names and values, without manual intervention. This concept achieves a closed-loop process from "automatic extraction of structural descriptions" to "automatic generation of encoding and decoding code," fundamentally changing the traditional protocol processing methods that rely on manual definition and hard coding.

[0030] The following description, in conjunction with the accompanying drawings, details the automated signaling encoding and decoding method based on DWARF debugging information provided in this application through specific embodiments and application scenarios.

[0031] Reference Figure 1 As shown, Figure 1This is a flowchart illustrating the steps of an automated signaling encoding / decoding method based on DWARF debugging information provided in this application. This method utilizes DWARF debugging information generated by a compiler to automatically understand and process the structure of the signaling protocol, ultimately achieving bidirectional conversion between binary / structured format and readable semantic format. Figure 1 As shown, the method may include steps S110 to S140: Step S110: Parse the compiled DWARF debugging information and construct a protocol type dictionary, which includes the complete definitions and reference relationships of basic types, structures, unions, arrays and aliases.

[0032] Among them, DWARF debugging information is generated by the compiler during the compilation process and is usually exported by tools such as objdump. The DWARF debugging information records in detail the layout, size, members and reference relationships of all types (such as basic types, structures, unions, arrays, etc.) in the source code. In this application embodiment, DWARF debugging information is used as the authoritative description source of the protocol structure.

[0033] Specifically, DWARF debugging information is essentially a hierarchical description containing numerous tags (such as DW_TAG_structure_type for structures) and attributes (such as DW_AT_name for names and DW_AT_type for type references). This step, by scanning and parsing these tags and attributes, automatically extracts the complete definitions of all data types defined in the protocol stack code. This includes identifying the definitions of all basic types (such as integers and characters), structures (structs), unions, and aliases (typedefs), and recording the reference relationships between them (e.g., the type of a member of a structure). Finally, this information is organized into a protocol type dictionary.

[0034] The protocol type dictionary is a complete description of the signaling protocol type system. It can be viewed as a map, containing not only the definitions of basic types but also a complete record of the composition of all custom structures, unions, arrays, and aliases, including their member lists, offsets of each member, data type references, and nesting relationships. Thus, by constructing the protocol type dictionary, programs can dynamically and accurately understand the complete memory structure and semantic composition of any signaling message at runtime without accessing the source code.

[0035] Step S120: Based on the protocol type dictionary, starting from the top-level node of the target signaling message, the structure of the target signaling message is expanded into a signaling structure tree by replacing non-terminating type references with complete definitions.

[0036] After obtaining the protocol type dictionary, for a specific target signaling message (e.g., an NGAP "PDU session resource establishment request" message), its specific, instantiated tree structure (i.e., signaling tree structure) is reconstructed.

[0037] Specifically, starting from the top-level node of the target signaling message (i.e., the name of the target signaling message), a depth-first recursive expansion is performed with that node as the root. References to non-terminating types (i.e., those whose definitions include references to other types, such as a member being another structure type) are replaced with complete definitions from the protocol type dictionary. For example, when a member in the message structure is found to be an alias of a structure (such as `struct ProtocolIE_Container`), the complete definition of that structure is retrieved from the protocol type dictionary and inlined to the current position. This process is recursive: if the expanded definition contains references to other structures, unions, or arrays, the replacement and expansion continue. The recursion terminates when a basic terminating type (such as `uint8_t`, `int32_t`, etc.) is encountered or a simple structure marked as terminating is reached. Finally, a signaling structure tree is generated, in which all abstract references are replaced by concrete content, clearly showing all fields, nesting levels, and type information of each node of the target signaling message from root to leaf, eliminating all indirect references, and becoming a self-contained data structure that can be directly used for analysis.

[0038] Step S130: Perform a flattened path traversal on the signaling structure tree to generate a field path and basic type mapping table. Each record in the field path and basic type mapping table is associated with a complete access path and basic type of a terminating field.

[0039] The signaling structure tree fully expresses the semantics, but its nested structure makes it difficult for programs to directly and uniformly access fields. This step flattens the signaling structure tree, transforming its complex nested hierarchy into a table format that is easily processed by template engines and code generators, namely a field path to basic type mapping table.

[0040] Specifically, the signaling structure tree generated in step S120 is recursively traversed using a preset interface prefix (such as "N1." or "N2.") as the root path. During the traversal, a unique field path is generated for each ultimately indivisible field (i.e., the terminating field, which is usually a basic type or a block marked as terminating). This path is similar to a file system path, containing all the level names from the root path to the terminating field; at the same time, the basic type of the terminating field (such as uint8_t, int32_t) is recorded. Finally, a field path-to-basic type mapping table (e.g., CSV format) is generated, where each field path is associated with a complete access path and basic type for a terminating field, along with each record in the basic type mapping table.

[0041] In this way, the field path and basic type mapping table establishes the correspondence between the complete access path of each terminating field and its basic data type. Together with the signaling structure tree obtained in step S120, it lays the foundation for everything from protocol standard definition to semantic key-value pairs and then to automated encoding and decoding. That is, the signaling structure tree is responsible for semantic integrity and consistency, while the field path and basic type mapping table is responsible for the operability of the project implementation.

[0042] Step S140: Based on the field path and basic type mapping table, an encoding function and a decoding function are automatically generated using a preset code template; wherein, the decoding function is used to convert the protocol structure instance of the signaling to be decoded into semantic key-value pairs containing field names and field values, and the encoding function is used to convert and fill the semantic key-value pairs to be encoded into the protocol structure instance.

[0043] Encoding and decoding functions can be generated by a generator. Specifically, for each record in the field path-to-basic type mapping table, the template generator selects the corresponding code template from a pre-built code template library based on its basic type field (for example, for an integer field, the decoding template is "convert the structure member value to a string and insert it into std::map", and the encoding template is "extract the string from std::map and convert it to an integer and assign it to the structure member"). Then, the field path in each record is converted into the correct access syntax for the structure member, and these code templates are assembled in an orderly manner to automatically output complete decoding and encoding functions.

[0044] A function-level bidirectional mapping is established between JSON key-value pairs (i.e., semantic key-value pairs) and signaling instances through encoding and decoding functions. Specifically, the decoding function receives a protocol structure instance pre-parsed by a third-party library (i.e., the protocol structure instance of the signaling to be decoded), iterates through all its fields, and outputs a standardized set of semantic key-value pairs containing "field name: field value" to complete the signaling encoding. The encoding function receives a pre-filled set of semantic key-value pairs (i.e., the semantic keys to be encoded), accurately assigns their values ​​back to the corresponding structure instance, and can then encode them into a binary signaling stream to complete the signaling decoding. This process is fully automated, requiring no manual writing of any parsing or assembly code for specific messages, greatly improving development efficiency, consistency, and maintainability.

[0045] For example, the encoding and decoding functions can be represented as:

[0046] in, For decoding function, For encoding functions, This is a signaling code stream instance (i.e., a structure instance). For key-value pairs ( Indicates key, (Representation value). After the signaling is decoded by a third-party library, it can be... Convert to M; padding before encoding After Transform into Finally, a third-party library encodes the data into a valid bitstream to achieve a closed loop.

[0047] It is understood that the method of this embodiment can be used for encoding and decoding NAS signaling and NGAP signaling. If it is used for encoding and decoding NAS signaling, the encoding function is the NAS signaling encoding function and the decoding function is the NAS signaling decoding function; if it is used for encoding and decoding NGAP signaling, the encoding function is the NGAP signaling encoding function and the decoding function is the NGAP signaling decoding function.

[0048] Thus, based on the methods described in steps S110 to S140, a protocol type dictionary is constructed by parsing the DWARF debugging information. Then, starting from the top-level node of the target signaling message, the structure of the target signaling message is expanded into a signaling structure tree by replacing non-terminating type references with complete definitions, thereby completing the protocol structure extraction. Next, a flattened path traversal is performed on the signaling structure tree to generate a field path-to-basic type mapping table. Based on this mapping table, encoding and decoding functions are automatically generated using pre-defined code templates to establish a function-level bidirectional mapping between JSON key-value pairs (i.e., semantic key-value pairs) and signaling instances.

[0049] like Figure 2 As shown, during decoding, for a binary signaling stream (5G NAS signaling or NGAP signaling), a third-party library can parse it into a protocol structure instance, and then call the corresponding decoding function (NAS, NGAP signaling decoding function) to convert the protocol structure instance into semantic key-value pairs (JSON key-value pairs) containing field names and field values. For example... Figure 3 As shown, during encoding, the corresponding encoding functions (NAS, NGAP signaling encoding functions) are called to assign the semantic key-value pairs (JSON key-value pairs) to be encoded back to the corresponding structure instance, which is then used by the third-party library to encode them into a binary signaling stream to complete the signaling decoding.

[0050] The technical solution adopted in this application constructs a protocol type dictionary by parsing the compiled DWARF debugging information and expanding the structure of the target signaling message into a signaling structure tree. This accurately and completely restores the original definition of the protocol structure, ensuring the semantic correctness of subsequent processing, and eliminating the need for manual maintenance or writing of structure description files. Furthermore, by performing a flattened path traversal on the signaling structure tree, a field path-to-basic type mapping table is generated, transforming the complex nested protocol structure into a flattened representation that can be directly enumerated and accessed. This provides a precise and unambiguous input foundation for automated code generation. Based on the field path-to-basic type mapping table and by automatically generating encoding and decoding functions through preset templates, bidirectional automated conversion between protocol structure instances and semantic key-value pairs containing field names and values ​​is achieved. Therefore, this method changes the cumbersome mode of manually encoding and accessing structure members in related technologies, reducing development and maintenance costs. At the same time, the output semantic key-value pairs are directly readable and can be directly understood and utilized by log systems, automated testing tools, or upper-level analysis models, significantly improving the accessibility and reusability of signaling data.

[0051] In an optional embodiment, the step S110 above, "parse the compiled DWARF debugging information and construct a protocol type dictionary," may specifically include sub-steps S110-1 to S110-5: Step S110-1: Perform a sequential scan of the DWARF debug information text to identify the compilation unit information line, type label line, and attribute line.

[0052] When DWARF debugging information is presented in text form, it contains numerous type label lines and attribute lines, indicating that a certain address contains a structure, along with the structure's name, size, included members, and the type of each member pointing to another type. Tables 1, 2, and 3 illustrate the type labels, attributes, and their corresponding relationships within the DWARF debugging information text.

[0053] Table 1. Type Label Illustration

[0054] Table 2 Attribute Illustration

[0055] Table 2. Correspondence between type tags and attributes

[0056] This step involves sequentially scanning the DWARF debug information text (line by line). The scanning process uses a tri-state flow: first, it attempts to analyze the compilation unit for each line; then, it attempts to analyze the tag lines; and finally, it attempts to analyze the attribute lines. Lines are categorized based on their beginning characteristics. Compilation unit information lines typically mark the start of a logical compilation module, helping to define the scope of the analysis. Type tag lines (usually containing keywords such as DW_TAG_structure_type and DW_TAG_base_type) identify the start of a new type definition or entity. Attribute lines (usually containing keywords such as DW_AT_name and DW_AT_type) describe the specific attributes of the preceding tag line.

[0057] Step S110-2: Record the tag type, level depth and address identifier of the type tag row, and store the attribute row associated with the type tag row into the node record; wherein, the attribute information of the node record includes at least one of the following: name, byte size, type reference address, member offset, bit field information and array upper bound.

[0058] Specifically, when a type tag line is identified, a new node record is created, recording its core metadata: tag type (such as struct, basic type), hierarchy depth (reflecting the nesting level in the source code or type definition), and address identifier (an address uniquely identifying the entry within DWARF, used for subsequent references). Subsequently, all attribute lines immediately following this tag line and preceding the next tag line are parsed, and their contents (such as name, size, addresses of other referenced types, offsets of members within the struct, detailed parameters of bit fields, array dimensions, etc.) are stored in the node record as its attribute information. In this way, unstructured text lines are initially transformed into semi-structured data objects.

[0059] Step S110-3: Construct a node list and address index table based on all node records.

[0060] Specifically, all created node records are stored in a node list in the order they are parsed to maintain the original definition order and associations. Simultaneously, an address index table is created, with each node's address identifier as the key and a pointer or index pointing to that node's position in the list as the value. This address index table establishes a fast lookup channel within DWARF for type references via addresses, enabling efficient navigation to the definition node when resolving "what a certain type is" in subsequent steps.

[0061] Step S110-4: Locate the definition node of the target type from the node list, and recursively parse the type reference structure of the node based on the address index table to restore the complete type definition.

[0062] Specifically, the top-level type definition node (e.g., the structure of a PDU session resource establishment request) related to the target signaling message is located from the node list. Then, based on the address index table, a recursive resolution process is initiated to parse the type reference structure of the node, thereby reconstructing the complete type definition.

[0063] Optionally, the type reference structure of the node is recursively parsed based on the address index table to restore the complete type definition, including steps S110-4-1 to S110-4-5: Step S110-4-1: For basic types, record the type name and byte size.

[0064] For nodes with tags of basic types, the processing method is to directly record their name (such as int) and size in bytes (DW_AT_byte_size). For example, the description can be in the form of name:{type:"base",size:...}.

[0065] Step S110-4-2: For a structure or union, record the overall byte size and recursively parse the type references of each member to form a member list, which includes member name, byte offset and type information.

[0066] For nodes labeled as structs or unions, first record their overall byte size, then traverse all their member child nodes. For each member, record its name, byte offset in the parent struct / union (DW_AT_data_member_location), and find its type reference address through the DW_AT_type attribute. Use the address index table to jump to the type definition node corresponding to that address, recursively execute this step (S110-4) to resolve the type of the member, and finally form a member list describing all its members and nested structures.

[0067] Step S110-4-3: For aliases, record the mapping relationship between aliases and underlying real types.

[0068] For nodes labeled as aliases, the process involves recording the alias name, finding the address of the underlying real type it points to through the address pointer of DW_AT_type, recursively parsing the real type, and finally establishing a mapping relationship between the alias and the underlying real type.

[0069] Step S110-4-4: For arrays, record the array element types and length information for each dimension.

[0070] For nodes with array labels, the definition address of their element type is found through DW_AT_type and recursively parsed; at the same time, their associated DW_TAG_subrange_type child nodes are parsed to obtain attributes such as DW_AT_upper_bound (upper bound), and the length of each dimension is calculated, ultimately forming an array description that combines element type and dimension information.

[0071] Step S110-5: Aggregate all restored type definitions to obtain the protocol type dictionary.

[0072] All type definitions (including basic types, structures, unions, arrays, and alias mappings) obtained through recursive parsing in step S110-4 are organized and stored in a unified data structure (such as a JSON object), ultimately resulting in a protocol type dictionary. The keys in the protocol type dictionary are typically type names, and their corresponding values ​​are the original structural descriptions of that type. This description includes the type's core attributes (such as size in bytes; for composite types (structures or unions), it includes their member list and names, offsets, etc.). For example, querying "structure A" returns the definition of A itself, including its size and a list of member names. The complete definitions of members "structure B" and "type alias C" are stored as independent entries in the same dictionary. The protocol type dictionary thus constitutes a queryable set containing all original type definitions and their mutual references, providing a complete data foundation for the recursive expansion in subsequent steps.

[0073] Understandably, during recursive parsing, once a type is fully resolved, its name and description are written into a unified data structure. If the type is referenced again elsewhere, it is retrieved directly without repeated parsing. This way, all subtypes accessible from the target type name are automatically retrieved, ultimately forming a protocol type dictionary.

[0074] The technical solution adopted in this application embodiment can fully automate the extraction of precise type information recognized by the compiler, avoiding errors that may be introduced by manually defining the protocol structure and ensuring the accuracy of the source data. Through recursive parsing and address index table mechanisms, it can correctly handle arbitrarily complex type nesting, alias references, and array dimensions, restoring the complete definition of the protocol specification. Furthermore, the generated protocol type dictionary is a standardized, queryable intermediate representation, providing a unique and reliable data source for subsequent steps such as signaling structure tree expansion and field path generation, ensuring the consistency and reliability of the entire automated process.

[0075] In an optional embodiment, step S120 above, "based on the protocol type dictionary, starting from the top-level node of the target signaling message, by replacing non-terminating type references with complete definitions, the structure of the target signaling message is expanded into a signaling structure tree," may specifically include steps S120-1 to S120-2: Step S120-1: Starting with the name of the target signaling message, obtain the corresponding type definition from the protocol type dictionary.

[0076] Using the name of the specific target signaling message (pduSessEstablishmentReq for N1, Ngap_PDUSessionResourceSetupRequestTransfer for N2) as the key, a query is performed in the protocol type dictionary constructed in step S110 to return the type definition corresponding to that name. This type definition may contain the message's direct members and their type names (these type names may be references to other structures, unions, etc.).

[0077] Step S120-2: Recursively expand the type definition to obtain the signaling structure tree; wherein, the recursive expansion includes: when encountering a type reference entry, determining the referenced type name; if the referenced type name is a terminating type, then stopping the expansion of the reference entry; if the referenced type name is a non-terminating type, then searching for the complete definition in the protocol type dictionary and replacing the reference entry, and continuing to perform recursive expansion on the replaced content until no more non-terminating type references that need to be expanded are contained.

[0078] Specifically, the process begins with the obtained type definition; during the recursive expansion, whenever a type reference entry is encountered (i.e., the type of a field or member is not a specific value, but the name of another type), the type name of the reference is determined.

[0079] If the referenced type name is a terminating type (typically a basic type such as int, char, uint32_t, or a simple structure marked as no longer expandable), then expanding the referenced entry stops, meaning that the field is already a leaf node in the tree structure. If the referenced type name is a non-terminating type (for example, it is the name of another structure, union, array, or type alias already defined in the protocol type dictionary), then a find and replace operation is performed; that is, the complete definition (i.e., a detailed structural description of the type itself) is found in the protocol type dictionary based on this type name, and the current type referenced entry is replaced with this complete definition.

[0080] After the replacement is complete, the recursive expansion process continues on the replaced content (i.e., inside the newly inserted complete definition). This means that if the newly inserted definition contains references to other non-terminal types, these references will also be searched and replaced. This recursive process continues until the entire structure definition being processed no longer contains any non-terminal type references that need to be expanded; at this point, all indirect references made by name have been replaced by their specific, detailed definitions.

[0081] During the recursive expansion process, the member types of structures and unions are recursively expanded; aliases are replaced with the underlying real types they point to; and arrays are expanded into composite representations containing element type and dimension information.

[0082] In this embodiment, when the recursive process encounters a node of type struct or union, the same expansion process is performed on the definition of each member. That is, it delves into the interior of the struct or union, processing the type references of all its member fields one by one, ensuring that the types of these members (whether basic types or other composite types) are also fully expanded. This guarantees that nested, complex protocol structures can be thoroughly flattened until all leaf nodes are indivisible basic units.

[0083] When an alias node is encountered, it is recognized that it is not a new, independent data type, but rather an alias or label for an existing type. Therefore, the underlying real type it points to is found by following the mapping relationship recorded in the protocol type dictionary. Subsequently, in the generated signaling structure tree, this alias node is replaced by the complete definition of its underlying real type. This process eliminates naming indirection and ensures that all nodes in the tree represent the actual data layout.

[0084] When an array-type node is encountered, since the array contains element type and dimension (size), a two-step expansion is performed: element type expansion and dimension information integration. Element type expansion refers to recursively expanding the element type of the array. If the element is a basic type such as int, it stops here; if the element itself is a structure, it continues to expand the structure. Dimension information integration refers to extracting and retaining the dimension information of the array (e.g., the length calculated by the DW_AT_upper_bound attribute). Finally, in the signaling structure tree, the array is replaced by a composite representation that contains both the fully expanded element type definition and the specific dimension information. For example, an array defined as int

[10] will be represented in the tree as a structure like {"element type": "int", "dimension information": 10}.

[0085] Furthermore, low-level metadata such as bit fields, offsets, and sizes, if available in the type dictionary, will also be included. After the structure is restored, a signaling structure tree that does not rely on external name resolution and can be directly traversed sequentially is obtained, serving as the sole true source for subsequent automated generation and field mapping.

[0086] The technical solution adopted in this application integrates the various type definitions associated by name in the protocol into a self-contained signaling structure tree that requires no external verification. This tree completely and accurately represents the possible forms of a specific signaling message in memory. The substitution operation eliminates all indirect references between type definitions, allowing any subsequent processing steps to be based on the signaling structure tree without dynamically resolving type relationships at runtime, greatly simplifying the processing logic and ensuring accuracy. This process is fully automated, driven by the protocol type dictionary, and does not require writing specific logic for different messages; therefore, this method has strong adaptability and scalability.

[0087] In an optional embodiment, step S130 above, "performing a flattened path traversal of the signaling structure tree to generate a field path-to-basic type mapping table," may specifically include steps S130-1 to S130-4: Step S130-1: Using the preset interface prefix as the root path, recursively traverse the signaling structure tree.

[0088] The predefined interface prefix (such as N1. or N2.) is used to identify the protocol source or interface category of the signaling in the final field path, providing a clear namespace root for all paths. Using this prefix as the starting path, a depth-first recursive traversal is performed starting from the root node of the signaling tree structure, ensuring that every node in the tree is visited.

[0089] Step S130-2: During the recursive traversal, expand the current path according to the type of the current node using the corresponding rules.

[0090] At each step of the traversal, the current path representing the access chain is dynamically constructed or modified based on the type of the currently visited node. Specifically, this can include items A-1 through A-4: Item A-1: ​​If the current node is a structure, expand the current path to current path - member name.

[0091] For struct nodes, the path expansion rule is "current path-member name" (or represented as current path.member name); this rule reflects the program semantics of accessing struct members through the dot operator, transforming nested relationships into path hierarchy.

[0092] Item A-2: If the current node is a union, statically expand each branch member of the union to form parallel paths starting from the current path - branch member name.

[0093] For a union node, all candidate branches of the union are statically expanded, that is, a parallel path is generated for each branch member starting with "current path-branch member name" (or represented as current path.branch member name) to ensure that all possible fields are considered at compile time (code generation stage), and the active branch is determined according to the selector at actual runtime.

[0094] Item A-3: If the current node is an array, and the element type of the array is a terminating type, then the entire array is treated as a whole field, and the current path is marked as a pointer; if the element type of the array is a non-terminating type, then path items with subscript indices are generated according to the array dimension, and the recursive traversal continues for each path item.

[0095] For array nodes, the processing is divided into two cases. If the element type of the array is a terminal type (such as unsignedchar), it is usually represented as a byte string or string in the protocol context. Therefore, its subscript is not expanded, but the entire array is treated as a whole field, which may be marked as a pointer in the path (e.g., reserved name) to indicate its contiguous memory characteristics. If the element type of the array is a non-terminal type (such as a structure), then each element inside it needs to be accessed, and path items with subscript indices are generated according to the array dimension (such as field[0], field[1]), and the recursive traversal continues for each subscript item to expand the fields inside the element.

[0096] Item A-4: If the current node contains pointer semantics, use pointer notation in the current path.

[0097] When encountering a type referenced by a pointer, the default pointer symbol (e.g., ...) is used in the current path. ) is used to represent, for example...gTPTunnel The formal representation of the path conceptually bypasses a pointer layer before reaching the actual member. This preserves the indirect access semantics in the source code, ensuring that the path accurately reflects the memory access logic while maintaining readability.

[0098] In addition, for certain special fields (such as data), when they are not fixed-length arrays but dynamic buffers whose length is determined by other fields, pointer markers are retained in the path to avoid being mistakenly expanded as fixed-length arrays.

[0099] Step S130-3: When the recursive traversal reaches the terminal type node, a record is generated, which contains the field path from the root path to the terminal type node and the basic type information of the terminal type node.

[0100] Specifically, the termination condition for recursive traversal is accessing a terminating type node (i.e., a basic data type, or a node specifically marked as terminating). At this point, the current path constructed is the complete field path from the root path to this leaf field, and a record is generated that binds the field path of this terminating type node and the basic type information of the terminating type node.

[0101] Step S130-4: By summarizing all generated records, form the field path and basic type mapping table.

[0102] When the traversal of the entire signaling structure tree is complete, all records generated in step S130-3 are organized into a table (such as CSV format). This table is the field path-to-basic type mapping table. The field path-to-basic type mapping table fully enumerates all accessible terminal fields in the signaling message. Each field has a unique path address and a clear data type, completely eliminating nested structures.

[0103] The technical solution of this application transforms a tree structure with arbitrary nesting, union selection, and array loops into a flat, non-recursive field list without loss of quality. This allows upper-level processing logic to access any field through simple path lookup without needing to understand the complex original structure. The generated mapping table provides deterministic input for subsequent templated code generation; each row directly corresponds to an assignment or retrieval statement to be generated. The field path specifies the access target, and the basic type determines the conversion function, thus ensuring the correctness of the generated code. Through differentiated path expansion rules (such as static union expansion and case-specific array processing), the core semantics of the original data structure are preserved while flattening the structure.

[0104] In an optional embodiment, step S140 above, "automatically generating encoding and decoding functions based on the field path and basic type mapping table using a preset code template," may specifically include sub-steps S140-1 to S140-3: Step S140-1: Read the configuration file to obtain the prefix, structure name, and function name of the target signaling message.

[0105] When automatically generating encoding and decoding functions, a configuration file (e.g., in YAML format) is first read. This configuration file contains key metadata related to the specific target signaling message. The prefix of the target signaling message (e.g., N1. or N2.) is used to uniquely identify the field group belonging to a specific message in the "Field Path to Basic Type Mapping Table"; the structure name refers to the structure type name corresponding to the message in the original C / C++ code (e.g., Ngap_PDUSessionResourceSetupRequest_t); and the function name is the name specified for the encoding and decoding functions to be generated. In addition, the configuration file can also specify the CSV file path (pointing to the Field Path to Basic Type Mapping Table), output file information (specifying the names of the generated source code header files (.h) and implementation files (.cc),) and header file dependencies (i.e., the system or third-party header files that the generated code needs to include).

[0106] In this way, the generation logic is decoupled from the specific message parameters, allowing the same generator to be configured to adapt to different signaling messages.

[0107] Step S140-2: Based on the prefix, filter out field records belonging to the same signaling message from the field path and basic type mapping table.

[0108] The field path-to-basic type mapping table may contain fields from multiple different signaling messages (corresponding to different prefixes). Using prefixes obtained from the configuration file, the field path-to-basic type mapping table is filtered. For example, configuring the prefix as N1. will filter out all field records starting with N1. in the field path-to-basic type mapping table. Then, common prefixes are removed from these complete field records to obtain relative field paths (relative field records) that directly correspond to the C++ struct member access syntax. This step yields a clean list of "fields and their types" belonging only to the target message, preparing for code conversion.

[0109] Step S140-3: Traverse the filtered field records, select the corresponding code generation rule according to the basic type in each record, convert the field path into access or assignment statements for protocol structure members, and assemble them into the encoding function template or decoding function template respectively.

[0110] Based on the traversed, filtered, and processed relative field records, and according to the basic type in each record, a predefined code generation rule is selected. This rule then transforms abstract field paths into specific access statements (for decoding) or assignment statements (for encoding) targeting protocol structure members. The generated access or assignment statements for all fields are then logically assembled into two pre-defined function code templates: one for constructing the decoding function and the other for constructing the encoding function. The templates provide the function framework (such as return type, function name, parameter list, error handling, etc.) to obtain the decoding and encoding functions.

[0111] In some embodiments, step S140-3 above, "selecting the corresponding code generation rule based on the basic type in each record," specifically includes steps S140-3-1 to S140-3-2: Step S140-3-1: When generating the decoding function, for integer fields, generate code to convert their values ​​to strings and insert them into the key-value pair mapping table; for character array or byte array fields, generate code to convert their contents to strings and insert them into the mapping table.

[0112] For example, for integer fields (such as int32_t, uint8_t): the rule is to generate a function that calls std::to_string() to convert the value to a string and insert it into a semantic key-value pair map (such as std::map).<std::string, std::string> The code for mess_map. Example code generation rule: mess_map.insert(std::make_pair(“field path”, std::to_string(mess_struct.field))).

[0113] For character array or byte array fields (such as char buf

[64] ): the rule is to generate code that calls a dedicated conversion function (such as uchar_array_to_string()) to convert the memory contents to a string (such as a hexadecimal string or an escaped string) and then inserts it into the map. Example of code generation rule: mess_map.insert(std::make_pair(“field path”, uchar_array_to_string(mess_struct.field, sizeof(mess_struct.field)))).

[0114] Step S140-3-2: When generating the encoding function, for integer fields, generate code to extract string values ​​from the key-value pair mapping table, convert them to the corresponding numeric type, and assign them to the structure members; for character array or byte array fields, generate code to convert the string values ​​and copy them to the structure array members.

[0115] For example, for integer fields, the rule is to generate code that extracts a string value from `mess_map`, converts it to the corresponding numeric type using functions like `stringToNum<type>()`, and then assigns it to a struct member. Example code generation rule: `mess_struct.field = stringToNum`<uint32_t> (mess_map ["field path"]).

[0116] For character array or byte array fields, the rule is to generate code that calls a reverse conversion function (such as stringToCharArray()) to convert the string value and copy it into the structure array member. Example of code generation rule: stringToCharArray(mess_map["field path"], mess_struct.field).

[0117] In some embodiments, the step S140-3 above, "converting the field path into an access or assignment statement for a protocol structure member", specifically includes: when there is a control field in the field path that indicates the length or validity of subsequent fields, when generating the access or assignment statement for the corresponding data field, automatically inserting condition judgment or length calculation logic that depends on the value of the control field.

[0118] In this embodiment, when scanning field records, the generator identifies and processes the dependencies between fields. Specifically, if the validity or length of certain subsequent fields depends on control fields such as .n / .nbits / .nocts under the same path, the generator first retrieves these control fields and temporarily stores them in local variables, and then automatically inserts conditional judgments or length calculation logic that depend on the values ​​of the control fields before the corresponding data fields.

[0119] For example, if the actual length of a data field is determined by a preceding control field (such as nbits or nocts), the length calculation logic is automatically inserted when generating the conversion statement for that data field. This will pass std::stoi(nbits) / 8 or std::stoi(nocts) as the byte length to the array-to-string tool. The code generation rule is "mess_map.insert(std::make_pair(std::string("<path>"), uchar_array_to_string(mess_struct.<field>,std::stoi(nbits_value) / 8))); or mess_map.insert(std::make_pair(std::string("<path>"),uchar_array_to_string (mess_struct.<field>, std::stoi(nocts_value))));", where nbits_value and nocts_value are control field values ​​pre-retrieved from mess_map.

[0120] If the validity of a field is determined by a preceding existence indicator field (such as a count item n), the generator will first check the value of n before deciding whether to write it. The template rule automatically adds a layer of protection before outputting the data. The template is: if(n_value!=""&&std::stoi(n_value)>0){mess_map.insert (std::make_pair(std::string("<path>"),std::to_string(mess_struct.<field>)));} In this way, the tedious process of manually writing conditional branches and length calculation code is eliminated, and the logic is directly derived from the order and semantics of the field path and the basic type mapping table records, which is accurate and reliable.

[0121] The technical solution adopted in this application automatically generates encoding and decoding functions based on descriptive configuration files and field path-to-basic type mapping tables, replacing error-prone manual coding and achieving automated and configurable code production. Furthermore, generating code based on precise field paths and type information ensures that each field can be correctly accessed and converted. In particular, the intelligent handling of variable-length fields automatically embeds necessary business logic, enabling the generated code to safely and correctly process complex real-world protocol data. The generated decoding and encoding functions form a bidirectional, reversible conversion pair, achieving lossless conversion between protocol structure instances and semantically rich key-value pairs, providing a unified and reliable data interface for advanced applications such as signaling analysis, visualization, and backfill testing.

[0122] In some embodiments, in addition to the steps described above, the method further includes: automatically outputting a header file containing the declarations of the encoding and decoding functions, and a source file containing the definitions of the encoding and decoding functions, based on the configuration file and the generated encoding and decoding functions.

[0123] In this embodiment, corresponding header files (usually with .h or .hpp extensions) and source files (usually with .cc, .cpp, or .c extensions) are created on the disk according to the output file names specified in the configuration file. The file naming follows the configuration, ensuring the predictability and engineering standardization of the output results.

[0124] The header file generation process involves writing the function declarations (i.e., function prototypes) of the generated encoding and decoding functions into the header file. The function declarations include the function's return type, name, and parameter list (typically containing a protocol structure reference and a key-value mapping table reference). The source file generation process involves writing the complete function definitions (i.e., the function bodies containing all conversion statements) of the generated encoding and decoding functions into the source file. Finally, the assembled header and source file contents are written to the specified disk path. This results in two independent, standard source code files that can be immediately added to the project's build list (such as CMakeLists.txt or Makefile) for compilation and linking with other code to form the final executable program or library.

[0125] The technical solution adopted in this application directly transforms the final output of the entire automated process into source code files that can be directly compiled and integrated, forming a complete closed loop of "input configuration and data - output compilable source code," thereby improving the actual deployment efficiency and user experience of the solution. By automatically generating standard header and source files, it ensures that the generated code fully complies with general C / C++ engineering practices in terms of format and organization, enabling seamless integration into existing, potentially very complex software project architectures and avoiding integration obstacles caused by non-standard file formats.

[0126] In summary, the automated signaling encoding and decoding method based on DWARF debugging information provided in this application has the following main advantages compared with related technologies: Advantage 1: This method enables automated reconstruction from structures to semantic key-value pairs, achieving significant improvements over traditional encoding / decoding (stream) processes. After processing the structure, the system further utilizes DWARF debugging information to automatically extract the name, offset, and type information of each member, and automatically generates key-value mappings between field names and field values. Complete "segment name: field value" semantic key-value pairs can be obtained without manually reading structure members, significantly reducing manual operation costs.

[0127] Advantage 2: The output results are semantic, directly readable, and reusable. The decoded output results are presented in the form of standardized key-value pairs, and the field names have clear semantics. They can be directly used in scenarios such as log analysis, test verification, protocol consistency checks, and AI model training, which significantly improves the accessibility and scalability of the upper-layer system.

[0128] Advantage 3: It has protocol universality and automatic adaptation capabilities. By dynamically parsing the structure definition through DWARF information, this method can automatically adapt to different versions and manufacturers of NAS / NGAP structures without the need for manual maintenance of field definitions or recompiling library files, and supports protocol upgrades and extensions.

[0129] Advantage 4: Supports reverse reconstruction and reversible verification. The generated semantic key-value pairs can not only be used for display and analysis, but can also be reverse-constructed into the original structure or even binary signaling, realizing complete "semantic" functionality. structure The bit stream is a reversible closed loop.

[0130] This application also provides an automated signaling encoding and decoding system based on DWARF debugging information, see below. Figure 4 As shown, Figure 4 This is a schematic diagram of an automated signaling encoding and decoding system based on DWARF debugging information provided in an embodiment of this application. The system includes: The protocol structure extraction module 410 is used to parse the compiled DWARF debugging information and construct a protocol type dictionary; and based on the protocol type dictionary, starting from the top-level node of the target signaling message, it expands the structure of the target signaling message into a signaling structure tree by replacing non-terminal type references with complete definitions; wherein, the protocol type dictionary includes complete definitions and reference relationships of basic types, structures, unions, arrays and aliases; The path processing module 420 is used to perform a flattened path traversal on the signaling structure tree and generate a field path and basic type mapping table. Each record in the field path and basic type mapping table is associated with a complete access path and basic type of a terminating field. The code generation module 430 is used to automatically generate encoding and decoding functions based on the field path and basic type mapping table and a preset code template. The decoding function is used to convert the protocol structure instance of the signaling to be decoded into semantic key-value pairs containing field names and field values, and the encoding function is used to convert and fill the semantic key-value pairs to be encoded into the protocol structure instance.

[0131] It is understood that the signaling automated encoding and decoding system based on DWARF debugging information in the embodiments of this application can implement the signaling automated encoding and decoding method based on DWARF debugging information in the above embodiments. The signaling automated encoding and decoding system based on DWARF debugging information has the same advantages as the above-mentioned signaling automated encoding and decoding method based on DWARF debugging information compared with the prior art, and will not be repeated here.

[0132] This application also provides an electronic device, see embodiments thereof. Figure 5 , Figure 5 This is a schematic diagram of an electronic device provided in an embodiment of this application. For example... Figure 5 As shown, the electronic device 500 includes a memory 510 and a processor 520. The memory 510 and the processor 520 are connected via a bus for communication. The memory 510 stores a computer program that can run on the processor 520 to implement the steps of the signaling automated encoding and decoding method based on DWARF debugging information described in the embodiments of this application.

[0133] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the signaling automated encoding and decoding method based on DWARF debugging information described in this application.

[0134] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the signaling automated encoding and decoding method based on DWARF debugging information described in this application.

[0135] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0136] This application describes embodiments of methods and systems according to embodiments of this application with reference to flowchart illustrations and / or block diagrams. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0137] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0138] The above provides a detailed description of the signaling automated encoding and decoding method and system based on DWARF debugging information provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An automated signaling encoding and decoding method based on DWARF debugging information, characterized in that, include: Parse the compiled DWARF debugging information and construct a protocol type dictionary, which includes the complete definitions and reference relationships of basic types, structures, unions, arrays, and aliases; Based on the protocol type dictionary, starting from the top-level node of the target signaling message, the structure of the target signaling message is expanded into a signaling structure tree by replacing non-terminating type references with complete definitions; The signaling structure tree is flattened and path traversal is performed to generate a field path and basic type mapping table. Each record in the field path and basic type mapping table is associated with a complete access path and basic type of a terminating field. Based on the field path and basic type mapping table, encoding and decoding functions are automatically generated using a preset code template. The decoding function is used to convert the protocol structure instance of the signaling to be decoded into semantic key-value pairs containing field names and field values, and the encoding function is used to convert and populate the semantic key-value pairs to be encoded into the protocol structure instance.

2. The method according to claim 1, characterized in that, Parse the compiled DWARF debugging information and construct a protocol type dictionary, including: The DWARF debug information text is scanned sequentially to identify the compilation unit information line, type label line, and attribute line; Record the tag type, level depth, and address identifier of the type tag row, and store the attribute row associated with the type tag row into the node record; wherein, the attribute information of the node record includes at least one of the following: name, byte size, type reference address, member offset, bit field information, and array upper bound; Construct a node list and address index table based on all node records; The definition node of the target type is found from the node list, and the type reference structure of the node is recursively parsed based on the address index table to restore the complete type definition; Aggregate all the restored type definitions to obtain the protocol type dictionary.

3. The method according to claim 2, characterized in that, Based on the address index table, the type reference structure of the node is recursively parsed to restore the complete type definition, including: For basic types, record the type name and size in bytes; For a structure or union, record the overall byte size and recursively parse the type references of each member to form a member list, which includes member name, byte offset and type information; For aliases, record the mapping relationship between the alias and the underlying real type; For arrays, record the array element type and length information for each dimension.

4. The method according to claim 1, characterized in that, Based on the aforementioned protocol type dictionary, starting from the top-level node of the target signaling message, the structure of the target signaling message is expanded into a signaling structure tree by replacing non-terminating type references with complete definitions, including: Starting with the name of the target signaling message, retrieve the corresponding type definition from the protocol type dictionary; The signaling structure tree is obtained by recursively expanding the type definition. The recursive expansion includes: when encountering a type reference entry, determining the referenced type name; if the referenced type name is a terminating type, stopping the expansion of the reference entry; if the referenced type name is a non-terminating type, searching for the complete definition in the protocol type dictionary and replacing the reference entry, and continuing to perform recursive expansion on the replaced content until no more non-terminating type references need to be expanded are contained.

5. The method according to claim 4, characterized in that, During the recursive expansion process, the member types of structures and unions are recursively expanded; aliases are replaced with the underlying real types they point to; and arrays are expanded into composite representations containing element type and dimension information.

6. The method according to claim 1, characterized in that, The signaling structure tree is flattened and traversed to generate a field path-to-basic type mapping table, including: The signaling structure tree is recursively traversed using a preset interface prefix as the root path. During the recursive traversal, the current path is expanded according to the type of the current node using the corresponding rules: If the current node is a structure, the current path is expanded to current path - member name; If the current node is a union, the members of each branch of the union are statically expanded to form parallel paths starting from the current path and the branch member name; If the current node is an array, and the element type of the array is a terminating type, then the entire array is treated as a whole field, and the current path is marked as a pointer; if the element type of the array is a non-terminating type, then path items with subscript indices are generated according to the array dimension, and each path item is recursively traversed. If the current node contains pointer semantics, pointer notation is used in the current path; When the recursive traversal reaches the terminal type node, a record is generated, which contains the field path from the root path to the terminal type node, as well as the basic type information of the terminal type node; By aggregating all generated records, a mapping table between the field paths and the basic types is formed.

7. The method according to any one of claims 1-6, characterized in that, Based on the field path and basic type mapping table, encoding and decoding functions are automatically generated using pre-defined code templates, including: Read the configuration file to obtain the prefix, structure name, and function name of the target signaling message; Based on the prefix, filter out field records belonging to the same signaling message from the field path and basic type mapping table; Iterate through the filtered field records, select the corresponding code generation rule based on the basic type in each record, convert the field path into access or assignment statements for protocol structure members, and assemble them into the encoding function template or decoding function template respectively.

8. The method according to claim 7, characterized in that, Based on the basic type in each record, select the corresponding code generation rule, including: When generating the decoding function, for integer fields, code is generated to convert their values ​​to strings and insert them into the key-value pair mapping table; for character array or byte array fields, code is generated to convert their contents to strings and then insert them into the mapping table. When generating the encoding function, for integer fields, code is generated to extract string values ​​from the key-value pair mapping table, convert them to the corresponding numeric type, and then assign them to the structure members; for character array or byte array fields, code is generated to convert the string values ​​and copy them into the structure array members.

9. The method according to claim 8, characterized in that, Convert field paths into access or assignment statements for protocol structure members, including: If a control field exists in the field path that indicates the length or validity of subsequent fields, when generating access or assignment statements for the corresponding data fields, conditional judgments or length calculation logic that depend on the value of the control field will be automatically inserted.

10. An automated signaling encoding and decoding system based on DWARF debugging information, characterized in that, include: The protocol structure extraction module is used to parse the compiled DWARF debugging information and build a protocol type dictionary; Based on the protocol type dictionary, starting from the top-level node of the target signaling message, the structure of the target signaling message is expanded into a signaling structure tree by replacing non-terminating type references with complete definitions; wherein, the protocol type dictionary includes complete definitions and reference relationships of basic types, structures, unions, arrays and aliases; The path processing module is used to perform flattened path traversal on the signaling structure tree and generate a field path and basic type mapping table. Each record in the field path and basic type mapping table is associated with a complete access path and basic type of a terminating field. The code generation module is used to automatically generate encoding and decoding functions based on the field path and basic type mapping table and a preset code template. The decoding function is used to convert the protocol structure instance of the signaling to be decoded into semantic key-value pairs containing field names and field values, and the encoding function is used to convert and fill the semantic key-value pairs to be encoded into the protocol structure instance.

Images