|
From: <sv...@va...> - 2005-08-28 11:01:16
|
Author: tom
Date: 2005-08-28 12:01:13 +0100 (Sun, 28 Aug 2005)
New Revision: 4551
Log:
Move the tool specific executables to the valgrind library directory
and implement a trivial launcher program that decides which tool to use
and exec's the relevant executable.
Added:
branches/ASPACEM/coregrind/m_launcher.c
Modified:
branches/ASPACEM/cachegrind/Makefile.am
branches/ASPACEM/coregrind/Makefile.am
branches/ASPACEM/lackey/Makefile.am
branches/ASPACEM/massif/Makefile.am
branches/ASPACEM/memcheck/Makefile.am
branches/ASPACEM/none/Makefile.am
Modified: branches/ASPACEM/cachegrind/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/cachegrind/Makefile.am 2005-08-28 10:17:00 UTC (rev =
4550)
+++ branches/ASPACEM/cachegrind/Makefile.am 2005-08-28 11:01:13 UTC (rev =
4551)
@@ -9,13 +9,13 @@
=20
noinst_HEADERS =3D cg_arch.h
=20
-bin_PROGRAMS =3D valgrind_cachegrind
+val_PROGRAMS =3D cachegrind
=20
-valgrind_cachegrind_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrin=
d.a
-valgrind_cachegrind_SOURCES =3D \
+cachegrind_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a
+cachegrind_SOURCES =3D \
cg_main.c \
cg-@VG_ARCH@.c
-valgrind_cachegrind_LDFLAGS =3D \
+cachegrind_LDFLAGS =3D \
-static \
$(top_srcdir)/coregrind/libcoregrind.a \
-Wl,-defsym,valt_load_address=3D@VALT_LOAD_ADDRESS@ \
Modified: branches/ASPACEM/coregrind/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/coregrind/Makefile.am 2005-08-28 10:17:00 UTC (rev 4=
550)
+++ branches/ASPACEM/coregrind/Makefile.am 2005-08-28 11:01:13 UTC (rev 4=
551)
@@ -33,6 +33,9 @@
RANLIB =3D echo "Not really ranlib-ing"
## end of hack
=20
+bin_PROGRAMS =3D \
+ valgrind
+
val_PROGRAMS =3D \
vg_preload_core.so
=20
@@ -89,6 +92,10 @@
BUILT_SOURCES =3D=20
CLEANFILES =3D=20
=20
+valgrind_SOURCES =3D \
+ m_launcher.c \
+ m_debuglog.c
+
libcoregrind_a_SOURCES =3D \
m_cpuid.S \
m_debugger.c \
Added: branches/ASPACEM/coregrind/m_launcher.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/coregrind/m_launcher.c 2005-08-28 10:17:00 UTC (rev =
4550)
+++ branches/ASPACEM/coregrind/m_launcher.c 2005-08-28 11:01:13 UTC (rev =
4551)
@@ -0,0 +1,91 @@
+
+/*--------------------------------------------------------------------*/
+/*--- Launching valgrind m_launcher.c ---*/
+/*--------------------------------------------------------------------*/
+
+/*
+ This file is part of Valgrind, a dynamic binary instrumentation
+ framework.
+
+ Copyright (C) 2000-2005 Julian Seward=20
+ js...@ac...
+
+ This program is free software; you can redistribute it and/or
+ modify it under the terms of the GNU General Public License as
+ published by the Free Software Foundation; either version 2 of the
+ License, or (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program; if not, write to the Free Software
+ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+ 02111-1307, USA.
+
+ The GNU General Public License is contained in the file COPYING.
+*/
+
+#include <errno.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+
+#include "pub_core_basics.h"
+#include "pub_core_debuglog.h"
+#include "pub_core_libcproc.h" // For VALGRINDLIB
+
+/* Where we expect to find all our aux files */
+static const char *valgrind_lib =3D VG_LIBDIR;
+
+int main(int argc, char** argv, char** envp)
+{
+ const char *toolname =3D NULL;
+ const char *cp;
+ int i, loglevel;
+ char *toolfile;
+
+ /* Start the debugging-log system ASAP. First find out how many=20
+ "-d"s were specified. This is a pre-scan of the command line. */
+ loglevel =3D 0;
+ for (i =3D 1; i < argc; i++) {
+ if (argv[i][0] !=3D '-')
+ break;
+ if (0 =3D=3D strcmp(argv[i], "--"))=20
+ break;
+ if (0 =3D=3D strcmp(argv[i], "-d"))=20
+ loglevel++;
+ if (0 =3D=3D strncmp(argv[i], "--tool=3D", 7))=20
+ toolname =3D argv[i] + 7;
+ }
+
+ /* ... and start the debug logger. Now we can safely emit logging
+ messages all through startup. */
+ VG_(debugLog_startup)(loglevel, "Stage 1");
+
+ if (toolname) {
+ VG_(debugLog)(1, "stage1", "tool %s requested\n", toolname);
+ } else {
+ VG_(debugLog)(1, "stage1", "no tool requested, defaulting to memch=
eck\n");
+ toolname =3D "memcheck";
+ }
+
+ cp =3D getenv(VALGRINDLIB);
+
+ if (cp !=3D NULL)
+ valgrind_lib =3D cp;
+
+ toolfile =3D malloc(strlen(valgrind_lib) + strlen(toolname) + 2);
+ sprintf(toolfile, "%s/%s", valgrind_lib, toolname);
+
+ VG_(debugLog)(1, "stage1", "launching %s\n", toolfile);
+
+ execve(toolfile, argv, envp);
+
+ fprintf(stderr, "valgrind: failed to start %s: %s", toolname, strerro=
r(errno));
+
+ exit(1);
+}
Modified: branches/ASPACEM/lackey/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/lackey/Makefile.am 2005-08-28 10:17:00 UTC (rev 4550=
)
+++ branches/ASPACEM/lackey/Makefile.am 2005-08-28 11:01:13 UTC (rev 4551=
)
@@ -1,11 +1,11 @@
include $(top_srcdir)/Makefile.tool.am
=20
-bin_PROGRAMS =3D valgrind_lackey
+val_PROGRAMS =3D lackey
=20
-valgrind_lackey_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a
-valgrind_lackey_SOURCES =3D \
+lackey_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a
+lackey_SOURCES =3D \
lk_main.c
-valgrind_lackey_LDFLAGS =3D \
+lackey_LDFLAGS =3D \
-static \
$(top_srcdir)/coregrind/libcoregrind.a \
-Wl,-defsym,valt_load_address=3D@VALT_LOAD_ADDRESS@ \
Modified: branches/ASPACEM/massif/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/massif/Makefile.am 2005-08-28 10:17:00 UTC (rev 4550=
)
+++ branches/ASPACEM/massif/Makefile.am 2005-08-28 11:01:13 UTC (rev 4551=
)
@@ -2,8 +2,7 @@
=20
SUBDIRS +=3D hp2ps
=20
-val_PROGRAMS =3D vgpreload_massif.so
-bin_PROGRAMS =3D valgrind_massif
+val_PROGRAMS =3D massif vgpreload_massif.so
=20
vgpreload_massif_so_SOURCES =3D=20
vgpreload_massif_so_DEPENDENCIES =3D \
@@ -13,10 +12,10 @@
$(LIBREPLACEMALLOC) \
-Wl,--no-whole-archive
=20
-valgrind_massif_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a
-valgrind_massif_SOURCES =3D \
+massif_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a
+massif_SOURCES =3D \
ms_main.c
-valgrind_massif_LDFLAGS =3D \
+massif_LDFLAGS =3D \
-static \
$(top_srcdir)/coregrind/libcoregrind.a \
-Wl,-defsym,valt_load_address=3D@VALT_LOAD_ADDRESS@ \
Modified: branches/ASPACEM/memcheck/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/memcheck/Makefile.am 2005-08-28 10:17:00 UTC (rev 45=
50)
+++ branches/ASPACEM/memcheck/Makefile.am 2005-08-28 11:01:13 UTC (rev 45=
51)
@@ -3,8 +3,7 @@
## Build Memcheck at a higher optimisation level
AM_CFLAGS +=3D -O2
=20
-val_PROGRAMS =3D vgpreload_memcheck.so
-bin_PROGRAMS =3D valgrind_memcheck
+val_PROGRAMS =3D memcheck vgpreload_memcheck.so
=20
vgpreload_memcheck_so_SOURCES =3D \
mac_replace_strmem.c
@@ -15,14 +14,14 @@
$(LIBREPLACEMALLOC) \
-Wl,--no-whole-archive
=20
-valgrind_memcheck_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.=
a
-valgrind_memcheck_SOURCES =3D \
+memcheck_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a
+memcheck_SOURCES =3D \
mac_leakcheck.c \
mac_malloc_wrappers.c \
mc_main.c \
mac_shared.c \
mc_translate.c
-valgrind_memcheck_LDFLAGS =3D \
+memcheck_LDFLAGS =3D \
-static \
$(top_srcdir)/coregrind/libcoregrind.a \
-Wl,-defsym,valt_load_address=3D@VALT_LOAD_ADDRESS@ \
Modified: branches/ASPACEM/none/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- branches/ASPACEM/none/Makefile.am 2005-08-28 10:17:00 UTC (rev 4550)
+++ branches/ASPACEM/none/Makefile.am 2005-08-28 11:01:13 UTC (rev 4551)
@@ -1,11 +1,11 @@
include $(top_srcdir)/Makefile.tool.am
=20
-bin_PROGRAMS =3D valgrind_none
+val_PROGRAMS =3D none
=20
-valgrind_none_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a
-valgrind_none_SOURCES =3D \
+none_DEPENDENCIES =3D $(top_srcdir)/coregrind/libcoregrind.a
+none_SOURCES =3D \
nl_main.c
-valgrind_none_LDFLAGS =3D \
+none_LDFLAGS =3D \
-static \
$(top_srcdir)/coregrind/libcoregrind.a \
-Wl,-defsym,valt_load_address=3D@VALT_LOAD_ADDRESS@ \
|
|
From: Tom H. <to...@co...> - 2005-08-28 11:59:12
|
In message <200...@ja...>
sv...@va... wrote:
> Author: tom
> Date: 2005-08-28 12:01:13 +0100 (Sun, 28 Aug 2005)
> New Revision: 4551
>
> Log:
> Move the tool specific executables to the valgrind library directory
> and implement a trivial launcher program that decides which tool to use
> and exec's the relevant executable.
One problem with this at the moment is that it only looks for --tool in
the arguments to valgrind and not in VALGRIND_OPTS or .valgrindrc.
I have abstracted out the command line processing from m_main.c into a
new file which can then be linked into the launcher program so that it
can easily process all the options, and it seems to work.
The problem is that the command line handling uses various functions
from valgrind's internal libc and in order to avoid linking that into
the launcher (which quickly got out of control, especially malloc) I had
to give the launcher versions of about a dozen VG_ libc routines which
are implemented using the real libc.
The real pains were assert_fail and strcmp_ws which don't exist as
such in the normal C library.
Does all this sound like a reasonable approach? or does anybody have
a better suggestion how to handle this?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-28 15:43:52
|
On Sun, 28 Aug 2005, Tom Hughes wrote: > The problem is that the command line handling uses various functions > from valgrind's internal libc and in order to avoid linking that into > the launcher (which quickly got out of control, especially malloc) I had > to give the launcher versions of about a dozen VG_ libc routines which > are implemented using the real libc. > > The real pains were assert_fail and strcmp_ws which don't exist as > such in the normal C library. You could do it more concisely with pre-processor hackery. See memcheck/tests/oset_test.c for an example. It's a bit nasty, though. For assert_fail, I'd do a simpler version. For example, you don't have to distinguish between core vs tool errors. Also, I wouldn't worry about the call to report_and_quit(), ie. all the stack tracing stuff. (More or less) duplicating strcmp_ws seems fine to me. Nick |
|
From: Nicholas N. <nj...@cs...> - 2005-08-28 15:36:43
|
On Sun, 28 Aug 2005, sv...@va... wrote: > Log: > Move the tool specific executables to the valgrind library directory > and implement a trivial launcher program that decides which tool to use > and exec's the relevant executable. Nice work, Tom. How will this relate to getting transparent handling of 32- and 64-bit programs working on AMD64? It seems like this launcher would be the right place to detect which stage2 (stage2_32 or stage2_64) is needed. That would require parsing the command line a bit more to find the file being executed, and then inspecting the ELF header. Is that the right way to do it? N |
|
From: Nicholas N. <nj...@cs...> - 2005-08-28 15:45:59
|
On Sun, 28 Aug 2005, Tom Hughes wrote: > That is my plan, yes. It's a bit more complicated than that because > if it is a script you have to parse the #! line to get the interpreter > and then probe the ELF header of the interpreter. Yes. This trivial wrapper is quickly looking like the old stage1.c :) > What I'm thinking is to create x86-linux and amd64-linux subdirectories > under the normal valgrind library directory, move all the static tool > executables and the preload libraries there so we have two copies and > then get the launcher to choose the right ones. Is the normal approach to have lib/ and lib64/ directories? And maybe bin/ and bin64/ directories? If that's the standard approach we should follow it. N |
|
From: Tom H. <to...@co...> - 2005-08-28 15:52:45
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Sun, 28 Aug 2005, Tom Hughes wrote:
>
> > What I'm thinking is to create x86-linux and amd64-linux subdirectories
> > under the normal valgrind library directory, move all the static tool
> > executables and the preload libraries there so we have two copies and
> > then get the launcher to choose the right ones.
>
> Is the normal approach to have lib/ and lib64/ directories? And maybe
> bin/ and bin64/ directories? If that's the standard approach we should
> follow it.
Well it is (although not universal - at least one linux distro has
not gone that way for amd64). This is actually a bit different though...
What we're specifying here is not the architecture that valgrind is
complied to run on (ie lib vs lib64) but the architecture of the binaries
a given tool is designed to run. There is (in principle) nothing to
prevent have a /usr/lib64/valgrind/solaris-sparc/memcheck tool on an
amd64 linux box if we ever got to the point of being able to do cross
platform/os emulation.
In other words it is more like the directories under /usr/lib/gcc
which correspond to the targets you can build code for if you have
cross compilers installed.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-28 15:42:39
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> How will this relate to getting transparent handling of 32- and 64-bit
> programs working on AMD64? It seems like this launcher would be the right
> place to detect which stage2 (stage2_32 or stage2_64) is needed. That
> would require parsing the command line a bit more to find the file being
> executed, and then inspecting the ELF header. Is that the right way to do
> it?
That is my plan, yes. It's a bit more complicated than that because
if it is a script you have to parse the #! line to get the interpreter
and then probe the ELF header of the interpreter.
What I'm thinking is to create x86-linux and amd64-linux subdirectories
under the normal valgrind library directory, move all the static tool
executables and the preload libraries there so we have two copies and
then get the launcher to choose the right ones.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|