|
From: Mukund S. <mu...@sh...> - 2004-01-12 16:20:21
|
Hi=20 Attached is the small test case you asked for. The err.out file contains the errors as generated by valgrind.=20 Thanks Mukund -----Original Message----- From: Dirk Mueller [mailto:dm...@gm...]=20 Sent: Monday, January 12, 2004 7:58 AM To: val...@li... Subject: Re: [Valgrind-users] 2.6 kernel support On Monday 12 January 2004 16:24, Mukund Srinivasan wrote: > Is there a plan to support the 2.6 kernel features any > time soon? sure, you post small selfcontained examples that fail, and we'll fix them.=20 ------------------------------------------------------- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Mukund S. <mu...@sh...> - 2004-01-16 03:18:47
|
Hi Thanks I already tried it and it worked great for me. Thanks. Yes it will be awesome if it made it into the cvs=20 Thanks Mukund -----Original Message----- From: Dan Kegel [mailto:da...@ke...]=20 Sent: Thursday, January 15, 2004 6:23 PM To: Mukund Srinivasan Cc: Dirk Mueller; val...@li... Subject: Re: [Valgrind-users] 2.6 kernel support Mukund Srinivasan wrote: > Attached is the small test case you asked for. The err.out file contains > the errors as generated by valgrind.=20 Looks like valgrind 2.1.0 and cvs are missing the syscalls #define __NR_epoll_create 254 #define __NR_epoll_ctl 255 #define __NR_epoll_wait 256 I see that there's a patch for valgrind-2.0.0 to add epoll support at http://www.fefe.de/diffs/ Perhaps you could try 2.0.0 with that patch. It'd be nice if the epoll support made it into cvs sometime... - Dan |
|
From: Mukund S. <mu...@sh...> - 2004-01-19 23:14:51
|
Hi=20
Epoll_create internally uses wait locking(for threads) to create a
system resource that can hold the descriptors on the kernel table, So
you should assume both epoll_create and epoll_ctl can block
Epoll_wait is definitely blocking. Its exactly identical to poll which
is blocking.=20
Thanks
Mukund
-----Original Message-----
From: Tom Hughes [mailto:th...@cy...]=20
Sent: Monday, January 19, 2004 2:50 PM
To: val...@li...
Subject: Re: [Valgrind-users] 2.6 kernel support
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sun, 18 Jan 2004, Jeremy Fitzhardinge wrote:
>=20
> > It should be pretty easy to do in the 2.1 tree - you just need to
add
> > PRE and POST functions to deal with the args and return vals, work
out
> > which syscalls can block, and put the entries into the table. The
2.0
> > patch won't be much help though, because I presume most of it is to
do
> > with making epoll_* non-blocking, which isn't an issue any more.
>=20
> Are epoll_{create,ctl,wait} blocking or non-blocking?
Judging from the documentation I would think just epoll_wait is a
blocking call. I can't see any reason why either of the others should
ever block.
Tom
--=20
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Tom H. <th...@cy...> - 2004-01-19 23:48:18
|
In message <0F8...@ms...>
"Mukund Srinivasan" <mu...@sh...> wrote:
> Epoll_create internally uses wait locking(for threads) to create a
> system resource that can hold the descriptors on the kernel table, So
> you should assume both epoll_create and epoll_ctl can block
Is this locking something more than the normal type of kernel locks
that most system calls will wind up taking at some point? Only valgrind
doesn't normally consider a system call blocking just because it takes
a lock on a kernel structure at some point.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Tom H. <th...@cy...> - 2004-01-20 09:11:58
|
In message <3ee...@lo...>
Tom Hughes <th...@cy...> wrote:
> In message <0F8...@ms...>
> "Mukund Srinivasan" <mu...@sh...> wrote:
>
>> Epoll_create internally uses wait locking(for threads) to create a
>> system resource that can hold the descriptors on the kernel table, So
>> you should assume both epoll_create and epoll_ctl can block
>
> Is this locking something more than the normal type of kernel locks
> that most system calls will wind up taking at some point? Only valgrind
> doesn't normally consider a system call blocking just because it takes
> a lock on a kernel structure at some point.
Mukund has confirmed to me that it is only normal kernel locking that
he is talking about, so I think it is only epoll_wait that we need to
consider as blocking.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Dan K. <da...@ke...> - 2004-01-16 02:26:10
|
Mukund Srinivasan wrote: > Attached is the small test case you asked for. The err.out file contains > the errors as generated by valgrind. Looks like valgrind 2.1.0 and cvs are missing the syscalls #define __NR_epoll_create 254 #define __NR_epoll_ctl 255 #define __NR_epoll_wait 256 I see that there's a patch for valgrind-2.0.0 to add epoll support at http://www.fefe.de/diffs/ Perhaps you could try 2.0.0 with that patch. It'd be nice if the epoll support made it into cvs sometime... - Dan |
|
From: Nicholas N. <nj...@ca...> - 2004-01-19 22:37:25
|
On Sun, 18 Jan 2004, Jeremy Fitzhardinge wrote:
> It should be pretty easy to do in the 2.1 tree - you just need to add
> PRE and POST functions to deal with the args and return vals, work out
> which syscalls can block, and put the entries into the table. The 2.0
> patch won't be much help though, because I presume most of it is to do
> with making epoll_* non-blocking, which isn't an issue any more.
Are epoll_{create,ctl,wait} blocking or non-blocking?
N
|
|
From: Tom H. <th...@cy...> - 2004-01-19 22:49:45
|
In message <Pin...@ye...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Sun, 18 Jan 2004, Jeremy Fitzhardinge wrote:
>
> > It should be pretty easy to do in the 2.1 tree - you just need to add
> > PRE and POST functions to deal with the args and return vals, work out
> > which syscalls can block, and put the entries into the table. The 2.0
> > patch won't be much help though, because I presume most of it is to do
> > with making epoll_* non-blocking, which isn't an issue any more.
>
> Are epoll_{create,ctl,wait} blocking or non-blocking?
Judging from the documentation I would think just epoll_wait is a
blocking call. I can't see any reason why either of the others should
ever block.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-01-18 17:52:40
|
On Thu, 15 Jan 2004, Dan Kegel wrote: > Looks like valgrind 2.1.0 and cvs are missing the syscalls > #define __NR_epoll_create 254 > #define __NR_epoll_ctl 255 > #define __NR_epoll_wait 256 > > I see that there's a patch for valgrind-2.0.0 to add epoll support > at http://www.fefe.de/diffs/ > Perhaps you could try 2.0.0 with that patch. > > It'd be nice if the epoll support made it into cvs sometime... I thought it wasn't as simple as adding the entries to vg_syscalls.c, that it might sort-of work, but really deeper changes were needed... but that might be wrong. Anyone else know more? N |
|
From: Jeremy F. <je...@go...> - 2004-01-19 00:14:21
|
On Sun, 2004-01-18 at 09:52, Nicholas Nethercote wrote: > I thought it wasn't as simple as adding the entries to vg_syscalls.c, that > it might sort-of work, but really deeper changes were needed... but that > might be wrong. Anyone else know more? It should be pretty easy to do in the 2.1 tree - you just need to add PRE and POST functions to deal with the args and return vals, work out which syscalls can block, and put the entries into the table. The 2.0 patch won't be much help though, because I presume most of it is to do with making epoll_* non-blocking, which isn't an issue any more. J |