WO2022005447A1

WO2022005447A1 - Debug statement catalogs

Info

Publication number: WO2022005447A1
Application number: PCT/US2020/040093
Authority: WO
Inventors: Marvin Nelson; Stephen H. SCHWARZ; Yang Huang
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2020-06-29
Filing date: 2020-06-29
Publication date: 2022-01-06

Abstract

An example system may include a processor and a non-transitory machine-readable storage medium storing instructions executable by the processor to generate a catalog; utilize the catalog to decode corresponding encoded tokenized debug statements; and utilize the catalog to prevent data associated with an encoded tokenized debug statement tagged with a first data characteristic designation tag from being decoded from an encoded trace.

Description

DEBUG STATEMENT CATALOGS

Background

[0001] Instructions may be executed by a computing device to perform functions. For example, instructions may include system firmware code executable to organize communication with hardware and/or to perform functions like basic input/output tasks. The instructions may indude statements that serve to identify the presence and/or location of bugs (e.g., defect or error source) within a program when it is executing.

Brief Description of the Drawings

[0002] FIG. 1 illustrates an example of a system for generating debug statement catalogs consistent with the present disdosure.

[0003] FIG. 2 illustrates an example of a computing device for generating debug statement catalogs consistent with the present disdosure.

[0004] FIG. 3 illustrates an example of a non-transitory machine-readable memory and processor for generating debug statement catalogs consistent with the present disdosure.

[0005] FIG. 4 illustrates an example of a method for generating debug statement catalogs consistent with the present disdosure.

Detailed Descriotion

[0006] Computer programs or code may indude instructions executable by a processing resource to perform various functions. Execution of the instructions may collect and/or transform inputs to generate particular outputs in a manner specified by the instructions. In some examples, the execution of the instructions may fail to produce the corresponding function and/or may generate an erroneous or unexpected output. These errors and their underlying causes may be colloquially referred to as “bugs" in the program code. [0007] In addition to the instructions executable by the processing resource to perform the various functions, the code may include statements. The statements may include print statements or print tests. In some examples, these statements may be debug statements that may include the thoughts of the code architect or designer put into the code. The debug statements may be utilized to view and test the value of variables, inputs, outputs, etc. in addition to the flow of data when the instructions are executed. The debug statements, when viewed by a debugger, may be useful in achieving an understanding an overall view of the architecture of the instructions and/or how the instructions are functioning and/or should be functioning when executed. The debug statements may be associated with individual functions, portions of instructions, subroutines, etc.

[0008] It follows that these debug statements may be utilized to identify bugs in the program. That is, the debug statements may provide an overview of understanding to the underlying execution of the code that may be utilized to identify where in the code an error is originating. For example, tracing may be performed on a portion of the instructions of the computer program. As the portion of the instructions are executed the data resulting from and/or about the execution may be logged. A debugger may analyze the data along with the additional context provided by associated debug statements included in the code for the executed portion of instructions. Through such a process, a bug may be identified. As used herein, debugger may refer to a set of instructions executable by a processing resource to assist in the detection and/or correction of bus in a computing program. For example, a debugger may include instructions executable by a processing resource to test portions of a computing program under controlled conditions and monitor its progress and/or resource utilization to identify malfunctioning portions of the computing program code.

[0009] As described above, the debug statements may provide a wealth of knowledge regarding the functioning, flow, and/or underlying architecture of a computer program. Increasingly, program development and debugging may be a multi-team effort. In some examples, multiple teams of programmers, developers, debuggers, etc. from diverse interests may work together on or with a particular computer program. For example, two teams from competing companies or business groups may collaborate on a project involving a particular program. In some examples, portions of that computer program may be proprietary. For example, a portion of the computer program may be proprietary to an original developer or a portion of the development teams. As such, the original developer or portion of the development teams may not want the proprietary portion to be exposed to the other teams on the project. That is, exposing sensitive data such as the instructions and debug statements that lend insight into the underlying flow and/or architecture of the proprietary portions of a program to some of the parties interfacing with the program may result in a loss of secrecy to and/or an opportunity for copying by adverse parties.

[0010] In contrast, examples consistent with the present disclosure may include a mechanism to selectively filter out particular data from being collected during tracing and/or filter out particular data from being included in a catalog that may be utilized to decode the data collected during tracing. In this manner, examples consistent with the present disclosure may include a mechanism by which to selectively omit data collected from an execution of program instructions and also selectively omit data from a catalog that may be utilized to decode encoded data from the execution such that the debugging process may be streamlined and access to sensitive data may be selectively controlled. For example, examples consistent with the present disclosure may include a system including a processor and a non- transitory machine-readable storage medium to store instructions executable by the processor to: generate a catalog; utilize the catalog to decode corresponding encoded tokenized debug statements; and utilize the catalog to omit data associated with a tokenized debug statement tagged with a first data characteristic designation tag, from a trace collected from the encoded tokenized debug statements to be decoded.

[0011] FIG. 1 illustrates an example of a system 100 for generating debug statement catalog consistent with the present disclosure. The described components and/or operations of the system 100 may include and/or be interchanged with the described components and/or operations described in relation to FIG. 2- FIG. 4.

[0012] The system 100 may include a computing program 102. The computing program 102 may include instructions executable by a processing resource of a computing device to perform corresponding functions. An example of a computing program 102 may include firmware instructions executable to organize communication with hardware and/or to perform functions like basic input/output tasks for a computing system. The instructions may be executable to collect or accept data inputs and transform or operate on the data inputs to produce data outputs.

[0013] In addition, the computing program may include debug statements (e.g., tokenized debug statements 104-1... 104-N). The debug statements may include print statements or print tests. The debug statements may articulate the thoughts of the code architect or designer put into the code. The debug statements may include descriptions of the operations of the program 102 and the flow of data when the program 102 instructions are executed. The debug statements may be utilized to view and test the value of variables, inputs, outputs, etc. in addition to the flow of data when the instructions are executed. The debug statements, when viewed by a debugger, may be utilized to achieve an understanding an overall view of the architecture of the program 102 instructions and/or how the program 102 instructions are functioning and/or should be functioning when executed. The debug statements may be associated with individual functions, portions of instructions, subroutines, etc. of the program 102.

