RE: mis-annotated inlined function

[Santos, J. R. G <jos...@hp...>]

=20
>> So it appears we have two cases:
>> 1) due to lack of symbolic debug information in some=20
>> modules, bfd_find_nearest_line finds some unrelated line=20
>> number and the samples get attributed to that line number,
>> 2) if there is a static inline function called then the=20
>> samples get annotated to the caller rather than the inline=20
>> function source.
>> In older versions of gcc(3.3.3), the function name returned=20
>> by bfd_get_nearest_line for an inlined function was the same=20
>> as the caller, so symbol_name =3D=3D function_name and=20
>> is_correct_function() returned true, and we got the correct=20
>> line number.  In newer versions of gcc(4.1.2) the inlined=20
>> function_name is correctly identified.
>>=20
>> 1) is clearly misleading but perhaps not that common, and 2)=20
>> is probably more common, but at least the attribution can be=20
>> rationalized.
>> If we can't handle both cases without the DWARF processing=20
>> overhead, do you want to stick with handling 1), or switch=20
>> to handling the more common case 2)?
>>=20

  Dave and John

If case2 is addressed, it would be nice to have a command option to
enable the user to choose how inline function samples should be
accounted (either attributed to themselves or to the parent function). I
found this "bug" is sometimes a "feature" and was very handy in some of
my experiments. Sometimes is good to have a smaller number of functions
aggregating a larger number of samples. I would be disappointed if this
"feature" was removed. :) Not sure if you were already planning this...
Thanks

Renato