Re: Get the caller of socket_lock()
Re: Get the caller of socket_lock()
- Subject: Re: Get the caller of socket_lock()
- From: Laurent Dumont <email@hidden>
- Date: Wed, 02 Aug 2006 14:09:18 -0700
I think this is because the source you have for the socket structure is for
the ppc version, and gdb uses that to find the offsets and fields for
everything.
You could try replacing the reserved3/reserved4 by the new fields in the
copy of the sourcefile xnu/bsd/sys/socketvar.h that is used by gdb to
determine the structure format. If that fails, you may have to look at the
structure in hex with gdb and figure out the last part by hand.
Those fields are used for internal debug and not part of the KPI, which
provides accessors to certain fields of the socket structure. That's why the
format is not in sync with the sources you have...
on 8/2/06 13:49, Michael Tuexen at email@hidden wrote:
> Hi Laurent,
>
> hmmm, sounds really good, but we do not see the symbols you mention
> being part of the socket structure... How can we access the fields
> in gdb?
>
> Thank you very much in advance.
>
> Best regards
> Michael
>
> On Aug 2, 2006, at 10:23 PM, Laurent Dumont wrote:
>
>> Michael,
>>
>> On 10.4.x for i386 there is a slightly different debug mechanism
>> for the
>> socket lock and unlock. Instead of reserved3 and reserverd4, there is
>> circular buffers with the 4 last lock/unlocks for the socket:
>>
>> u_int32_t lock_lr[4];
>> int next_lock_lr;
>> u_int32_t unlock_lr[4];
>> int next_unlock_lr;
>>
>> "next_lock_lr" and "next_unlock_lr" provide the number (0 to 3) for
>> the next
>> debug link register slot to be used. You can work your way from n-1
>> and find
>> the last four lock/unlock recorded for that socket.
>>
>> Laurent
>>
>>
>>
>> on 8/2/06 11:23, Michael Tuexen at email@hidden
>> wrote:
>>
>>> Dear all,
>>>
>>> we are currently debugging a locking issue on Mac OS X on Intel. It
>>> is related to
>>> socket locks and we are able to break into the debugger to inspect
>>> the socket
>>> structures. On PPC one can find the last caller of the socket_lock()
>>> function,
>>> but is there a similar way in doing it in Intel, possibly by
>>> inspecting the reserved3
>>> or reserved4 fields in the socket structure? What is stored in these
>>> fields?
>>>
>>> Thank you very much for your help in advance.
>>>
>>> Best regards
>>> Michael
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Darwin-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden