From: Vitali L. <vit...@pa...> - 2009-12-04 05:24:39
|
Hi, I noticed the ruby script on the oprofile website that tries to provide kernel symbol resolution when a System.map (or /proc/kallsyms) file is available. I already converted it to C++, but I would rather integrate it into opreport. Can someone provide me with a pointer as to where the appropriate injection point would be so I can save myself some time? If opreport does the vma address -> symbol name resolution, where does that happen? If it's the kernel module that does it on the fly as it's sampling, where would an appropriate injection point be? Thanks, Vitali |
From: Maynard J. <may...@us...> - 2009-12-08 17:30:43
|
Vitali Lovich wrote: > Hi, I noticed the ruby script on the oprofile website that tries to provide kernel symbol resolution when a System.map (or /proc/kallsyms) file is available. I already converted it to C++, but I would rather integrate it into opreport. > > Can someone provide me with a pointer as to where the appropriate injection point would be so I can save myself some time? If opreport does the vma address -> symbol name resolution, where does that happen? If it's the kernel module that does it on the fly as it's sampling, where would an appropriate injection point be? In libpp/populate.cpp:populate_for_image, we create an op_bfd object based on the binary image whose samples we're currently processing. In the case where we use "--no-vmlinux" at profile time, the image namge will be "no-vmlinux". The op_bfd constructor will fail to find a real file by that name so it simply creates a fake symbol and sticks it in the symbols list for the op_bfd object. So you should detect the case of image name == no-vmlinux and do your /proc/kallsyms processing and add the symbols into the op_bfd's symbols list. -Maynard > > Thanks, > Vitali > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: Vitali L. <Vit...@pa...> - 2009-12-08 18:09:56
|
Thank you so much. Hopefully this won't be too much work since I already have the ruby script converted to C++. ________________________________________ From: Maynard Johnson [may...@us...] Sent: Tuesday, December 08, 2009 9:30 AM To: Vitali Lovich Cc: opr...@li... Subject: Re: integrating ruby script into opreport Vitali Lovich wrote: > Hi, I noticed the ruby script on the oprofile website that tries to provide kernel symbol resolution when a System.map (or /proc/kallsyms) file is available. I already converted it to C++, but I would rather integrate it into opreport. > > Can someone provide me with a pointer as to where the appropriate injection point would be so I can save myself some time? If opreport does the vma address -> symbol name resolution, where does that happen? If it's the kernel module that does it on the fly as it's sampling, where would an appropriate injection point be? In libpp/populate.cpp:populate_for_image, we create an op_bfd object based on the binary image whose samples we're currently processing. In the case where we use "--no-vmlinux" at profile time, the image namge will be "no-vmlinux". The op_bfd constructor will fail to find a real file by that name so it simply creates a fake symbol and sticks it in the symbols list for the op_bfd object. So you should detect the case of image name == no-vmlinux and do your /proc/kallsyms processing and add the symbols into the op_bfd's symbols list. -Maynard > > Thanks, > Vitali > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |