Analyzing Auto-Generated Code and Code Verification Techniques

arguing with the machine analysis of auto n.w
1 / 20
Embed
Share

Explore the process of analyzing auto-generated code, different types of code verification methods, the challenges of code generation, and the importance of implementation verification. Discover insights on code analysis, code generators, IV&V approaches, and experiences with Matlab/Simulink in this informative presentation.

  • Code Analysis
  • Verification Techniques
  • Auto-Generated Code
  • Implementation Verification
  • Matlab

Uploaded on | 1 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.

E N D

Presentation Transcript


  1. Arguing With the Machine Analysis of Auto-Generated Code Jacob Cox Jacob.t.cox@ivv.nasa.gov 1

  2. Agenda Types of code verification General discussion of code generation Some experiences 2

  3. The Simple Life In the beginning people wrote FSW in C 3

  4. Code Analysis Static code analysis (Syntactic) Uses industrial analyzers Produces large numbers of false positives Warnings need checked by hand Implementation verification (Semantic) Tracing requirements and design elements to the software implementation Manual process 4

  5. Code Generators Take input and produce source code Input can be: UML Models & Diagrams Manual Input (drawing Object diagrams) Text Files (XML) Excel Etc. Input Generator Code 5

  6. IV&V Approaches Should we analyze the input instead of the output? This is the way we treat compilers Can you trust the generator? Is the generator a COTS product? Has IV&V been performed on it? Can you identify the generated source from the manually coded source? Is the generated code human readable? 6

  7. Matlab/Simulink The code had headers stating not to edit Warning found in these files were ignored The generator was trusted The generated code was hard Lack of comments Difficult algorithms Variables & function names that were machine created 7

  8. Dictionaries A common place to store information used by everyone. Commands Telemetry Faults The data is stored in XML files 8

  9. XML Text file Hierarchical data store Allows defining schemas Human readable <Dictionary> <Command> <Name>AddStarToCatalog<Name/> <Params/> <Param> <Name>RightAscentionHour<Name/> <Type>UnsignedByte<Type/> <MinVal>0<MinVal/> <MaxVal>23<MaxVal/> <Param/> <Command/> <Dictionary/> 9

  10. XSLT Is an XML transformation language Is XML Is naturally recursive Data in XML XSLT Resulting Text File Processor XSLT Script 10

  11. Using the Dictionaries All products are consistent since they come from the same source XSLT Converting to HTML XSLT Web Browser HTML Processor XSLT Converting to PDF XSLT Command Manual Processor Source File Source File Source File Source File Source File Source File Command Dictionary in XML Code Generator 11

  12. Results of the process Clearly readable code Stubs to place processing of Command Handlers Very efficient in code production Very in-efficient with respect to SLOC 12

  13. How Did the IV&V Project React Black box approach on validating the generators Compared input XML patterns to resulting code Static (syntactic) code analysis on the resulting code Traced appropriate requirements to the resulting code (semantic analysis) 13

  14. Klocworks Raw Results Warning Type ABR CMD-IPC 36 DP EHA EVR HandCoded 412 HSM Instrument Parameter 34 SMAC Total 482 ABV.STACK ASSIGCOND.GEN 12 2 12 2 FUNCRET.GEN 4 3 7 IF_CYCLE 2 11 2 5 20 IF_DEF_IN_HEADER_DECL 148 148 IF_DEF_IN_HEADER_EX IF_DUPL_HEADER 183 2 1 184 2 IF_MISS_DECL 612 80 2242 21 14 343 3312 IF_MULTI_KIND IF_ONLY_DECL 65 139 13 28 762 1936 87 2804 226 INC_CONTEXT INC_EXTRA 87 153 12 5 11 4 337 437 1 1 51 121 499 734 4 9 INCONSISTENT.LABEL 4 4 IPAR NPD.CHECK.CALL.MIGHT 13 14 13 14 NPD.CHECK.MIGHT NPD.CHECK.MUST 269 1113 61 330 1147 34 NPD.FUNC.MIGHT NPD.FUNC.MUST 1 12 1 12 NPD.GEN.MIGHT 1 1 Warnings from Klocwork are sorted by Autocode generator, or Handcoded NPD.GEN.MUST 2 2 PRECISION.LOSS 504 1 505 RETVOID.GEN RNPD.CALL 2 10 2 10 RNPD.DEREF 13 13 SV.FMT_STR.BAD_SCAN_FORMAT 1 1 SV.FMTSTR.GENERIC 3 3 SV.INCORRECT_RESOURCE_HANDLING 2 2 When warnings are put into a pivot table, the grouping of error types by Autocoder are apparent. SV.STR_PAR.UNDESIRED_STRING_PARAMET ER 2 2 SV.STRBO.BOUND_COPY 108 68 176 SV.STRBO.BOUND_SPRINTF 4 4 SV.STRBO.UNBOUND_COPY 2 2 SV.STRBO.UNBOUND_SPRINTF SV.TAINTED.INDEX_ACCESS 2 1 2 1 SV.TAINTED.LOOP_BOUND SV.TOCTOU.FILE_ACCESS 1 1 17 17 UNINIT.CTOR.MUST 1 1 UNINIT.STACK.MIGHT UNINIT.STACK.MUST 13 260 13 294 34 UNREACH.BREAK 10 96 106 UNREACH.GEN 443 255 55 36 63 852 UNREACH.RETURN 1 1 UNREACH.RETURN0 VA_UNUSED.GEN 40 160 40 801 569 19 20 33 VA_UNUSED.INIT VA_UNUSED.INITCONST 251 227 443 122 694 480 50 35 46 Total 2156 65 123 766 9115 47 302 1342 63 13979 14

  15. Examples Checking parameters to insure they are not greater than maximum value but not checking they were less then minimum. Pointer increments at the end of repeated blocks of code. Generally speaking, static code analysis on auto-generated code did not produce issues and the warnings fell into easily identified patterns. 15

  16. Code, Dictionaries and Requirements Project A Cmd Rqmnt Cmd Rqmnt Cmd Rqmnt Cmd Rqmnt Cmd Rqmnt Cmd Rqmnt Cmd Rqmnt Command Dictionary Code for FSW Plumbing Generator Cmd Rqmnt There is a transitive relationship between the requirements, the dictionary entries and the code implementation. Checking the requirement in code also verified the dictionary (at least the parts that generated code). Note: Semantic analysis of a command requirement found that mode restrictions Had disappeared from the dictionary. 16

  17. Code, Dictionaries and Requirements Ctd. Project B Parent Rqmnt Parent Rqmnt Parent Rqmnt Cmd Rqmnt shall be in the dictionary Code for FSW Plumbing Command Dictionary Generator Parent Rqmnt Parent Rqmnt Parent Rqmnt There is no relationship between the requirements and the dictionary entries or code implementation. A solution could be a reference to the parent requirement in the dictionary entry. 17

  18. Model Generated Code Fully model generated code which generates all the code using Class diagrams Sequence diagrams Activity diagrams, etc. Partially generated code where the generator creates headers and stubs that are filled in by hand Class diagrams Analysis should be on the Inputs to the generator Really just well structured Hand written code requiring the same analysis as regular Hand written code. 18

  19. Model Generated Code, Ctd. The Hybrid where the diagrams generate the code BUT there is hand written code embedded in the diagrams that is incorporated into the generated code. Semantic Analysis can be performed on the snippets Does IV&V perform static analysis on the handwritten parts? Would it be performed on the snippets only and how to identify them in the generated output? 19

  20. Questions? 20

More Related Content