|
From: Adun R. <adu...@ml...> - 2004-08-10 04:45:05
|
> Note that since 2.1.1, the LD_PRELOAD method is no longer used. In your later post to this list you said that there is a FV method. This is the 2.1.2 doc, and the LD_PRELOAD is still mentioned there - http://developer.kde.org/~sewardj/docs-2.1.2/coregrind_core.html#howworks Please refer me to another source, thank you. > My opinion on Windows is that it would be great, if it could be done in a > way that doesn't result in Valgrind's code looking like a train crash. I would like to know how this stands against Valgrind 20031012-wine; do you think there's still a use for this idea? I believe the valgrind will look more of a debugger under Windows. For example, we can create the client process, and have it's main thread suspended. Regards, Rauch Adun. -- Adun R. adu...@ml... |
|
From: Nicholas N. <nj...@ca...> - 2004-08-10 08:49:27
|
On Mon, 9 Aug 2004, Adun R. wrote: >> Note that since 2.1.1, the LD_PRELOAD method is no longer used. > > In your later post to this list you said that there is a FV method. > This is the 2.1.2 doc, and the LD_PRELOAD is still mentioned there - > http://developer.kde.org/~sewardj/docs-2.1.2/coregrind_core.html#howworks > Please refer me to another source, thank you. Yes, this is out of date. Perhaps that section should just be removed altogether, because it's just misleading. The tech docs should have a big sign on them saying they're out of date too. As for a description of how the new version works, I'm working on my dissertation now which does cover this, see the text below. Please excuse the mark-up. As always, the source code is the best reference :) >> My opinion on Windows is that it would be great, if it could be done in a >> way that doesn't result in Valgrind's code looking like a train crash. > I would like to know how this stands against Valgrind 20031012-wine; do > you think there's still a use for this idea? I have no idea, I really don't understand that stuff at all. N \subsection{Starting Up} The following ingredients are used at start-up: \begin{itemize} \item Valgrind's loader (a statically-linked executable, called \code{valgrind}); \item Valgrind's core (a dynamically-linked executable, called \stagetwo); \item the tool plug-in (a shared object); \item the client program (an ELF executable, or a script). \end{itemize} %% The first step is to get the last three parts loaded into a single process, sharing the same address space. The loader is not present in the final layout; it is required because \stagetwo must end up at a high address, an address at which the operating system would not put it. The loader is loaded and executed normally by the operating system. The loader's single task is to load \stagetwo at a high address and execute it. Then \stagetwo does a preliminary parse of the command line options to see which tool has been chosen with the \code{--tool} option. It finds the shared object for the chosen tool and uses \code{dlopen()} to load the tool plug-in and any dynamic libraries the tool plug-in uses. Then \stagetwo loads the client executable (overwriting the no-longer-needed loader in the process). If the client program is a script, the script's interpreter is loaded. Both the loader and \stagetwo judiciously use empty memory mappings along the way to ensure the different pieces end up in the desired locations. The typical resulting memory layout is as follows. \begin{itemize} \item \hex{0xc0000000}--\hex{0xffffffff}: The top 1GB is reserved for the kernel on typical x86/Linux systems. \item \hex{0xb0000000}--\hex{0xbfffffff}: The next 256MB are used for \stagetwo and the tool plug-in, any libraries (shared objects) and mappings used by them, and their stack. (They do not need a heap, as all dynamic allocations are done using mappings.) \item \hex{0x00000000}--\hex{0xafffffff}: The lower part of the bottom 2.75GB is used for the client itself. The remainder is used for shadow memory required by the tool; the amount needed, if any, depends on the tool. (Shadow memory is discussed further in Section~\ref{Crucial Features}). \end{itemize} %% The chosen boundaries are selected with Valgrind build-time options and can be changed to suit less typical systems. Small (1MB) \emph{red-zones}---areas thatshould not be touched---separate each section. Once everything is in place, ``normal'' execution begins. The core (i.e.~\stagetwo) processes any command line arguments intended for it. Tool-specific arguments are possible; the core passes any arguments it does not recognise to the tool plug-in. The core initialises itself, and tells the tool to perform any initialisation it needs. Once all this is complete, the Valgrind tool is in complete control, and everything is in place to begin translating and executing the client from its first instruction. (In an earlier implementation, the core used the \LDPRELOAD environment variable to graft itself and the tool plug-in to the client process, and then ``hijacked'' execution. This approach was simpler but had four disadvantages. First, it did not work with statically linked executables. Second, the core did not gain control over the executable until some of the dynamic linker's code had run. Third, the client and Valgrind tool were not well separated in memory, so an erroneous client could wildly overwrite the tools code or data. Fourth, the core and tool plug-ins could not use any libraries also used by the client, including \glibc, and so had to use a private implementation of common library functions.) |