tom | 2878c81 | 2005-11-07 18:06:10 +0000 | [diff] [blame] | 1 | ------------------------------------------------------------------- |
| 2 | Guide to multiple architecture support |
| 3 | ------------------------------------------------------------------- |
| 4 | |
sewardj | 0126214 | 2006-01-04 01:20:28 +0000 | [diff] [blame^] | 5 | What is achieved |
| 6 | ~~~~~~~~~~~~~~~~ |
| 7 | Valgrind supports systems where binaries for more than one |
| 8 | architecture can be run. The current arrangements build: |
tom | 2878c81 | 2005-11-07 18:06:10 +0000 | [diff] [blame] | 9 | |
sewardj | 0126214 | 2006-01-04 01:20:28 +0000 | [diff] [blame^] | 10 | - single-arch support on x86 and ppc32 systems |
| 11 | - dual-arch support on amd64 and ppc64 systems |
tom | 2878c81 | 2005-11-07 18:06:10 +0000 | [diff] [blame] | 12 | |
sewardj | 0126214 | 2006-01-04 01:20:28 +0000 | [diff] [blame^] | 13 | To support this the valgrind build system can now build multiple |
| 14 | versions of the coregrind library and of VEX, and then build and link |
| 15 | multiple versions of each tool. |
| 16 | |
| 17 | A central notion is that of 'primary' vs 'secondary' platforms. The |
| 18 | system is built in its entirety for the primary platform, including |
| 19 | performance and regression suites and all auxiliary programs. For |
| 20 | dual-arch systems, the primary platform is amd64 and ppc64 |
| 21 | respectively. |
| 22 | |
| 23 | On dual-arch systems, there is a 'secondary' target - x86 and ppc32 |
| 24 | respectively. The tools are built again for the secondary target, and |
| 25 | the 'valgrind' launcher program can handle executables for either the |
| 26 | primary or secondary target. However, the regression and performance |
| 27 | tests and everything else is not rebuilt for the secondary target. |
| 28 | |
| 29 | On single-arch systems, there is no secondary target. |
| 30 | |
| 31 | |
| 32 | How the build system does that |
| 33 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 34 | The keys to understanding this are in: |
| 35 | |
| 36 | - configure.in |
| 37 | - Makefile.flags.am |
| 38 | - <tool>/tests/Makefile.am |
| 39 | - <tool>/tests/<arch>/Makefile.am |
| 40 | - perf/Makefile.am |
| 41 | |
| 42 | The configure script inspects the CPU. It then sets |
| 43 | |
| 44 | VG_PLATFORM_PRI to be the primary target |
| 45 | VG_PLATFORM_SEC to be the secondary target, if any |
| 46 | |
| 47 | (VG_PLATFORM_SEC is only used for printing an informational message at |
| 48 | configure time). |
| 49 | |
| 50 | It also sets one (single-arch build) or two (dual-arch build) of |
| 51 | the following: |
tom | 2878c81 | 2005-11-07 18:06:10 +0000 | [diff] [blame] | 52 | |
| 53 | VG_X86_LINUX |
| 54 | VG_AMD64_LINUX |
| 55 | VG_PPC32_LINUX |
sewardj | 0126214 | 2006-01-04 01:20:28 +0000 | [diff] [blame^] | 56 | VG_PPC64_LINUX |
tom | 2878c81 | 2005-11-07 18:06:10 +0000 | [diff] [blame] | 57 | |
| 58 | On an amd64 system both VG_X86_LINUX and VG_AMD64_LINUX will be true |
sewardj | 0126214 | 2006-01-04 01:20:28 +0000 | [diff] [blame^] | 59 | so that two versions of all the tools will be built. Similarly on a |
| 60 | ppc64 system both VG_PPC32_LINUX and VG_PPC64_LINUX will be defined. |
| 61 | For the amd64 example, the coregrind libraries will be named: |
tom | 2878c81 | 2005-11-07 18:06:10 +0000 | [diff] [blame] | 62 | |
| 63 | libcoregrind_x86_linux.a |
| 64 | libcoregrind_amd64_linux.a |
| 65 | |
| 66 | and the VEX libraries: |
| 67 | |
| 68 | libvex_x86_linux.a |
| 69 | libvex_amd64_linux.a |
| 70 | |
| 71 | Each tool will then be built twice, along with any preload library |
| 72 | for the tool and the core preload libraries. At install time one |
| 73 | subdirectory will be created in the valgrind library directory for |
| 74 | each supported platforms and the tools and shared objects will be |
| 75 | installed in the appropriate place. On amd64 the result will be: |
| 76 | |
| 77 | <prefix>/lib/valgrind |
| 78 | <prefix>/lib/valgrind/default.supp |
| 79 | <prefix>/lib/valgrind/glibc-2.4.supp |
| 80 | <prefix>/lib/valgrind/hp2ps |
| 81 | <prefix>/lib/valgrind/amd64-linux |
| 82 | <prefix>/lib/valgrind/amd64-linux/vgpreload_core.so |
| 83 | <prefix>/lib/valgrind/amd64-linux/vgpreload_massif.so |
| 84 | <prefix>/lib/valgrind/amd64-linux/cachegrind |
| 85 | <prefix>/lib/valgrind/amd64-linux/memcheck |
| 86 | <prefix>/lib/valgrind/amd64-linux/helgrind |
| 87 | <prefix>/lib/valgrind/amd64-linux/massif |
| 88 | <prefix>/lib/valgrind/amd64-linux/vgpreload_memcheck.so |
| 89 | <prefix>/lib/valgrind/amd64-linux/lackey |
| 90 | <prefix>/lib/valgrind/amd64-linux/none |
| 91 | <prefix>/lib/valgrind/amd64-linux/vgpreload_helgrind.so |
| 92 | <prefix>/lib/valgrind/xfree-3.supp |
| 93 | <prefix>/lib/valgrind/x86-linux |
| 94 | <prefix>/lib/valgrind/x86-linux/vgpreload_core.so |
| 95 | <prefix>/lib/valgrind/x86-linux/vgpreload_massif.so |
| 96 | <prefix>/lib/valgrind/x86-linux/cachegrind |
| 97 | <prefix>/lib/valgrind/x86-linux/memcheck |
| 98 | <prefix>/lib/valgrind/x86-linux/helgrind |
| 99 | <prefix>/lib/valgrind/x86-linux/massif |
| 100 | <prefix>/lib/valgrind/x86-linux/vgpreload_memcheck.so |
| 101 | <prefix>/lib/valgrind/x86-linux/lackey |
| 102 | <prefix>/lib/valgrind/x86-linux/none |
| 103 | <prefix>/lib/valgrind/x86-linux/vgpreload_helgrind.so |
| 104 | <prefix>/lib/valgrind/glibc-2.3.supp |
| 105 | <prefix>/lib/valgrind/xfree-4.supp |
| 106 | <prefix>/lib/valgrind/glibc-2.2.supp |
| 107 | |
sewardj | 0126214 | 2006-01-04 01:20:28 +0000 | [diff] [blame^] | 108 | The launcher program (ie the valgrind binary itself) is always built |
| 109 | as a program for the primary target (so a 64 bit program on amd64 and |
| 110 | ppc64) but will peek at the program which it is being asked to run and |
| 111 | decide which of the possible tools to run taking both the requested |
| 112 | tool and the format of the program being run into account. |
tom | 2878c81 | 2005-11-07 18:06:10 +0000 | [diff] [blame] | 113 | |
| 114 | Because the execv system call is now routed back through the launcher |
| 115 | it is also possible to exec an x86 program from an amd64 program and |
sewardj | 0126214 | 2006-01-04 01:20:28 +0000 | [diff] [blame^] | 116 | vice versa. Ditto ppc32 and ppc64. |
| 117 | |
| 118 | |
| 119 | Rules for Makefile.am hacking |
| 120 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| 121 | In places where compilation should happen twice (on a dual-arch |
| 122 | system), the decision about which directories and flags to use is |
| 123 | guarded by the symbols: |
| 124 | |
| 125 | VG_X86_LINUX |
| 126 | VG_AMD64_LINUX |
| 127 | VG_PPC32_LINUX |
| 128 | VG_PPC64_LINUX |
| 129 | |
| 130 | But there are also places where building must only happen once, |
| 131 | for the primary architecture. These places are (at least): |
| 132 | |
| 133 | * the launcher, valgrind.c |
| 134 | * all the architecture-independent regression tests |
| 135 | * the performance tests |
| 136 | * optionally, auxilary programs like hp2ps and valgrind-listener |
| 137 | |
| 138 | In order to do that, we need to know what flags to use to build for |
| 139 | the primary target, and in particular whether to hand -m32 or -m64 to |
| 140 | gcc. This is where Makefile.flags.am comes in. |
| 141 | |
| 142 | At the bottom of that file are defined AM_CPPFLAGS_PRI, AM_CFLAGS_PRI |
| 143 | and AM_CCASFLAGS_PRI that must be used for compiling for the primary |
| 144 | architecture. For example, look in coregrind/Makefile.am, and you |
| 145 | will see these flag-sets being used to build the launcher (valgrind). |
| 146 | |
| 147 | Also at the bottom of Makefile.flags.am, AM_FLAG_M3264_PRI is defined. |
| 148 | This gives the -m32/-m64 flag needed to build for the primary target. |
| 149 | That flag is also contained within AM_CFLAGS_PRI -- AM_FLAG_M3264_PRI |
| 150 | merely facilitates getting hold of it without the surrounding gunk. |
| 151 | |
| 152 | This leads to the final complication: building the regression tests. |
| 153 | Most of them are architecture-neutral and so should be built for the |
| 154 | primary target. The /test/ Makefile.am's duly include |
| 155 | AM_FLAG_M3264_PRI in the compilation invokations, and you should |
| 156 | ensure you preserve that when adding more tests. |
| 157 | |
| 158 | However, there are some arch-specific test directories (eg, |
| 159 | none/tests/ppc32, etc). In each of these, we implicitly 'know' |
| 160 | whether -m32 or -m64 is the right thing to specify. So instead of |
| 161 | messing with AM_FLAG_M3264_PRI, these directories merely specific |
| 162 | @FLAG_M32@ or @FLAG_M64@ directly. (These two symbols are also |
| 163 | automagically set up by configure.in. Do not use -m32 and -m64 |
| 164 | directly - older compilers barf on them). |
| 165 | |