#28 Function with empty implementation gives wrong unfolding/xref

Default
open
2013-09-09
2013-09-05
No

Taking the init_time() function of H.264 decoder as a study case.

We can find its node right after unfolding main(), This function has also been instrumented in win32.cil.c.

The issue is that init_time() has an empty implementation but unfolding it provides 2 nodes. These nodes also make reference to unrelated source code.

1 Attachments

Related

Tickets: #30

Discussion

  • Mihai T. Lazarescu

    • assigned_to: Mihai T. Lazarescu
     
  • Mihai T. Lazarescu

    Using the project I got from you:

    • I cannot see an init_time() after unfolding main() (see
      attached main_unfold.pdf);
    • no statements or data transfers are recorded in the profile
      file for the init_time() call stack (#2).
     
    Last edit: Mihai T. Lazarescu 2013-09-09
  • Leonardo Solis Vasquez

    I forgot to mention:those project files were produced before updating ParTools.
    The up-to-date results are attached here.
    See also the screenshot: unfold_main_with_init_time.pdf

     
    Last edit: Leonardo Solis Vasquez 2013-09-05
    • Mihai T. Lazarescu

      Now I can see it. :-)

      init_time() is not empty, see lcommon/src/win32.c:38:

      void init_time(void)
      {
        QueryPerformanceFrequency(&freq);
      }
      

      So, the bug appears to be that the cross-reference of the
      statements in its body is not right.

      This may have to do with calling a function that does NOT
      return a value. Can you confirm that this is true also for
      the other cases?

       
  • Leonardo Solis Vasquez

    Yes, init_time() is defined in lcommon/src/win32.c.
    However, its implementation depends on _WIN32:

    /*file win32.c*/
    
    #ifdef _WIN32
    
        static LARGE_INTEGER freq;
    
        // Other functions
    
        void init_time(void)
        {
          QueryPerformanceFrequency(&freq);
        }
    
    #else
    
        // Other functions
    
        void init_time(void)
        {
        }
    
    #endif
    

    In this case _WIN32 has not been explicitly defined and I think the implementation is the empty one. I corroborated this with Eclipse IDE for C/C++ which provides a detailed call hierarchy view. By the way, no return value from both cases.

    Moreover, we can find other functions with no return value using the same trace expansion view e.g: Configure(), defined in /ldecod/src/decoder_test.c:

    /*file decoder_test.c*/
    
    // declarations
    static void Configure(InputParameters *p_Inp, int ac, char *av[])
    {
      // Other statements
    
      ParseCommand(p_Inp, ac, av) // declared as void!
    
      // Other statements
    }
    

    The xref from the Configure() node to its source code works fine. The same is true for ParseCommand() (ldecod/src/configfile.c).

     
    • Mihai T. Lazarescu

      The spurious statement nodes are due to the instrumentation
      of the dependencies on global variables.

      Currently, these are attached to the first function called in
      a source file, which for win32.c appears to be init_time().

      These are declared in the function partools_decl_globals()
      that is attached at the end of each annotated source, e.g.:

      static void
      partools_decl_globals(void)
      {
          {
              if (partools_decl_globals_done)
                  return;
      
              partools_stmt_id_local_offset = partools_stmt_id_global_offset;
              partools_stmt_id_global_offset += 893;
      
              partools_loop_id_local_offset = partools_loop_id_global_offset;
              partools_loop_id_global_offset += 12;
      
              partools_decl("ColorComponent", (void *)(&ColorComponent), 4, 1, 1, "JM/ldecod/inc/defines.h", 239);
              partools_write(partools_stmt_id_local_offset + 892, "ColorComponent", (void *)(&ColorComponent), 4, "JM/ldecod/../lcommon/src/win32.c", 74, 0);
      
              partools_decl("tz", (void *)(&tz), 8, 1, 1, "JM/ldecod/../lcommon/src/win32.c", 54);
              partools_write(partools_stmt_id_local_offset + 891, "tz", (void *)(&tz), 8, "JM/ldecod/../lcommon/src/win32.c", 74, 0);
      
              partools_decl_globals_done = 1;
          }
      }
      

      Now, the issues are actually:

      1. these dependencies should be displayed differently by the
        viewer, not as node statements;
      2. the location should be that of the global
        variable declarations. Locations as
        "JM/ldecod/../lcommon/src/win32.c", 74 make no sense.
       
      Last edit: Mihai T. Lazarescu 2013-09-09
      • Mihai T. Lazarescu

        Solved the location issue (item (2) above).

         

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks