1

There is a device driver for a camera device provided to us as a .so library file by the vendor. Only the header file with API's is available which provides the list of functions that we can work with the device. Our application is linked with the .so library file provided by the vendor and uses the interface functions provided for our objective.

When we wanted to measure the time taken by our application in handling different tasks, we have added GCC -pg flag and compiled+built our application.

But we found that using this executable built with -pg, we are observing random failure in the camera image acquire functions. Since we are using the .so library file, we do not know what is going wrong inside that function.

So in general I wanted to understand what could be the possible reasons of such a failure mode. Any pointers or documents that can help what goes inside profiling and its side effects is appreciated.

BenC
  • 8,729
  • 3
  • 49
  • 68
Sriram
  • 28
  • 4

2 Answers2

2

This answer is a helpful overview of how the gcc -pg flag profiler actually works. The take-home point is mostly to do with possible changes to timing. If your library has any kind of time-sensitivity in it, introducing profiler overheads might be changing the time it takes to execute parts of the code, and perhaps violating some kind of constraint.

Community
  • 1
  • 1
Gian
  • 13,735
  • 44
  • 51
0

If you look at the gprof documentation, it would explain the implementation details:

Profiling works by changing how every function in your program is compiled so that when it is called, it will stash away some information about where it was called from. From this, the profiler can figure out what function called it, and can count how many times it was called. This change is made by the compiler when your program is compiled with the `-pg' option, which causes every function to call mcount (or _mcount, or __mcount, depending on the OS and compiler) as one of its first operations.

So the timing of your application would change quite a bit when you turn on -pg.

  • If you would like to instrument your code without significantly affecting the timings, you could possibly look at oprofile. It does not pose as significant an overhead as gprof does.

  • Another fairly recent tool that serves as a good lightweight profiling tool is perf.

  • The profiling tools are useful primarily in understanding the CPU bound pieces of your library/application and can help you optimize those critical pieces. Most of the time they serve to identify some culprit function/method which wastes CPU cycles. So do not use it as the sole piece for debugging any and all issues.

  • Most vendor libraries would also provide means to turn on extra debugging or dumping extra information during runtime. They include means such as environment variables, log files, /proc or /sys interfaces for drivers, etc. and sometimes even tools to increase debugging levels at runtime. See if you can leverage these.

  • If you have defined APIs in a library/driver, you should run unit-tests on them instead of trying to debug the whole application you've built.

    If you find a certain unit-test fails, send the source code of the unit-test to your vendor, and ask them to fix the bug. If it is not a bug, your vendor would at least point you towards the right set of APIs or the semantics to use.

Tuxdude
  • 47,485
  • 15
  • 109
  • 110