[0014] The debug statements may be tokenized. A tokenized debug statement 104-1... 104-N may include a debug statement that is augmented beyond traditional debug statements that are just focused on the functionality of the underlying program 102 and the data variables of its execution. The tokenized debug statement 104-1... 104-N may, for example, include data characteristic designation tags 106-1... 106-N. The data characteristic designation tags 106- 1... 106-N may be tags that designate a data characteristic of the corresponding tokenized debug statement 104-1... 104-N. As described above, each tokenized debug statement 104-1... 104-N may correspond to and/or accompany a specific functionality or portion of the instructions of the program 102 and/or the data inputs or outputs of that portion of the instructions. As such, a data characteristic designation tag 106-1...106-N may designate a data characteristic of its corresponding specific functionality or portion of the instructions of the program 102 and/or the data inputs or outputs of that portion of the instructions. Again, the tokenized debug statements 104-1... 104-N and/or their corresponding data characteristic designation tags 106-1... 106-N may be part of and/or coded within the code of the program 102 and/or within or associated with the instructions of the program 102 to which they correspond. [0015] The data characteristic designation tags 106-1... 106-N may designate a characteristic such as a priority of a corresponding tokenized debug statement 104-1...104-N and/or its corresponding specific functionality, portion of the instructions of the program 102, and/or the data inputs or outputs of that portion of the instructions. A priority designation may designate whether the tokenized debug statement 104-1... 104-N and/or its associated data are high priority, medium priority, low priority, etc. or any other priority designation. In some examples, the priority designation may designate whether the tokenized debug statement 104-1... 104-N and/or its associated data are priority A, priority B, priority C, priority D, etc.

[0016] Regardless of the specific nomenclature associated with the priority designation, the priority designation of a corresponding tokenized debug statement 104-1... 104-N and/or its associated data may designate a priority group within which it may be characterized.

[0017] An example of a priority group may include a first priority group including a tokenized debug statement 104-1... 104-N and/or its associated data which is applicable and/or of interest in nearly every instance of debugging. That is, the first priority group may include tokenized debug statement 104-1...104-N and/or its associated data which could be characterized as highly useful and/or applicable in debugging and that which should be presented by debuggers no matter what their specific task or query is as it is likely a component in understanding the basic operation of the program 102.

[0018] An example of a priority group may include a second priority group including a tokenized debug statement 104-1... 104-N and/or its associated data which is applicable and/or of interest with respect to identifying something going wrong within a particular function or set of functions. For example, the second priority group may include tokenized debug statement 104-1... 104-N and/or its associated data which could be characterized as highly useful and/or applicable in debugging a particular function or set of functions and that which should be presented by debuggers when their specific task or query is related to the particular function or set of functions.

[0019] An example of a priority group may include a third priority group including a tokenized debug statement 104-1... 104-N and/or its associated data which provides a next level of analysis that includes detailed data and statements which represent a deeper dive into the code than the prior priority levels. This third priority group may include a tokenized debug statement 104-1...104-N and/or its associated data which could be characterized as appropriate for detailed analysis of a portion of the program 102 associated with a relatively complex debugging operation.

[0020] An example of a priority group may include a fourth priority group including a tokenized debug statement 104-1... 104-N and/or its associated data which is largely the entire contents of the debug statements 104-1... 104-N and/or associated data for the program 102 which would be applicable in circumstances where a wholistic analysis of the program 102 may be utilized for debugging. That is, the fourth priority group may include an all-inclusive view of all the debug statements 104-1...104-N and/or their associated data for the program 102. These examples of priority groups are non-limiting examples and serve to illustrate the types of characteristics by which the tokenized debug statement 104-1... 104-N and/or its associated data may be characterized by the data characteristic designations tags 106-1... 106-N. The examples of priority groups demonstrate that the priority designation of a corresponding tokenized debug statement 104-1... 104-N and/or its associated data may designate a corresponding tokenized debug statement 104-1... 104-N and/or its associated data according to the level of detail revealed thereby, the predicted utility of that level of detail in expected debugging routines, etc.

[0021] In addition, the data characteristic designation tags 106-1...106-N may designate a characteristic such as a data sensitivity of a corresponding tokenized debug statement 104-1... 104-N and/or its corresponding specific functionality, portion of the instructions of the program 102, and/or the data inputs or outputs of that portion of the instructions. A data sensitivity designation may indicate how sensitive a developer or business interest considers the debug statement 104- 1... 104-N and/or its corresponding data to be.

[0022] Non-limiting examples of data sensitivity designations may include designations of whether a corresponding debug statement 104-1... 104-N and/or its corresponding data are IP protected (e.g., copyrighted, patented, trade secret, trademarked, etc.), not IP protected, secret, not secret, proprietary, not proprietary, competitively advantageous, not competitively advantageous, private, not private, etc. The data sensitivity designation may be binary in that the designation corresponds to a sensitive or non-sensitive designation, or the data sensitivity designation may be one of a plurality of sensitivity designations arranged in a sensitivity continuum (e.g., sensitivity levels, etc.).

[0023] Regardless of the nomenclature of the data sensitivity designation, the data sensitivity designation may indicate whether the debug statement 104-1... 104- N and/or its corresponding data should be protected with some corresponding degree of secrecy or security. That is, the data sensitivity designation may designate whether the debug statement 104-1... 104-N and/or its corresponding data should be protected from access and/or viewing by particular users or user groups.

[0024] Additionally, the data characteristic designation tags 106-1... 106-N may designate a characteristic such as a data format of a corresponding tokenized debug statement 104-1... 104-N and/or its corresponding specific functionality, portion of the instructions of the program 102, and/or the data inputs or outputs of that portion of the instructions. A data format designation may indicate a designation of how the various pieces of data associated with and/or output by the execution of the program 102 instructions corresponding to a tokenized debug statement 104- 1... 104-N are to be collected and put back together into a readable statement. That is, the data format designation may specify the output format for a tokenized debug statement 104-1...104-N which may be utilized to reassemble a useable statement from the encoded data corresponding to the tokenized debug statement 104-1...104- N when the trace is decoded.

[0025] The data characteristic designation tags 106-1... 106-N may be designations added by a developer of the program 102. That is, the developer of the program 102 code may insert the tokenized debug statements 104-1... 104-N and their corresponding data characteristic designation tags 106-1... 106-N within the program 102 code. As such, the determination of which data characteristic designation tag 106-1...106-N a particular tokenized debug statement 104-1... 104-N is assigned may be determine by the party or parties writing the instructions of the program 102. For example, a program 102 developer may decide a data sensitivity designation of a corresponding debug statement 104-1... 104-N and/or its corresponding data based on his/her judgment, opinion, corporate directive, etc. In this manner, each tokenized debug statement 104-1... 104-N may include data characteristic designation tags 106-1...106-N tailored by a developer that coded the program 102 instructions and has an intimate familiarity with the characteristics of each tokenized debug statement 104-1... 104-N and/or its corresponding data. By letting a developer decide the data characteristic designation tags 106-1...106-N of a corresponding debug statement 104-1...104-N and install these designations within the code of the program 102 with the described level of granularity, the tokenized debug statements 104-1...104-N of the entire program 102 become selectively filterable as described below.

[0026] A trace operation may be performed on the program 102. In a trace operation a portion of the program 102 may be encoded. For example, a system on a chip (SoC) may be utilized in encoding the portion of the program 102 for the trace operation. For example, the SoC may be access the program 102 instructions via an internal product bus. The SoC may, as the program 102 instructions execute, write the data being generated to different addresses for collection. For example, controls inside of the SoC may be utilized to manage the data resulting from the trace operation which may be packaged, time stamped, and fed into a local capture such as a first-in-first-out (FIFO) buffer. The FIFO may be drained into an external storage location through a narrow bus running between the FIFO and the external storage location. A local input/output converter and buffering manager may manage the size of the buffer, how to sort data within the buffer, and which data from the buffer should be kept versus filtered out or discarded from the encoded trace 108. [0027] For example, a user may specify to a local input/output converter and buffering manager which data from the program 102 the user wants to be included in the encoded trace 108. That is, the data from the program that is to be included in and/or excluded from the encoded trace 108 may be determined based on a user indication to a local input/output converter and buffering manager. In some examples, a user indication may specify which tokenized debug statements 104- 1...104-N and/or their associated data should be included in and/or excluded from an encoded trace 108 on the basis of their corresponding data characteristic designation tags 106-1...106-N. For example, a user may indicate to a local input/output converter and buffering manager that they do not want a tokenized debug statement 104-N with a specific data characteristic designation tag (e.g., tag C) 106-N to be included in the encoded trace 108.

[0028] For example, the data characteristic designation tag C 106-N may correspond to a particular priority or priority group as described above. For example, the data characteristic designation tag C 106-N may correspond to a fourth all- inclusive priority group as described above. The user may indicate to a local input/output converter and buffering manager that the user wants tokenized debug statements 104-N and/or their associated data that are tagged with the data characteristic designation tag C 106-N (fourth priority group) to be excluded from the encoded trace 108. As such, the encoded trace 108 may be generated with the tokenized debug statements 104-1...104-2 and/or their associated data that are tagged with the data characteristic designation tags A-B 106-1...106-2, whereas the tokenized debug statements 104-N and/or their associated data that are tagged with the data characteristic designation tag C 106-N may be not collected in the encoded trace 108, omitted from the encoded trace 108, excluded from collection from the buffer, etc. based on an identification of the data characteristic designation tags 106- 1...106-N of each of the tokenized debug statements 104-1...104-N of the portion of the program 102 being encoded in the trace. In this manner, a user may achieve a front-end coarse-grained filtering of the data that is to be collected for and/or included in an encoded trace 108. This can cut down on the amount of data that is to be collected and/or analyzed in later steps. In some examples, users may be able to exclude everything from an encoded trace 108 that has to do with a particular function, group of functions, data characteristic, etc. before consuming the resources associated with its inclusion in an encoded trace 108.

[0029] The encoded trace 108 may include a collection of raw data. For example, the encoded trace 108 may have the appearance of an enormous barrage of numeric values which are seemingly nonsensical to a human reader. That is, the encoded trace 108 may be in a format that is not readily understandable by a human and/or able to be immediately utilized for a debugging operation. The raw data of the encoded trace 108 may be decoded. For example, decoding the encoded trace 108 may include reassembling the raw data of the encoded trace, including the encoded tokenized debug statements 104-1...104-N and/or their associated data, into a human readable format.

[0030] A catalog 110-1...110-N may be utilized to decode an encoded trace

108. A catalog 110-1...110-N may specify a format to reassemble the tokenized debug statements 104-1...104-N and/or their associated data into a human readable format For example, a catalog 110-1...110-N may function similarly to a table of contents where each of the tokenized debug statements 104-1...104-N represents an entry in the table of contents which specifies how to reassemble a string of data corresponding to the tokenized debug statements 104-1...104-N. Without a corresponding catalog 110-1...110-N to decode a portion of an encoded trace 108, the portion of the encoded trace 108 may not be able to be decoded and may remain unreadable to a human without significant effort in manually determining the appropriate format of raw data. That is, a catalog 110-1...110-N may provide the context to reassemble the tokenized debug statements 104-1...104-N and/or their associated data into a format that can be understood by humans and/or utilized for debugging operations.

[0031] In system 100, catalogs 110-1...110-N corresponding to the raw data in the encoded trace 108 may be generated. The catalogs 110-1...110-N may be generated to be utilized to decode the encoded trace 108. The generated catalogs 110-1...110-N may include the information involved in reassembling the tokenized debug statements 104-1...104-2 and/or their associated data in the encoded trace 108 into a human readable format. As described above, in order to reassemble each individual debug statement of the plurality of debug statements 104-1...104-2 and/or their associated data in the encoded trace 108 a catalog 110-1...110-N may have to provide the reassembly data corresponding to each individual debug statement of the plurality of debug statements 104-1...104-2 and/or their associated data in the encoded trace 108. That is, if a catalog 110-1...110-N does not include reassembly data for a particular debug statement of the plurality of debug statements 104- 1...104-2 and/or its associated data in the encoded trace 108, then that particular debug statement may not be able to be decoded utilizing the catalog 110-1...110-N. Stated alternatively, if the data for a particular debug statement of the plurality of debug statements 104-1...104-2 and/or its associated data in the encoded trace 108 is omitted from a catalog 110-1...110-N, then that particular debug statement may not be able to be reassembled and/or decoded from the encoded trace 108.

