Lassi, Did you look at the ia64 version of libunwind? It does handle VDSO. Frankly, I don't remember the details off hand, but if it doesn't make sense to you, let me know and I'll refresh my memory.
--david On Wed, Apr 21, 2010 at 9:14 AM, Lassi Tuura <[email protected]> wrote: > Hi, > > I've run our test applications with GCC 4.5.0 - built software, and indeed > the vast majority of inaccuracies have gone away with my recent patch set. > > There's two issues remaining to fix in libunwind: > > - Recognise the 'master' PLT entry. My x86_64 is_plt_entry() only > recognises the function PLT entries, but once in a blue moon we also get hit > in the entry that calls into dynamic linker to resolve functions. > > - Recognise VDSO. If I understand correctly, the VDSO does not show up in > the dynamic linker's list of shared objects, so tracing for kernel functions > (e.g. __vdso_gettimeofday()) fails. Any ideas how we should identify this > one? An address > 0xffffffffnnnnnnnn on x86-64 is very likely VDSO, but how > do I get the beginning address to feed the rest of the chain? Look in > /proc/self/maps? > > I didn't really look carefully yet, I know there's logic to parse > /proc/self/maps, and I think the unwind info is correct for the VDSO, so I > am just guessing VDSO is just not getting detected for one reason or > another. Will continue debugging but hints would be useful. > > Regards, > Lassi > > PS. Fortunately GCC 4.5.0 makes most of the inaccuracies due to missing > unwind info for function epilogues go away. > > _______________________________________________ > Libunwind-devel mailing list > [email protected] > http://lists.nongnu.org/mailman/listinfo/libunwind-devel > -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768
_______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
