|
From: KJK::Hyperion <no...@li...> - 2004-03-22 20:21:51
|
At 00.41 22/03/2004, Jeremy Fitzhardinge wrote: >Well, the data is the big thing, so you'd stll have the problem of fitting >everything into the one adderss space. memcheck uses 9 bits of shadow for >every 8 bits of client memory, so if they're both in the same address >space, you're always going to be able to use less than half the avaliable >adderss space for your program. I'm not too worried about memory usage (well, there's the issue of placing Valgrind data so that it doesn't conflict with certain non-relocable system DLLs... but there should be plenty of room in the middle). Separation of address spaces is more a matter of "playing by the rules". Anyway, how do tools register with the JIT engine so they are called at certain points? because the issue now is whether they can store most data in Valgrind's process and only require small "registration data" in the client, or not. Ideally, all tools (except maybe memcheck) should run in Valgrind's process and be called through some form of RPC by the JIT (running in the client), so their execution won't interfere with the client Apropos, I've downloaded some CVS release, but I have a hard time understanding much of it. Basically, all I've understood is that Valgrind has its own scheduler. The rest looks pretty obscure. What do you think would be the best way to get started on Valgrind internals? On an unrelated topic: does the core code depend on GCCisms? I've only seen surprisingly little inline assembler, some expression-with-statements, noreturn functions and functions with registry parameters - all of which have some equivalent in Windows compilers - and playing games with symbol names, which doesn't have effect on Win32. Is there much more? >It is really multithreaded as far as the client is concerned; *this* is what I'm not sure about. I've read the latest Microsoft SQL Server has its own scheduler, and I've read a pretty detailed description of it on the weblog of some Microsoft guy. It looks like it can work only for very specific operations, like only for file I/O - SQL server can afford it because, like all database servers, it's largely self-contained, but most applications aren't And don't forget the pervasive inter-process interactions. Pressing Control-C in a console, asyncronous signals lacking, always creates a thread in each process attached to the console. You right-click on the console window title and select the "properties" menu? a thread is created in the oldest process in order of attachment to display the property pages. And there's no way you can accurately duplicate the scheduler in user mode - some scheduler object may come from outside the process, or even from a driver, and only grant access for being waited on. My general impression is that Windows doesn't like cheaters (or at least loves to make their lifes miserable) Anyway, what about holding a mutex that is only yielded before system calls (and after some quantum expires, to prevent starvation)? isn't that more or less the behavior that Valgrind simulates? >Hm, that isn't all that high. Does that mean a process has less than 2G >of available address space under XP? maybe I'm confusing addresses. You know, all those hexadecimal digits... anyway </me fetches calculator>, the highest user-mode address is reported here (Windows 2000) as being 0x7FFEFFFF, meaning 64 Kb are unavailable. The shared read-only data begins at 0x7FFE0000, and includes the tick counter, some information about the kernel and of course the system call thunk. Not sure where the probe address is at, and if its semantics are what I believe they are (probably not) |