[0032] As such, the data from the encoded trace 108 which is made available to be decoded can be selectively controlled based on the selective omission of that data from the catalogs 110-1...110-N. For example, a developer or distributor of the program 102 may not want portions of the program including particular debug statements of the plurality of debug statements 104-1...104-N and/or their associated data to be visible to everybody debugging the program 102 every time a debugging operation is performed. The developer or distributor may, by selectively omitting particular debug statements of the plurality of debug statements 104- 1...104-N and/or their associated data from the catalog 110-1...110-N, apply a selective control over which of the debug statements 104-1...104-N are included in the catalog 110-1...110-N and, as a result, which debug statements of the plurality of debug statements 104-1...104-N and/or their associated data are able to be decoded utilizing the catalog 110-1...110-N.

[0033] However, there may be particular instance and/or particular parties that the developer or distributor wants to be able to decode and/or view the debug statements that he/she wants to be hidden in other instances and/or to other parties. For example, in the above described multi-team development environment, a developer or distributor may want members of the development team that are members of a first company and/or first business group to have the ability to access all of the plurality of debug statements 104-1...104-N and/or their associated data that may be included in an encoded trace 108 from a portion of the program 102.

For example, the developer or distributor may not be concerned whether members of the first company or business group have the ability to decode and/or read debug statements 104-1...104-N that include sensitive data with respect to the first company or first business group. Especially, if this sensitive data may be useful in identifying a bug in the program 102.

[0034] However, the developer or distributor may want members of the development team that are members of a second company and/or second business group to not have the ability to decode and/or read debug statements 104-1...104-N that include sensitive data with respect to the first company or first business group. That is, the developer or distributor may want to protect the intellectual property present in some of the debug statements 104-1...104-N and/or their associated data from being discovered by debuggers that lack particular relationships with the intellectual property owner.

[0035] The mechanism described in system 100 may serve both of the above stated purposes of the developer and/or distributor. For example, in the system 100 a plurality of catalogs 110-1...110-N may be created for an encoded trace 108. For example, a first catalog 110-1 may be generated. The first catalog 110-1 may include data that can be utilized to decode a first portion of the tokenized debug statements (e.g., tokenized debug statement 104-1) from the encoded trace 108.

The first portion may include data to reassemble less than all of the tokenized debug statements 104-1...104-2 present in the encoded trace 108. That is, the first catalog 110-1 may omit the data to reassemble some of the tokenized debug statements (e.g., tokenized debug statement 104-2) from the encoded trace 108.

[0036] The data to be omitted from the first catalog 110-1 may be determined based on the data characteristic designation tags 106-1...106-2 of the tokenized debug statements 104-1...104-2 present in the encoded trace 108. For example, a developer may designate that tokenized debug statements (e.g., tokenized debug statement 104-2) with a particular data characteristic designation tag (e.g., data characteristic designation tag B 106-2) is to be excluded from the first catalog 110-1 when it is generated. In an example, the particular data characteristic designation tag may correspond to a particular data sensitivity designation. For example, the particular data characteristic designation may be a designation that the corresponding tokenized debug statement and/or its associated data are proprietary. In such examples, when the first catalog 110-1 is generated during compiling for the encoded trace 108 data that may be utilized to reassemble any of the tokenized debug statements having the proprietary data characteristic designation may be omitted from the catalog 110-1.

[0037] In this manner, the developer may, through inclusion of the data characteristic designation tags 106-1...106-2 of the tokenized debug statements 104-1...104-2, provide a sorting or filtering mechanism for the automated identification of proprietary data and its omission from the catalog 110-1. This mechanism may be utilized to selective identify various debug statements which include proprietary data as designated by the developer and to omit data to decode these statements from a catalog 110-1. This may operate as a security mechanism by which team members that have access to the catalog 110-1 have access to some data that may be utilized to decode the encoded trace 108, but do not have access to a mechanism to readily decode any proprietary data in the encoded trace 108. [0038] However, as described above, team members of a particular company or business group that holds or produces the proprietary data may not have to be screened off from the proprietary data. To be able to provide these team members access to the data utilizable to decode the proprietary data in the encoded trace 108, a second catalog 110-N may be generated. The second catalog 110-N may be utilized to decode more, and in some cases all, of the tokenized debug statements 104-1...104-N in the encoded trace 108. That is, a portion of the data selectively omitted from the first catalog 110-1 for decoding tokenized debug statements with the data characteristic designation tag targeted for omission may be included in the second catalog 110-N. To extend the example given above, the developer may have designated that tokenized debug statements (e.g., tokenized debug statement 104-2) with a particular data characteristic designation tag (e.g., data characteristic designation tag B 106-2) is to be excluded from the first catalog 110-1 when it is generated. However, the data to decode the tokenized debug statement 104-2 with the data characteristic designation tag B 106-2 that was omitted from the first catalog 110-1 may be included in the second catalog 110-N. In examples where the particular data characteristic designation tag B 106-2 designates that the corresponding tokenized debug statement 104-2 and/or its associated data are proprietary, team members that have access to the second catalog 110-N may have access to data that may be utilized to decode the proprietary data in the encoded trace 108.

[0039] Although the above described example in described in terms of two catalogs for ease of comprehension, examples with additional catalogs are contemplated. For example, a developer may designate a range of catalogs that provide data to decode a very specific typed of encoded tokenized debug statement with a very specific data characteristic designation tag on one end of the range and that provide data to decode substantially all the encoded tokenized debug statement regardless of data characteristic designation tag on the other end of the range. The principle may be expanded or contracted to meet whatever granularity of selective omission of data decoding ability a developer wants to implement.

[0040] Access to each of the plurality of catalogs 110-1...110-N may be controlled utilizing a security mechanism. For example, submission of a security token or credential may be a requisite to access particular catalogs. For example, when a user submits a request to access data from then encoded trace 108, the user may provide security credentials as part of the request. It may be determined, based on the credentials, which of the plurality of catalogs 110-1...110-N the submitting user has access to.

[0041] For example, a first user may have a first security credential associated with a first level of access or permissions. This first level of access may be akin to guest access or permissions which does not include permissions or access to proprietary data. Therefore, the first user may be granted access to the first catalog 110-1 which omits data for decoding encoded tokenized debug statements having a proprietary data characteristic designation tag. In some examples, when utilizing the first catalog 110-1 to decode an encoded trace 108 the user may simply not see the proprietary data corresponding to the encoded tokenized debug statements having a proprietary data characteristic designation tag. In some examples, when utilizing the first catalog 110-1 to decode an encoded trace 108 the user may see an obscured or replaced version of the proprietary data corresponding to the encoded tokenized debug statements having a proprietary data characteristic designation tag. For example, the user may be presented with a placeholder message for the proprietary data that indicates “proprietary data excluded” or some other message indicating to the user that additional data exists but is not decoded due to inadequate access or permission granted to the credential associated with the encoded trace 108 request.

[0042] In some examples, no specific granted access, credentials, permissions, etc. may be a requisite for access to the first catalog 110-1. For example, access to the first catalog 110-1 may be granted by default whereas access to additional ones of the plurality of catalogs involve specific granted access, credentials, permissions, etc.

[0043] A second user may have a second security credential associated with a second level of access or permissions. This second level of access may be akin to a verified or validated team member access or permissions which does includes permissions or access to proprietary data. Therefore, the second user may be granted access to the second catalog 110-N which includes the data omitted from the first catalog 110-1 for decoding encoded tokenized debug statements having a proprietary data characteristic designation tag. In some examples, when utilizing the second catalog 110-N to decode an encoded trace 108 the user may have the ability to access and read the proprietary data corresponding to the encoded tokenized debug statements having a proprietary data characteristic designation tag.

[0044] Each of the plurality of catalogs 110-1...110-N may be stored in a separate memory location. The memory locations may be physically and/or logically separated. Each of the catalogs 110-1...110-N may be stored in their respective memory locations along with the encoded trace 108 data corresponding to the tokenized debug statements that they may be utilized to decode. For example, the first catalog 110-1 may be stored in a first memory location along with the data from the encoded trace 108 corresponding to the tokenized debug statement 104-1. The second catalog 110-N may be stored in a second memory location along with the data from the encoded trace 108 corresponding to the tokenized debug statements 104-1 and 104-2.

[0045] As such, the system 100 may be utilized to provide selective front-end of debugging filtering of tokenized debug statements 104-1...104-N and back-end of debugging access control, both being based on the data characteristic designation tags 106-1...106-N of the tokenized debug statements 104-1...104-N based on the judgement of and/or inserted by the developer of the program 102. For example, the data of the tokenized debug statements 104-1...104-N to be included and/or omitted in the encoded trace 108 may be selected on the basis of their corresponding data characteristic designation tags 106-1...106-N allowing a developer or a user requesting access to an encoded trace to selectively filter out data of the tokenized debug statements 104-1...104-N that is to be collected in the encoded trace 108. Access to data to decode the data of the tokenized debug statements 104-1...104-N included in the encoded trace 108 may be selectively granted by inclusion or omission in one of a plurality of catalogs 110-1...110-N and access to those catalogs may be controlled utilizing credentials. As such, the debugging process may be streamlined by filtering out unwanted or inapplicable data from inclusion in an encoded trace 108 in the first place. Additionally, the debugging process may be secured by controlling access to particular types of data in an encoded trace by selective inclusion of decoding data in one of a plurality of catalogs 110-1...110-N in addition to credential control to each of the catalogs 110-1...110-N.

[0046] FIG. 2 illustrates an example of a computing device 230 for generating debug statement catalogs consistent with the present disclosure. The described components and/or operations described with respect to the computing device 230 may include and/or be interchanged with the described components and/or operations described in relation to FIG. 1 and FIG. 3-FIG. 4.

[0047] The computing device 230 may include a single computing devices and/or a plurality of computing devices. The computing device 230 may be a computing device executing a computing program from which an encoded trace is collected. The computing device 230 may alternatively or additionally include a host computing device for managing the collection of the encoded trace and the generation of catalogs. The computing device 230 may include a user device for accessing a catalog and an encoded trace and decoding the data of the encoded trace utilizing the catalog. As such, the computing device 230, its components, its instructions 236, 238, 240, etc., and/or the execution of those instructions may be localized to a single device and/or distributed among devices.

[0048] The computing device 230 may include a processor 232 and/or a non- transitory memory 234. The non-transitory memory 234 may include instructions (e.g., 236, 238, 240, etc.) that, when executed by the processor 232, cause the computing device 230 and/or a device controlled thereby to perform various operations described herein. Again, while the computing device 230 is illustrated as a single component, it is contemplated that the computing device 230 may be distributed among and/or inclusive of a plurality of such components.

[0049] The computing device 230 may include instructions 236 executable by the processor 232 to generate a catalog. Generating a catalog may include generating, during compilation of code from a program, data that may be utilized to decode the data collected in a raw encoded trace. Generating the catalog may include selectively including and/or excluding data for decoding particular types of data present in the encoded trace.

[0050] For example, a program may include debug statements within its code. The debug statements may include tokenized debug statements that are tagged with a data characteristic designation tag. The data characteristic designation tag may designate that the data associated with the corresponding tokenized debug statements has a specific characteristic such as a specific priority, a specific data sensitivity, specific formatting instructions, etc. The tokenized debug statements may each be tagged with their corresponding data characteristic designation tag within their respective code. For example, as a developer integrates the tokenized debug statements into the code of a computing program, the developer may tag each of the tokenized debug statements with their corresponding data characteristic designation tag within the code.

[0051] Generating a catalog may include targeting data for inclusion or omission within the catalog on the basis of their corresponding data characteristic designation tag within the code. For example, generating a catalog may include generating a catalog that includes data to decode encoded tokenized debug statements tagged with a particular data characteristic designation tag and to exclude data to decode encoded tokenized debug statements tagged with a different type of data characteristic designation tag. As such, the corresponding data characteristic designations of the tokenized debug statements are utilized to identify data targeted for omission from the catalog.

