Aubrey Li wrote: > On Mon, May 12, 2008 at 6:26 PM, Rafael Vanoni <Rafael.Vanoni at sun.com> > wrote: >> Li, Aubrey wrote: >> >>> Rafael Vanoni wrote: >>> >>> >>>> Aubrey Li wrote: >>>> >>>>> 2008/5/9 Rafael Vanoni Wrote: >>>>> >>>>>> Here's a patch for this one. >>>>>> Simple case of using uint64_t or 32_t for one of the arguments to >>>>>> dtrace_lookup_by_addr. >>>>>> >>>>> I'm not sure you found the root cause. >>>>> There are a few dtrace_lookup_by_addr calls under >>>>> $(SRC)/lib/libdtrace/common, they are always using (uint64_t *) as >>>>> the pointer type. Any thoughts why? >>>>> >>>> It's both type and casting. For instance, in >>>> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/l >>>> ib/libdtrace/common/dt_consume.c#845 >>>> >>>> There are references to dtrace_lookup_by_addr that always use >>>> uint64_t, and I'm not sure why they're not checking the bit depth. >>>> Could be either because it's still a private interface, the places >>>> that use it do the casting by themselves or it's a bug. >>>> >>>> >>> It is not a bug. >>> The address width should be 64-bit. >>> >> Why ? >> The 32bit kernel will never have 64bit symbols, and vice-versa. >> > > I didn't mean the kernel symbols, I mean the parameter of > dtrace_lookup_by_addr(). >> >>> Our issue should be fixed like this: >>> >>> offender_addr = (void *)(data->dtada_data + rec1->dtrd_offset); >>> size = (64 or 32); /* sysinfo to obtain system information, 32-bit or 64 >>> bit? */ >>> >>> switch (size) { >>> case 32: >>> pc = *(uint32_t *)offender_addr; >>> break; >>> case 64: >>> pc = *(uint64_t *)offender_addr; >>> break; >>> } >>> >>> dtrace_lookup_by_addr(g_dtp, pc, &sym, &dts); >>> ... >>> >>> >>> Does this make sense? >>> >> Well, both fixes are correct. >> I personally think there's no need for the extra code given that the >> #define __amd64 is there for exactly this purpose. >> > > "#define __amd64" forgot SPARC. > > And if powertop is taken out from ON makefile system, > there have to two different packages for i386 and amd64, even > if the difference is slight.
You're right, I overlook that. Here's the patch with these changes. thanks Rafael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: 5937.export URL: <http://mail.opensolaris.org/pipermail/tesla-dev/attachments/20080512/da0ac037/attachment.ksh>
