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.
> 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.
thanks
Rafael
