|
From: Jeremy F. <je...@go...> - 2004-01-15 00:47:34
|
Well, I'm still working (slowly) on the source tree rearrangement. I've put the current patch up at http://www.goop.org/~jeremy/valgrind/archdep.patch This may build and work on i386-linux (it did a while ago), but I may have just broken it. Either way, I'm posting it so people can get a look at where I'm going with this. So far, I've factored out vg_syscalls.c and vg_proxylwp.c, as well as *.S. vg_signals and vg_scheduler are next, and they should be simpler. I've been extracting parts of Doug's FreeBSD patch as required, but I haven't even compile-tested it, let alone run it. It shouldn't be too hard to rearrange the freebsd patch against my patch to get it working (but I wouldn't bother putting lots of effort into it for now, since I'm still changing things). I'm also beginning to move the purely x86-specific parts into the proper place - vg_(to|from)_ucode are the obvious candidates here, as are bits of vg_main. But since Julian is contemplating new innards to deal with other CPU architectures, I don't think I'll go to heroic lengths until we have a better idea of the future of UCode. J |
|
From: Doug R. <df...@nl...> - 2004-01-15 10:27:58
|
On Thu, 2004-01-15 at 00:45, Jeremy Fitzhardinge wrote: > Well, I'm still working (slowly) on the source tree rearrangement. I've > put the current patch up at > http://www.goop.org/~jeremy/valgrind/archdep.patch > This may build and work on i386-linux (it did a while ago), but I may > have just broken it. Either way, I'm posting it so people can get a > look at where I'm going with this. > > So far, I've factored out vg_syscalls.c and vg_proxylwp.c, as well as > *.S. vg_signals and vg_scheduler are next, and they should be simpler. > > I've been extracting parts of Doug's FreeBSD patch as required, but I > haven't even compile-tested it, let alone run it. It shouldn't be too > hard to rearrange the freebsd patch against my patch to get it working > (but I wouldn't bother putting lots of effort into it for now, since I'm > still changing things). I've read through the patch and it does look like a reasonably useful structure. Only one minor thing occurred to me while reading - you can use 'uname -m' to get a value for VG_PLAT_ARCH on FreeBSD. The other thing I've been thinking about recently is that now we can use library routines fairly safely, why not re-implement vg_proxylwp using pthreads? That would make the only non-portable part the actual syscall delivery. I might actually try that. In the meantime, I have been keeping my port up to date with valgrind cvs and implementing missing syscalls etc. I've also got the thing to work on FreeBSD 4.x which was a bit tricky since /proc doesn't include map filename information on 4.x. I ended up tweaking ume.c to preserve the filenames for the executable and interpreter and using dladdr() to look up the filename for valgrind's portion of the address space. If you are interested, you can look at the current state of my hackery using subversion: $ svn co svn://mailgate.nlsystems.com/repos/valgrind/branches/dfr valgrind-dfr Don't worry too much about tracking things though - I'm quite happy to do the work of merging when you commit the reorg. Subversion is really quite good at merging. > > I'm also beginning to move the purely x86-specific parts into the proper > place - vg_(to|from)_ucode are the obvious candidates here, as are bits > of vg_main. But since Julian is contemplating new innards to deal with > other CPU architectures, I don't think I'll go to heroic lengths until > we have a better idea of the future of UCode. I've been thinking about that too. One thing to bear in mind before you fix on a structure is the problem of amd64 and ia64. For amd64, the instruction set is almost identical with the main difference being a few extra prefixes and wider registers. A decompiler for amd64 should share almost all the i386 code. To a much lesser extent, the i386 decompiler would be useful on ia64 too since its possible to switch between ia64 and ia32 instruction sets at will. In practice, perhaps this doesn't happen though. |
|
From: Jeremy F. <je...@go...> - 2004-01-15 18:08:35
|
On Thu, 2004-01-15 at 02:27, Doug Rabson wrote: > The other thing I've been thinking about recently is that now we can use > library routines fairly safely, why not re-implement vg_proxylwp using > pthreads? That would make the only non-portable part the actual syscall > delivery. I might actually try that. Yes, that's on my list of things to do. I'm a bit worried by a few things; since the proxylwp does direct syscalls (invokes int 0x80 directly), the threads implementation has to be able to cope with that (which probably means 1:1 app thread:kernel thread ratio). The direct syscalls are still required so it can maintain the signal/restart state machine properly. On the plus size, it would allow me to drop the use of pipes as a thread communication/synchronisation mechanism, and use pthreads operations instead, which will be more efficient with any luck. Hm. There's still one hole in allowing unfettered use of system libraries - we need to make sure that any FDs opened are pushed into Valgrind's range. > I've been thinking about that too. One thing to bear in mind before you > fix on a structure is the problem of amd64 and ia64. For amd64, the > instruction set is almost identical with the main difference being a few > extra prefixes and wider registers. A decompiler for amd64 should share > almost all the i386 code. > > To a much lesser extent, the i386 decompiler would be useful on ia64 too > since its possible to switch between ia64 and ia32 instruction sets at > will. In practice, perhaps this doesn't happen though. I know ia64 has the ability to switch on a jump, but I was hoping that in practice the change only really happened at execve time (like amd64's transitions). If we were to support ia64 dynamic instruction set switching, it would complicate things quite a bit, since we'd have to have two complete implementations of the dynamic translator (not to mention the cost of switching between the client's instruction set and Valgrind's). J |
|
From: Doug R. <df...@nl...> - 2004-01-15 18:37:36
Attachments:
vg_proxylwp_pthread.c
|
On Thu, 2004-01-15 at 18:08, Jeremy Fitzhardinge wrote: > On Thu, 2004-01-15 at 02:27, Doug Rabson wrote: > > The other thing I've been thinking about recently is that now we can use > > library routines fairly safely, why not re-implement vg_proxylwp using > > pthreads? That would make the only non-portable part the actual syscall > > delivery. I might actually try that. > > Yes, that's on my list of things to do. I'm a bit worried by a few > things; since the proxylwp does direct syscalls (invokes int 0x80 > directly), the threads implementation has to be able to cope with that > (which probably means 1:1 app thread:kernel thread ratio). The direct > syscalls are still required so it can maintain the signal/restart state > machine properly. I put something together today (attached). I also had to tweak vg_mylibc.c somewhat since my pthreads library wanted to override sigprocmask, sigaction etc. I've attached the result for your amusement. > > On the plus size, it would allow me to drop the use of pipes as a thread > communication/synchronisation mechanism, and use pthreads operations > instead, which will be more efficient with any luck. I left the pipes alone in the interests of simplicity. > > Hm. There's still one hole in allowing unfettered use of system > libraries - we need to make sure that any FDs opened are pushed into > Valgrind's range. I didn't think of that. I don't think that any of the FreeBSD pthreads implementations has any internal file descriptors. I'm not sure about NPTL/linuxthreads. > > > I've been thinking about that too. One thing to bear in mind before you > > fix on a structure is the problem of amd64 and ia64. For amd64, the > > instruction set is almost identical with the main difference being a few > > extra prefixes and wider registers. A decompiler for amd64 should share > > almost all the i386 code. > > > > To a much lesser extent, the i386 decompiler would be useful on ia64 too > > since its possible to switch between ia64 and ia32 instruction sets at > > will. In practice, perhaps this doesn't happen though. > > I know ia64 has the ability to switch on a jump, but I was hoping that > in practice the change only really happened at execve time (like amd64's > transitions). If we were to support ia64 dynamic instruction set > switching, it would complicate things quite a bit, since we'd have to > have two complete implementations of the dynamic translator (not to > mention the cost of switching between the client's instruction set and > Valgrind's). I think that it probably never happens in practice. Just implementing an ia64 jit at all will be enough work without worrying about ia32 switching. |
|
From: Jeremy F. <je...@go...> - 2004-01-15 19:49:36
|
On Thu, 2004-01-15 at 10:37, Doug Rabson wrote: > I put something together today (attached). I also had to tweak > vg_mylibc.c somewhat since my pthreads library wanted to override > sigprocmask, sigaction etc. I've attached the result for your amusement. Have you tested it much? Hm. The more I look at it, the more potential problems I see. We're using a couple of signals for internal use, which are the same ones as the Linux libpthread uses for itself (deliberately; I wanted to keep things looking the same to the clients). We need to be sure to pay attention to that (NPTL's sigaction prevents setting handlers for those signals anyway, but of course we're going direct to the kernel). So I guess the prerequisite for this is that we use libc for signal management, if nothing else. Is that what you did to vg_mylibc? > I left the pipes alone in the interests of simplicity. Good idea. There's a few things which depend on the pipes, so they'll need some thinking about. > > Hm. There's still one hole in allowing unfettered use of system > > libraries - we need to make sure that any FDs opened are pushed into > > Valgrind's range. > > I didn't think of that. I don't think that any of the FreeBSD pthreads > implementations has any internal file descriptors. I'm not sure about > NPTL/linuxthreads. I don't think NPTL does, but LinuxThreads might because it has that manager thread thing. Maybe it does it all with signals. If it does use file descriptors, I presume it must do something to get them out of the way of the app's FDs. The FD allocation algorithm (first available) is part of the Unix API, and some programs depend on it, and would get upset to find unexpected FDs lying around. But my real concern was other libraries which open files, etc. stdio, for example. One possibility is to fully virtualize the client's FDs with a mapping table. That means we need to be able to intercept all ways in which the client and the kernel can refer to FDs to each other. For plain old read/write/open/close that's pretty simple, but mucking about with poll/select sets is a bit hairy and I'm a bit concerned about things like ioctls which can generate new FDs by unconventional means. > I think that it probably never happens in practice. Just implementing an > ia64 jit at all will be enough work without worrying about ia32 > switching. The impression I get is that the hardware ia32 emulation is so slow that hardly anyone uses it; Intel have a software dynamic-compilation ia32 emulator which is a lot faster (within spitting distance of a similarly clocked Xeon). J |
|
From: Robert S. <rsc...@un...> - 2004-01-15 20:16:41
|
On Thu, Jan 15, 2004 at 11:49:31AM -0800, Jeremy Fitzhardinge wrote: > I don't think NPTL does, but LinuxThreads might because it has that > manager thread thing. Maybe it does it all with signals. If it does > use file descriptors, I presume it must do something to get them out of Yes, LinuxThreads _does_ use file descriptors for this purpose. Robert --=20 Robert Schiele Tel.: +49-621-181-2517 Dipl.-Wirtsch.informatiker mailto:rsc...@un... |
|
From: Doug R. <df...@nl...> - 2004-01-15 20:16:47
|
On Thu, 2004-01-15 at 19:49, Jeremy Fitzhardinge wrote: > On Thu, 2004-01-15 at 10:37, Doug Rabson wrote: > > I put something together today (attached). I also had to tweak > > vg_mylibc.c somewhat since my pthreads library wanted to override > > sigprocmask, sigaction etc. I've attached the result for your amusement. > > Have you tested it much? Hm. The more I look at it, the more potential > problems I see. We're using a couple of signals for internal use, which > are the same ones as the Linux libpthread uses for itself (deliberately; > I wanted to keep things looking the same to the clients). We need to be > sure to pay attention to that (NPTL's sigaction prevents setting > handlers for those signals anyway, but of course we're going direct to > the kernel). I tested it on my FreeBSD build and it works ok for most of the tests which worked before (some of the tests fail for me anyway because of glibc-dependant stack traces etc.). The signal-dependant tests like signal2, sigaltstack seem to work. Yes, I'm aware of the internal signal thing and I left that alone apart from using pthread_kill to direct them to the proxy thread. It seems to me that VKI_SIGVGKILL might not be needed since pthread_cancel should be roughly equivalent. > > So I guess the prerequisite for this is that we use libc for signal > management, if nothing else. Is that what you did to vg_mylibc? Yes. Of the two pthread implementations I tested, one overrides all the signal calls to help it implement its many user threads to few kernel threads policy. > > > I left the pipes alone in the interests of simplicity. > > Good idea. There's a few things which depend on the pipes, so they'll > need some thinking about. > > > > Hm. There's still one hole in allowing unfettered use of system > > > libraries - we need to make sure that any FDs opened are pushed into > > > Valgrind's range. > > > > I didn't think of that. I don't think that any of the FreeBSD pthreads > > implementations has any internal file descriptors. I'm not sure about > > NPTL/linuxthreads. > > I don't think NPTL does, but LinuxThreads might because it has that > manager thread thing. Maybe it does it all with signals. If it does > use file descriptors, I presume it must do something to get them out of > the way of the app's FDs. The FD allocation algorithm (first available) > is part of the Unix API, and some programs depend on it, and would get > upset to find unexpected FDs lying around. > > But my real concern was other libraries which open files, etc. stdio, > for example. > > One possibility is to fully virtualize the client's FDs with a mapping > table. That means we need to be able to intercept all ways in which the > client and the kernel can refer to FDs to each other. For plain old > read/write/open/close that's pretty simple, but mucking about with > poll/select sets is a bit hairy and I'm a bit concerned about things > like ioctls which can generate new FDs by unconventional means. That would work pretty well in most cases. I don't think there can be many weird ways for ioctls to generate new FDs. We need to handle them all for proper fd leak checking anyway. > > > I think that it probably never happens in practice. Just implementing an > > ia64 jit at all will be enough work without worrying about ia32 > > switching. > > The impression I get is that the hardware ia32 emulation is so slow that > hardly anyone uses it; Intel have a software dynamic-compilation ia32 > emulator which is a lot faster (within spitting distance of a similarly > clocked Xeon). I was just reading about that yesterday on The Register. I've used the hardware ia32 emulation on Itanium 1 early hardware and it sucks big time. Software is likely to be lots faster. |
|
From: Jeremy F. <je...@go...> - 2004-01-16 01:59:45
|
On Thu, 2004-01-15 at 12:16, Doug Rabson wrote: > Yes, I'm aware of the internal signal thing and I left that alone apart > from using pthread_kill to direct them to the proxy thread. It seems to > me that VKI_SIGVGKILL might not be needed since pthread_cancel should be > roughly equivalent. Yes, but I'm concerned about getting entangled in the internal details of how the pthreads implementation handles pthread_cancel. > Yes. Of the two pthread implementations I tested, one overrides all the > signal calls to help it implement its many user threads to few kernel > threads policy. OK, but presumably that pthread implementation is unusable to us, since directly calling int 0x80 from a thread will potentially deadlock the threads library. We would need to make sure that each proxy gets its own kernel-level schedulable entity when we actually try to run a syscall. > > One possibility is to fully virtualize the client's FDs with a mapping > > table. That means we need to be able to intercept all ways in which the > > client and the kernel can refer to FDs to each other. For plain old > > read/write/open/close that's pretty simple, but mucking about with > > poll/select sets is a bit hairy and I'm a bit concerned about things > > like ioctls which can generate new FDs by unconventional means. > > That would work pretty well in most cases. I don't think there can be > many weird ways for ioctls to generate new FDs. We need to handle them > all for proper fd leak checking anyway. Yes, but leak checking doesn't need to be completely correct - the penalty for getting it a bit wrong is just that we give less good errors for that case. If we fully virtualize FDs, then we have to be 100% correct. > I was just reading about that yesterday on The Register. I've used the > hardware ia32 emulation on Itanium 1 early hardware and it sucks big > time. Software is likely to be lots faster. ...and then we have the fun of multiple layers of dynamic compilation... J |
|
From: Doug R. <df...@nl...> - 2004-01-16 09:51:50
|
On Fri, 2004-01-16 at 01:57, Jeremy Fitzhardinge wrote: > On Thu, 2004-01-15 at 12:16, Doug Rabson wrote: > > Yes, I'm aware of the internal signal thing and I left that alone apart > > from using pthread_kill to direct them to the proxy thread. It seems to > > me that VKI_SIGVGKILL might not be needed since pthread_cancel should be > > roughly equivalent. > > Yes, but I'm concerned about getting entangled in the internal details > of how the pthreads implementation handles pthread_cancel. True. > > > Yes. Of the two pthread implementations I tested, one overrides all the > > signal calls to help it implement its many user threads to few kernel > > threads policy. > > OK, but presumably that pthread implementation is unusable to us, since > directly calling int 0x80 from a thread will potentially deadlock the > threads library. We would need to make sure that each proxy gets its > own kernel-level schedulable entity when we actually try to run a > syscall. This happens automatically in the FreeBSD kernel. When a thread blocks in the kernel, an upcall to the userland thread scheduler happens and it switches to the next runnable thread. It was an interesting exercise putting together a pthread proxylwp implementation but its certainly not the right solution for some systems. For example on FreeBSD 4.x there is no decent support for kernel threads and the userland threading library relies on intercepting all the blocking syscalls and using poll(2) in the thread scheduler to attempt to switch threads when they would block. > > > > One possibility is to fully virtualize the client's FDs with a mapping > > > table. That means we need to be able to intercept all ways in which the > > > client and the kernel can refer to FDs to each other. For plain old > > > read/write/open/close that's pretty simple, but mucking about with > > > poll/select sets is a bit hairy and I'm a bit concerned about things > > > like ioctls which can generate new FDs by unconventional means. > > > > That would work pretty well in most cases. I don't think there can be > > many weird ways for ioctls to generate new FDs. We need to handle them > > all for proper fd leak checking anyway. > > Yes, but leak checking doesn't need to be completely correct - the > penalty for getting it a bit wrong is just that we give less good errors > for that case. If we fully virtualize FDs, then we have to be 100% > correct. Very true. > > > I was just reading about that yesterday on The Register. I've used the > > hardware ia32 emulation on Itanium 1 early hardware and it sucks big > > time. Software is likely to be lots faster. > > ...and then we have the fun of multiple layers of dynamic compilation... No no, stop it. VMware running bochs running valgrind translating an ia64 implementation of gdb simulating a mips64. |
|
From: Jeremy F. <je...@go...> - 2004-01-17 01:02:48
|
On Fri, 2004-01-16 at 01:51, Doug Rabson wrote: > This happens automatically in the FreeBSD kernel. When a thread blocks > in the kernel, an upcall to the userland thread scheduler happens and it > switches to the next runnable thread. Ah, OK. That sounds like an interesting thing to virtualize when we move to a threading model in which we expose virtual kernel interfaces rather than just pthreads. > It was an interesting exercise putting together a pthread proxylwp > implementation but its certainly not the right solution for some > systems. For example on FreeBSD 4.x there is no decent support for > kernel threads and the userland threading library relies on intercepting > all the blocking syscalls and using poll(2) in the thread scheduler to > attempt to switch threads when they would block. Is that because FreeBSD 4.x doesn't have any kind of kernel-level shared-address-space thread thing? Is it that the poll trick works for looking at syscalls which block on FDs, but doesn't really help for other types of blocking syscall? How important is FreeBSD 4.x as a target? J |
|
From: Doug R. <df...@nl...> - 2004-01-17 09:50:30
|
On Sat, 2004-01-17 at 01:00, Jeremy Fitzhardinge wrote: > On Fri, 2004-01-16 at 01:51, Doug Rabson wrote: > > This happens automatically in the FreeBSD kernel. When a thread blocks > > in the kernel, an upcall to the userland thread scheduler happens and it > > switches to the next runnable thread. > > Ah, OK. That sounds like an interesting thing to virtualize when we > move to a threading model in which we expose virtual kernel interfaces > rather than just pthreads. That might be quite interesting indeed. It is possible that I might be able to get the kernel threading authors involved if necessary though since this stuff is fairly recent and is still being actively maintained. > > > It was an interesting exercise putting together a pthread proxylwp > > implementation but its certainly not the right solution for some > > systems. For example on FreeBSD 4.x there is no decent support for > > kernel threads and the userland threading library relies on intercepting > > all the blocking syscalls and using poll(2) in the thread scheduler to > > attempt to switch threads when they would block. > > Is that because FreeBSD 4.x doesn't have any kind of kernel-level > shared-address-space thread thing? Is it that the poll trick works for > looking at syscalls which block on FDs, but doesn't really help for > other types of blocking syscall? There is a shared-address-space fork which I used to get proxylwp working minimally on 4.x. I think the main problem with it as far as pthreads goes might be the signal routing thing that linuxthreads has - in fact there is a port of linuxthreads. The base system pthreads implementation is purely user-space threading. > > How important is FreeBSD 4.x as a target? I'm not quite sure. I might have some people who want FreeBSD 4.x support for their own use but they probably don't need complete support (probably not full pthreads support for instance). I'm still waiting to hear from them. |
|
From: Jeremy F. <je...@go...> - 2004-01-17 19:30:14
|
On Sat, 2004-01-17 at 01:50, Doug Rabson wrote: > On Sat, 2004-01-17 at 01:00, Jeremy Fitzhardinge wrote: > > On Fri, 2004-01-16 at 01:51, Doug Rabson wrote: > > > This happens automatically in the FreeBSD kernel. When a thread blocks > > > in the kernel, an upcall to the userland thread scheduler happens and it > > > switches to the next runnable thread. > > > > Ah, OK. That sounds like an interesting thing to virtualize when we > > move to a threading model in which we expose virtual kernel interfaces > > rather than just pthreads. > > That might be quite interesting indeed. It is possible that I might be > able to get the kernel threading authors involved if necessary though > since this stuff is fairly recent and is still being actively > maintained. There's a tension between how we want to implement Valgrind and the kinds of client programs we want to support. For Valgrind internally, we'd like to use the most portable code and interfaces, so pthreads rather than clone. But we want to support all the clients, including those which use clone/rfork/upcalls directly. This means we need to do some things near the kernel interface to virtualize all those things. For Linux with clone, signals are the only real problem, and only in 2.4. Upcalls sound tricky; I don't know how they work (any docs pointers?), but it seems that if the kernel does an upcall, we need to intercept it, decide whether it is aimed at our libpthread or at the client, and do the appropriate demultiplexing. Given the large number of ways in which libpthread can be possibly implemented, it means that using libpthread for Valgrind itself doesn't necessarily give us any portability gains, because we still need to deal with the raw kernel interface on the client's behalf. The question is whether using libpthread is a net gain or loss of portability/complexity, and the answer isn't obviously clear to me. Anyway, all the more reason to do a FreeBSD port, from my perspective. > There is a shared-address-space fork which I used to get proxylwp > working minimally on 4.x. I think the main problem with it as far as > pthreads goes might be the signal routing thing that linuxthreads has - > in fact there is a port of linuxthreads. The base system pthreads > implementation is purely user-space threading. OK; what are rfork's signal semantics? Is it simply that signals arrive at the process they're aimed at, with no shared signal state? Does the existing signal router in vg_signals.c cope with this correctly? J |
|
From: Doug R. <df...@nl...> - 2004-01-17 21:38:24
|
On Sat, 2004-01-17 at 18:30, Jeremy Fitzhardinge wrote: > On Sat, 2004-01-17 at 01:50, Doug Rabson wrote: > > On Sat, 2004-01-17 at 01:00, Jeremy Fitzhardinge wrote: > > > On Fri, 2004-01-16 at 01:51, Doug Rabson wrote: > > > > This happens automatically in the FreeBSD kernel. When a thread blocks > > > > in the kernel, an upcall to the userland thread scheduler happens and it > > > > switches to the next runnable thread. > > > > > > Ah, OK. That sounds like an interesting thing to virtualize when we > > > move to a threading model in which we expose virtual kernel interfaces > > > rather than just pthreads. > > > > That might be quite interesting indeed. It is possible that I might be > > able to get the kernel threading authors involved if necessary though > > since this stuff is fairly recent and is still being actively > > maintained. > > There's a tension between how we want to implement Valgrind and the > kinds of client programs we want to support. For Valgrind internally, > we'd like to use the most portable code and interfaces, so pthreads > rather than clone. But we want to support all the clients, including > those which use clone/rfork/upcalls directly. > > This means we need to do some things near the kernel interface to > virtualize all those things. For Linux with clone, signals are the only > real problem, and only in 2.4. Upcalls sound tricky; I don't know how > they work (any docs pointers?), but it seems that if the kernel does an > upcall, we need to intercept it, decide whether it is aimed at our > libpthread or at the client, and do the appropriate demultiplexing. There are some reasonable descriptions of the userland interface in the kse(2) manpage. I imagine a few of the hairy details might still be locked in the developer's heads but the manpage is a good place to get started. > > Given the large number of ways in which libpthread can be possibly > implemented, it means that using libpthread for Valgrind itself doesn't > necessarily give us any portability gains, because we still need to deal > with the raw kernel interface on the client's behalf. > > The question is whether using libpthread is a net gain or loss of > portability/complexity, and the answer isn't obviously clear to me. Well I don't expect any real programs except a pthread implementation to actually use these interfaces so perhaps its not a problem. On the other hand we don't get to interpose our own libpthread for statically linked programs. Regardless, I imagine the people implementing libpthread using the KSE syscalls might find it useful to have a version of valgrind that they can use to validate their work. > > Anyway, all the more reason to do a FreeBSD port, from my perspective. Right. > > > There is a shared-address-space fork which I used to get proxylwp > > working minimally on 4.x. I think the main problem with it as far as > > pthreads goes might be the signal routing thing that linuxthreads has - > > in fact there is a port of linuxthreads. The base system pthreads > > implementation is purely user-space threading. > > OK; what are rfork's signal semantics? Is it simply that signals arrive > at the process they're aimed at, with no shared signal state? Does the > existing signal router in vg_signals.c cope with this correctly? I think thats right but I haven't delved too deeply into it. I think the existing signal router should do the job - are there any valgrind test cases that test that particular feature? |
|
From: Jeremy F. <je...@go...> - 2004-01-18 08:32:14
|
On Sat, 2004-01-17 at 13:38, Doug Rabson wrote: > There are some reasonable descriptions of the userland interface in the > kse(2) manpage. I imagine a few of the hairy details might still be > locked in the developer's heads but the manpage is a good place to get > started. OK. I had a bit of a look at that, but now that I've got FreeBSD 5 running under VMware, I'll get more of a chance. Hm, I just found http://www.freebsd.org/kse/ which seems to have everything. > Well I don't expect any real programs except a pthread implementation to > actually use these interfaces so perhaps its not a problem. On the other > hand we don't get to interpose our own libpthread for statically linked > programs. Regardless, I imagine the people implementing libpthread using > the KSE syscalls might find it useful to have a version of valgrind that > they can use to validate their work. Well, there are definitely real programs which use clone() directly under Linux, and there have been requests to implement clone to support them. So that's already in the plan. There are also problems of secret, private, highly-version-dependent interfaces between libpthread and glibc which I don't think we can support in any dependable way. So using the native libpthread is becoming more appealing for that reason. The downside is that it becomes much harder to guess what the thread state of a particular thread is if we only look at the syscall stream coming out of it ("why has it blocked? is it waiting on a mutex? or something else?"). As you say, another benefit of this is that we instrument libpthread itself (and we've certainly found enough strange things in glibc). But that's all a digression. I was actually talking about making Valgrind itself use libpthread to manage its concurrency (ie, your patch), and how we can multiplex Valgrind's libpthread demands and the client's kernel/libpthread demands. > I think thats right but I haven't delved too deeply into it. I think the > existing signal router should do the job - are there any valgrind test > cases that test that particular feature? Don't think so particularly. I've only been consistently adding regression tests for bugs recently. J |