Re: [RFC 3/3] Test on solib load and unload

[Yao Qi <yao@codesourcery.com>]

On 08/28/2013 07:31 PM, Agovic, Sanimir wrote:
>> +  for (i = 0; i < number; i++)
>> >+    {
>> >+      char funname[20];
>> >+      void *p;
>> >+
>> >+      sprintf (funname, "shr%d", i);
>> >+      p = dlsym (handles[i], funname);
>> >
> Does dlsym has any perf impact on the debugger?
>

Probably no much performance impact on the debugger, IMO.  dlsym is to 
resolve symbol in runtime, debugger is not much involved.

>> >+
>> >+gdb_test_no_output "python SolibLoadUnload\($SOLIB_NUMBER\)"
>> >+
>> >+# Call the convenience function registered by python script.
>> >+send_gdb "call \$perftest()\n"
>> >
> Not sure if a convenience function is necessary:
> python SolibLoadUnload().execute_test()
> could do the job as well.
>

Convenience function is useful to de-couple solib.py and solib.exp. 
solib.py adds a convenience function, while solib.exp is to call it.

>> >+
>> >+            start_time = time.clock()
>> >+            gdb.execute (do_test_command)
>> >+            elapsed_time = time.clock() - start_time
>> >+
>> >+            self.result.record (num, elapsed_time)
>> >+
>> >+            num = num / 2
>> >+            iteration -= 1
>> >
> You may consider observing solibs loads/unloads to compute the time
> between the events.
> Can you re-run the sample with turned off garbage collector? It may
> cause some jitter if turned on.

I don't know how much time is spent on jitter, but python code is
simple and most of the time should be spent on GDB, which is what we
want.  Thanks for your suggestion.  I'll re-run it with gc turned off,
to see if I can get something different.

-- 
Yao (齐尧)