[0052] Generating a catalog may include generating a first catalog which omits data that may not be utilized to decode an encoded tokenized debug statement tagged with a first data characteristic designation tag. For example, a first catalog may be generated that omits data that may be utilized to decode an encoded tokenized debug statement tagged with a proprietary data characteristic designation tag. While this first catalog can be utilized to decode encoded tokenized debug statement tagged with other data characteristic designation tags, encoded tokenized debug statements tagged with the first data characteristic designation tag may not be decoded utilizing the first catalog.

[0053] Generating a catalog can include generating a second or additional catalog. The second catalog may include data utilizable to decode encoded tokenized debug statement tagged with the first data characteristic designation tag.

In some examples, the second catalog may include just the data utilizable to decode encoded tokenized debug statement tagged with the first data characteristic designation tag that were omitted from the first catalog and not the encoded tokenized debug statements tagged with the other data characteristic designation tags that were included in the first catalog. In such examples, decoding of the encoded tokenized debug statement tagged with the first data characteristic designation tag and the encoded tokenized debug statements tagged with the other data characteristic designation tags may be completed by merging the data from the second catalog utilizable to decode encoded tokenized debug statement tagged with the first data characteristic with the data from the first catalog utilizable to decode encoded tokenized debug statement tagged with the other data characteristic designation tags.

[0054] In some examples, the second catalog may include both the data utilizable to decode encoded tokenized debug statement tagged with the first data characteristic designation tag and the data utilizable to decode the encoded tokenized debug statements tagged with the other data characteristic designation tags. That is, generating the second catalog may include generating a catalog including the decoding data omitted from the first catalog but also decoding data included in the first catalog. [0055] The first and second catalogs may be stored in separate repositories along with their corresponding encoded tokenized debug statements collected from the encoded trace. The repositories may be physically and/or logically separated such that access to the catalog and corresponding data in one repository may not grant the accessor access to the catalog and corresponding data in the other repository. Access to the repositories and/or their contents may be controlled based on credential permissions. For example, a determination may be made whether to provide access to the first catalog or access to the second catalog based on credentials associated with a request to access an encoded trace.

[0056] In addition to acting as a component of the above described back-end filtering mechanism for data to be included in a catalog, the data characteristic designation tags of the tokenized debug statements may be utilized on a front-end of a debugging operation as well. For example, the data characteristic designation tags of the tokenized debug statements may be utilized to identify, prior to compiling an instructions set from a computing program to be executed to produce the encoded trace, data to be excluded from being compiled in the instructions set. For example, the data characteristic designation tags of the tokenized debug statements may be utilized to identify data that is filtered out from the data to be compiled into the instructions set that is executed to generate the encoded trace. For example, a user may specify that tokenized debug statements tagged with a particular data characteristic designation tag may be excluded or omitted from the computing program instructions compiled in an instructions set to be executed to generate an encoded trace and that tokenized debug statements tagged with a different data characteristic designation tag may be included in the computing program instructions compiled in an instructions set to be executed to generate an encoded trace.

[0057] Additionally, the data characteristic designation tags of the tokenized debug statements may be utilized to identify data collected from the executed instruction set to be excluded from an encoded trace. For example, the data characteristic designation tags of the tokenized debug statements may be utilized to identify data that is filtered out from the data collected from the executed instruction set. That is, the data characteristic designation tags of the tokenized debug statements may be utilized to identify collected data from an execution of the compiled instruction set to be discarded and/or not included in an encoded trace.

For example, a user may specify that tokenized debug statements tagged with a particular data characteristic designation tag may be excluded or omitted from data collected from an execution of the compiled instruction set for generating the encoded trace and that tokenized debug statements tagged with a different data characteristic designation tag may be included in the encoded trace.

[0058] The computing device 230 may include instructions 238 executable by the processor 232 to utilize the generated catalog to decode corresponding encoded tokenized debug statements. For example, the above described first catalog may be utilized to decode the tokenized debug statements tagged with data characteristic designation tags other than the first data characteristic designation tag. The first catalog may be utilized to reassemble the encoded tokenized debug statements tagged with data characteristic designation tags other than the first data characteristic designation tag from the encoded trace. That is, the first catalog may prevent data associated with an encoded tokenized debug statement in the encoded trace that is tagged with a first data characteristic designation tag from being decoded from an encoded trace since the data involved in such a decoding is selectively omitted from the catalog.

[0059] The computing device 230 may include instructions 240 executable by the processor 232 to utilize the catalog to prevent data associated with an encoded tokenized debug statement tagged with a first data characteristic designation tag from being decoded from an encoded trace. As described above, since generation of the first catalog involved the selective omission of data that may be utilized to decode encoded data associated with an encoded tokenized debug statement, its use may effectively prevent the data associated with the encoded tokenized debug statement tagged with a first data characteristic designation tag from being decoded.

[0060] Additionally, the second catalog may be utilized to decode corresponding encoded tokenized debug statements. Since generation of the second catalog involved the inclusion of the data selectively omitted from the first catalog, the second catalog may be utilized to decode encoded data associated with an encoded tokenized debug statement tagged with a first data characteristic designation tag in addition to encoded tokenized debug statements tagged with other data characteristic designation tags.

[0061] FIG. 3 illustrates an example of a norvtransitory machine-readable memory 344 and processor 342 for generating debug statement catalogs consistent with the present disclosure. A memory resource, such as the non-transitory machine-readable memory 344, may be utilized to store instructions (e.g., 346, 348, 350, etc.). The instructions may be executed by the processor 342 to perform the operations as described herein. The operations are not limited to a particular example described herein and may include and/or be interchanged with the described components and/or operations described in relation to FIG. 1- FIG. 2 and FIG. 4.

[0062] The non-transitory memory 344 may store instructions 346 executable by the processor 342 to generate a first catalog. The first catalog may be stored in a first memory location. The first memory location may be a first repository, a first hard drive, a first server, a first file location, etc. The first memory location may be populated with the catalog including data associated with decoding encoded tokenized debug statements collected from a computing program. Additionally, the first memory location may be populated with the encoded debug statements corresponding to the data for decoding them. Each of the encoded tokenized debug statements of the encoded trace may be time stamped and buffered prior to their delivery to the first memory location.

