Thread: [Valgrind-users] cachegrind on Darwin

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello there,

I know it is not implemented yet but I would like to know about the  
roadmap.

Thanks,

Luc

On Thu, May 28, 2009 at 6:03 PM, Luc Bourhis <luc...@ma...> wrote:
> Hello there,
>
> I know it is not implemented yet but I would like to know about the roadmap.

Actually, it is :)

Check out the SVN trunk:

http://www.valgrind.org/downloads/repository.html

Nick

On 29 May 2009, at 10:42, Josef Weidendorfer wrote:

> On Friday 29 May 2009, Nicholas Nethercote wrote:
>> On Thu, May 28, 2009 at 6:03 PM, Luc Bourhis  
>> <luc...@ma...> wrote:
>>> Hello there,
>>>
>>> I know it is not implemented yet but I would like to know about  
>>> the roadmap.
>>
>> Actually, it is :)
>
> Ha, I was not sure about this, as I do not have access to an OSX  
> machine.
> Can anybody test whether Callgrind is working, too?

I have just been trying it.

1) first valgrind --tool=cachegrind ls -l
result in
--36548-- WARNING: unhandled syscall: 33554774
--36548--            a.k.a.: 342

That is to say:

/usr/include/sys/syscall.h:#define	SYS_lstat64_extended 342

I read through README_MISSING_SYSCALL_OR_IOCTL and I could probably  
write the necessary patch but I won't have time to even start before  
well into next week. Quite likely one of you will have done it by then!

2) on one of my test program:
	valgrind --auto-run-dsymutil=yes --tool=cachegrind xxxx
followed by
	cg_annotate --auto=yes cachegrind.out.xxxx
and it prints the expected summary information as well as the line-by- 
line information. I haven't looked thoroughly through it to see  
whether it makes sense though.

Luc

> 1) first valgrind --tool=cachegrind ls -l
> result in
> --36548-- WARNING: unhandled syscall: 33554774
> --36548--            a.k.a.: 342
>

That's not cachegrind-specific, though.  That would happen regardless
of which --tool you select.

J

On Fri, May 29, 2009 at 8:43 PM, Luc Bourhis<luc...@ma...> wrote:
>
> --36548-- WARNING: unhandled syscall: 33554774
> --36548--            a.k.a.: 342
>
> That is to say:
>
> /usr/include/sys/syscall.h:#define      SYS_lstat64_extended 342
>
> I read through README_MISSING_SYSCALL_OR_IOCTL and I could probably write
> the necessary patch but I won't have time to even start before well into
> next week. Quite likely one of you will have done it by then!

I was just looking at this.  It's a tricky case, lstat64_extended()
has 4 arguments.  The first two are the same as lstat(), and are easy.
 But the last two are pointers, xsecurity and xsecurity_size, and I'm
having trouble working out how big are the buffers that they point to.

I think xsecurity_size points to a word-sized buffer, and that the
value in xsecurity_size is the size of xsecurity, and that
xsecurity_size is updated with the number of bytes written
(somewhere?) but I'm not completely sure.

Nick

On Wed, Jun 10, 2009 at 10:54 AM, Nicholas
Nethercote<n.n...@gm...> wrote:
>
> I was just looking at this.  It's a tricky case, lstat64_extended()
> has 4 arguments.  The first two are the same as lstat(), and are easy.
>  But the last two are pointers, xsecurity and xsecurity_size, and I'm
> having trouble working out how big are the buffers that they point to.
>
> I think xsecurity_size points to a word-sized buffer, and that the
> value in xsecurity_size is the size of xsecurity, and that
> xsecurity_size is updated with the number of bytes written
> (somewhere?) but I'm not completely sure.

I just discovered that stat_extended is already wrapped, so doing
lstat_extended from that should be easy.

Nick

On Wed, Jun 10, 2009 at 12:06 PM, Nicholas
Nethercote<n.n...@gm...> wrote:
> On Wed, Jun 10, 2009 at 10:54 AM, Nicholas
> Nethercote<n.n...@gm...> wrote:
>>
>> I was just looking at this.  It's a tricky case, lstat64_extended()
>> has 4 arguments.  The first two are the same as lstat(), and are easy.
>>  But the last two are pointers, xsecurity and xsecurity_size, and I'm
>> having trouble working out how big are the buffers that they point to.
>>
>> I think xsecurity_size points to a word-sized buffer, and that the
>> value in xsecurity_size is the size of xsecurity, and that
>> xsecurity_size is updated with the number of bytes written
>> (somewhere?) but I'm not completely sure.
>
> I just discovered that stat_extended is already wrapped, so doing
> lstat_extended from that should be easy.

stat_extended, lstat_extended, stat64_extended and lstat64_extended
are now implemented in the SVN trunk.

Thanks for the report.

Nick

Thread: [Valgrind-users] cachegrind on Darwin

valgrind-users