From: Dave N. <dc...@us...> - 2007-10-23 17:48:42
|
John Levon wrote: > On Mon, Oct 22, 2007 at 04:06:19PM -0700, Dave Nomura wrote: > > .... > >>> I don't know of a way to fix this without parsing DWARF ourselves. >>> >> Is parsing DWARF out of the question? >> > > It would totally kill performance I think. > > >> gdb seems to be able to correctly >> find the source line info for static inlines by looking at >> (bfd)->tdata.elf_obj_data but I'm not sure if it had to do some work to >> initialize that structure. >> > > !! > > So gdb just ignores the API and digs into bfd's inner workings??? That > is not nice. > I'm guessing that there is a place in that tdata structure to store a pointer to whatever you want. But it appears that gdb has to do a bunch of processing of the dwarf information and reference the condensed information in the tdata structure. I agree that this is probably too expensive. > >> If we have to choose between find_nearest_line() handling this other >> special case, or static inlines, which is the more common case? >> >> I would think static inlines would be pretty common since optimization >> creates them, and the reason someone is using oprofile, is to improve >> their program's performance. >> > > It's probably more common. I don't think we knew they were broken > previously. > So it appears we have two cases: 1) due to lack of symbolic debug information in some modules, bfd_find_nearest_line finds some unrelated line number and the samples get attributed to that line number, 2) if there is a static inline function called then the samples get annotated to the caller rather than the inline function source. In older versions of gcc(3.3.3), the function name returned by bfd_get_nearest_line for an inlined function was the same as the caller, so symbol_name == function_name and is_correct_function() returned true, and we got the correct line number. In newer versions of gcc(4.1.2) the inlined function_name is correctly identified. 1) is clearly misleading but perhaps not that common, and 2) is probably more common, but at least the attribution can be rationalized. If we can't handle both cases without the DWARF processing overhead, do you want to stick with handling 1), or switch to handling the more common case 2)? -- Dave Nomura LTC Linux Power Toolchain |