[0063] The first catalog may, for example, include data associated with decoding an encoded tokenized debug statement tagged with a first data characteristic designation tag. As described above, data characteristic designation tags may designate, for example, a priority, a data sensitivity, a format, etc. of the corresponding encoded tokenized debug statement tagged therewith. These same data characteristic designation tags may be utilized as a selection or sorting basis for determining which portion of tokenized debug statements in a program code are collected in an encoded trace and/or included in the memory location with the catalog.

[0064] In an example, the encoded tokenized debug statement tagged with a first data characteristic designation tag may include proprietary data such as data that may be utilized to gain an understanding of, reproduce, and/or design around a feature of an underlying program that may confer a proprietary functionality. As such, the first data characteristic designation tag may be a proprietary data tag.

[0065] Generating the first data catalog in the first memory location may include populating the first memory location, during code compilation, with data that may be utilized to decode the encoded tokenized debug statement tagged with the proprietary data characteristic designation tag to a human readable format. As such, the first catalog may be a proprietary catalog in that it may, when accessed, provide a user with the ability to decode and/or read proprietary data from an encoded trace.

[0066] The non-transitory memory 344 may store instructions 348 executable by the processor 342 to generate a second catalog. The second catalog may be stored in a second memory location. The second memory location may be a second repository, a second hard drive, a second server, a second file location, etc. different and/or physically and/or logically separate from the first memory location. The second memory location may be populated with the catalog including data associated with decoding encoded tokenized debug statements collected from a computing program. Additionally, the second memory location may be populated with the encoded debug statements corresponding to the data for decoding them. Each of the encoded tokenized debug statements of the encoded trace may be time stamped and buffered prior to their delivery to the second memory location.

[0067] The second catalog may, for example, include data associated with decoding encoded tokenized debug statements tagged with data characteristic designation tags other than the first data characteristic designation tag. In an example, encoded tokenized debug statement tagged with data characteristic designation tags other than the first data characteristic designation tag may include non-proprietary data such as publicly available data unrelated or non-revelatory of features of an underlying program that may confer a proprietary functionality. As such, the data characteristic designation tags other than the first data characteristic designation tag may be a non-proprietary or less proprietary data tag.

[0068] Generating the second data catalog in the second memory location may include populating the second memory location, during code compilation, with data that may be utilized to decode the encoded tokenized debug statements tagged with non-proprietary or less proprietary data characteristic designation tags to a human readable format. As such, the second catalog may be a non-proprietary or less proprietary catalog in that it may, when accessed, provide a user prevent and/or not provide the user with the ability to read proprietary data from an encoded trace. That is, the generated second catalog stored in the second memory location may omit the data, present in the first catalog, utilizable to decode and/or read proprietary data from an encoded trace. [0069] The non-transitory memory 344 may store instructions 350 executable by the processor 342 to determine which of the first catalog and the second catalog a particular user should be granted access to. For example, it may be determined whether to make the first catalog or the second catalog visible to decode the encoded tokenized debug statements of an encoded trace based on credential permissions. In an example, a user performing a debugging operation may log in to a catalog access management system via user credentials (e.g., username, password, security token, etc.). The catalog access management system may cross-reference the credentials against permissions granted to the credential. Based on their permissions (e.g., allowed to access proprietary data, not allowed to access proprietary data, allowed to access less-proprietary data, not allowed to access less- proprietary data, allowed to access non-proprietary data, not allowed to access nonproprietary data) the user may be granted access to a catalog that contains data to decode encoded tokenized debug statements with data characteristic designation tags that correspond to the permission levels granted to their entered credential levels.

[0070] In addition to utilizing the above described credential permission system to access catalogs, some examples may include implementing an encryption scheme to secure the catalogs. For example, the encoded tokenized debug statements and/or the data to decode them in the catalogs may be encrypted in their respective memory locations. A credential system similar to the one described above with respect to access control may be implemented to control decryption of the contents of the memory locations. In some examples, select users may be provide with decryption keys and/or the ability to decrypt the encoded tokenized debug statements and/or the data to decode them.

[0071] FIG. 4 illustrates an example of a method 460 for generating debug statement catalogs consistent with the present disclosure. The described components and/or operations of method 460 may include and/or be interchanged with the described components and/or operations described in relation to FIG. 1- FIG. 3.

[0072] At 462, the method 460 may include collecting a portion of encoded tokenized debug statements. For example, when code of a computing program is compiled for a debugging operation, a portion of encoded tokenized debug statements present within the code may be collected. [0073] The portion of the encoded tokenized debug statements that are collected may the portion of the encoded tokenized debug statements that are present within the portion of the code of the computing program that is the subject of the debugging operation.

[0074] Each of the encoded tokenized debug statements that are collected may be tagged with a data characteristic designation tag designating a characteristic or category of the encoded tokenized debug statement as determined and/or encoded by the developer of the portion of the code. The data characteristic designation tag may be utilized to selectively sort and filter the encoded tokenized debug statements. For example, the data characteristic designation tag may be used to identify the tokenized debug statements which may be compiled in an instruction set to be executed to generate an encoded trace. In some examples, the data characteristic designation tag may be used to identify the tokenized debug statements resulting from the execution of the instruction set which may be included in an encoded trace. That is, the data characteristic designation tag may be utilized to perform a first level filtering to prevent correspondingly tagged data from being compiled into the instruction set that is to be executed to generate data which may be collected to generate the encoded trace. Further, the data characteristic designation tag may be utilized to perform a second level filtering to prevent correspondingly tagged data collected from the execution of the compiled instruction set from being incorporated into the encoded trace. Additionally, the data characteristic designation tag may be used to identify the encoded tokenized debug statements for which data to decode them is included in a catalog.

[0075] At 464, the method 460 may include generating a catalog. Generating the catalog may include creating a catalog that omits data associated with a tokenized debug statement that is tagged with a proprietary data characteristic designation tag. That is, the data for decoding the tokenized debug statement that is tagged with a proprietary data characteristic designation tag may be omitted from the catalog.

[0076] As such, the generated catalog may not be utilizable to decode the encoded tokenized debug statement that is tagged with a proprietary data characteristic designation tag into a human readable representation of the underlying data. The underlying data corresponding to the encoded tokenized debug statement that is tagged with a proprietary data characteristic designation tag may remain undecoded when utilizing the generated catalog to decode an encoded trace.

[0077] Another catalog may be generated that is utilizable to decode the encoded tokenized debug statement that is tagged with the proprietary data characteristic designation tag into a human readable representation of the underlying data. That is, the additional catalog may include the data to decode the encoded tokenized debug statement that is tagged with the proprietary data characteristic tag. [0078] Each of the catalogs may be stored in a distinct repository. Each of the repositories may store the portion of the collected encoded tokenized debug statements along with the catalog data to decode a portion of the portion of the collected encoded tokenized debug statements that are tagged with the data characteristic tag authorized by the developer to be decoded by the catalog. Access to each of the catalogs may be controlled utilizing credential restriction. That is, access to each repository may be credential-restricted.

[0079] At 466, the method 460 may include outputting, responsive to receiving a credential with the appropriate permissions for a particular catalog, a placeholder in place of a decoded version of the proprietary data tagged tokenized debug statement. In some examples, responsive to receiving a credential, the portion of the encoded tokenized debug statements for which the particular catalog includes decoding data may be outputted. For example, the output may be generated by decoding an encoded trace including the portion of the encoded tokenized debug statements by utilizing the catalog. The result of such a decoding may include decoded versions of encoded tokenized debug statements with non-proprietary data tags and placeholder versions of encoded tokenized debug statements with proprietary data tags.

[0080] For example, where the generated catalog has omitted the data associated with decoding a tokenized debug statement tagged with a proprietary data tag, the output generated by decoding an encoded trace using that catalog may not include a decoded version of the tokenized debug statement tagged with a proprietary data tag. Instead, the output may include the portion of the encoded tokenized debug statements with the proprietary data tagged tokenized debug statement replaced with a placeholder.

[0081] For example, the proprietary data tagged tokenized debug statement may be replaced with a statement communicating that a portion of the encoded tokenized debug statements that were part of the requested program code are not present in the output For example, the proprietary data tagged tokenized debug statement may be replaced with statement describing to the user that he/she has insufficient permission to view this data and/or that the missing data is proprietary. In contrast, a decoded version of a non-proprietary data tagged tokenized debug statement may present in the output utilizing the above described catalog as the basis for decoding.

[00821 In the foregoing detailed description of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how examples of the disclosure may be practiced. These examples are described in sufficient detail to enable those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples may be utilized and that process, electrical, and/or structural changes may be made without departing from the scope of the present disclosure. Further, as used herein, "a plurality of” an element and/or feature can refer to more than one of such elements and/or features.

[0083] The figures herein follow a numbering convention in which the first digit corresponds to the drawing figure number and the remaining digits identify an element or component in the drawing. Elements shown in the various figures herein may be capable of being added, exchanged, and/or eliminated so as to provide a number of additional examples of the disclosure. In addition, the proportion and the relative scale of the elements provided in the figures are intended to illustrate the examples of the disclosure and should not be taken in a limiting sense.

Claims

What is claimed:

1. A system, comprising: a processor; and a non-transitory machine-readable storage medium to store instructions executable by the processor to: generate a catalog; utilize the catalog to decode corresponding encoded tokenized debug statements; and utilize the catalog to prevent data associated with an encoded tokenized debug statement tagged with a first data characteristic designation tag from being decoded from an encoded trace.

2. The system of claim 1 , including instructions to generate an additional catalog to decode the corresponding encoded tokenized debug statements, wherein the additional catalog includes data to decode the data associated with encoded tokenized debug statement prevented from being decoded by the catalog.

3. The system of claim 2, wherein the catalog and the additional catalog are stored in separate repositories along with their corresponding encoded tokenized debug statements collected from the encoded trace.

4. The system of claim 2, including instructions to determine whether to provide access to the catalog or access to the additional catalog based on credentials associated with a request to access the encoded trace.

5. The system of claim 1 , wherein the tokenized debug statements are each tagged with a corresponding data characteristic designation within their respective code, wherein the corresponding data characteristic designations are utilized to identify data targeted for omission from the catalog.

6. The system of claim 5, wherein the corresponding data characteristic designations are utilized to identify data to be excluded from being collected during trace collection.

7. The system of claim 5, wherein the corresponding data characteristic designations are utilized to identify, prior to compiling an instructions set to be executed to produce the encoded trace, data to be excluded from being compiled in the instructions set.

8. A non-transitory machine-readable storage medium comprising instructions executable by a processor to: generate, in a first memory location, a first catalog including: data associated with decoding an encoded tokenized debug statement tagged with a first data characteristic designation tag, and data associated with decoding an encoded tokenized debug statement tagged with a second data characteristic designation tag; generate, in a second memory location, a second catalog omitting the data associated with decoding the encoded tokenized debug statement tagged with the first data characteristic designation tag; and determine, based on credential permissions, whether to make the first catalog or the second catalog visible to decode encoded tokenized debug statements of an encoded trace.

9. The non-transitory machine-readable storage medium of claim 8, including instructions executable by the processor to time stamp and buffer each of the encoded tokenized debug statements of the encoded trace prior to delivery to the first memory location.

10. The non-transitory machine-readable storage medium of claim 8, including instructions executable by the processor to determine a portion of tokenized debug statements in a program code to be collected in the encoded trace based on their corresponding data characteristic designation tags.

11. The non-transitory machine-readable storage medium of claim 8, wherein the first data characteristic designation tag designates a priority of the encoded tokenized debug statement tagged therewith.

12. The non-transitory machine-readable storage medium of claim 8, wherein the first data characteristic designation tag designates a data sensitivity of the encoded tokenized debug statement tagged therewith.

13. The non-transitory machine-readable storage medium of claim 8, wherein the first data characteristic designation tag designates a format of the encoded tokenized debug statement tagged therewith.

14. A method, comprising: collecting a portion of encoded tokenized debug statements; generating a catalog omitting data associated decoding with an encoded tokenized debug statement tagged with a proprietary data tag; and outputting, responsive to receiving a credential, a placeholder in place of a decoded version of the proprietary data tagged tokenized debug statement.

15. The method of claim 14, including: decoding encoded tokenized debug statements of the portion of the encoded tokenized debug statements without the proprietary data tag utilizing the catalog; and outputting decoded tokenized debug statements for the encoded tokenized debug statements without the proprietary data tag.