|
From: Matthias S. <zz...@ge...> - 2015-08-10 18:52:52
|
Hi! I have seen that valgrind.h will missdetect x32 as amd64. So I wonder if this can cause any bad effects. If so, the header needs to be protected so it does not emit client requests on x32. It could be done like this, because the x32 ABI says that __ILP32__ must be defined (and it is not defined on amd64). See abi.pdf in https://sites.google.com/site/x32abi/documents Regards Matthias --- a/include/valgrind.h +++ b/include/valgrind.h @@ -140,7 +140,7 @@ # define PLAT_amd64_win64 1 #elif defined(__linux__) && defined(__i386__) # define PLAT_x86_linux 1 -#elif defined(__linux__) && defined(__x86_64__) +#elif defined(__linux__) && defined(__x86_64__) && !defined(__ILP32__) # define PLAT_amd64_linux 1 #elif defined(__linux__) && defined(__powerpc__) && !defined(__powerpc64__) # define PLAT_ppc32_linux 1 |
|
From: Bart V. A. <bva...@ac...> - 2015-08-11 02:08:13
|
On 08/10/15 11:52, Matthias Schwarzott wrote: > Hi! > > I have seen that valgrind.h will missdetect x32 as amd64. > > So I wonder if this can cause any bad effects. > > If so, the header needs to be protected so it does not emit client > requests on x32. > It could be done like this, because the x32 ABI says that __ILP32__ must > be defined (and it is not defined on amd64). > See abi.pdf in https://sites.google.com/site/x32abi/documents > > Regards > Matthias > > > --- a/include/valgrind.h > +++ b/include/valgrind.h > @@ -140,7 +140,7 @@ > # define PLAT_amd64_win64 1 > #elif defined(__linux__) && defined(__i386__) > # define PLAT_x86_linux 1 > -#elif defined(__linux__) && defined(__x86_64__) > +#elif defined(__linux__) && defined(__x86_64__) && !defined(__ILP32__) > # define PLAT_amd64_linux 1 > #elif defined(__linux__) && defined(__powerpc__) && !defined(__powerpc64__) > # define PLAT_ppc32_linux 1 Hello Matthias, Has this patch been tested ? I think if you want the above to work correctly that you need to swap the x86 and amd64 detection code. Bart. |
|
From: Matthias S. <zz...@ge...> - 2015-08-11 18:10:23
|
Am 11.08.2015 um 04:07 schrieb Bart Van Assche: > On 08/10/15 11:52, Matthias Schwarzott wrote: >> Hi! >> >> I have seen that valgrind.h will missdetect x32 as amd64. >> >> So I wonder if this can cause any bad effects. >> >> If so, the header needs to be protected so it does not emit client >> requests on x32. >> It could be done like this, because the x32 ABI says that __ILP32__ must >> be defined (and it is not defined on amd64). >> See abi.pdf in https://sites.google.com/site/x32abi/documents >> >> Regards >> Matthias >> >> >> --- a/include/valgrind.h >> +++ b/include/valgrind.h >> @@ -140,7 +140,7 @@ >> # define PLAT_amd64_win64 1 >> #elif defined(__linux__) && defined(__i386__) >> # define PLAT_x86_linux 1 >> -#elif defined(__linux__) && defined(__x86_64__) >> +#elif defined(__linux__) && defined(__x86_64__) && !defined(__ILP32__) >> # define PLAT_amd64_linux 1 >> #elif defined(__linux__) && defined(__powerpc__) && >> !defined(__powerpc64__) >> # define PLAT_ppc32_linux 1 > > Hello Matthias, > > Has this patch been tested ? I think if you want the above to work > correctly that you need to swap the x86 and amd64 detection code. > > Bart. > Hello Bart, yes, I did a compile check with a very simple c file calling VALGRIND_PRINTF. Then I compiled this with -m32, -m64 and -mx32. With my modified valgrind.h and using -mx32 the VALGRIND_PRINTF did not leave traces in the executabe. Why should it be necessary to swap amd64 and x86 - it worked already before I touched it and stays like this. And x32 does not define __i386__. But I still don't know if it is necessary to exclude x32 or if it just does not matter. Regards Matthias |
|
From: Bart V. A. <bva...@ac...> - 2015-08-12 02:25:35
|
On 08/11/15 11:10, Matthias Schwarzott wrote: > Am 11.08.2015 um 04:07 schrieb Bart Van Assche: >> On 08/10/15 11:52, Matthias Schwarzott wrote: >>> Hi! >>> >>> I have seen that valgrind.h will missdetect x32 as amd64. >>> >>> So I wonder if this can cause any bad effects. >>> >>> If so, the header needs to be protected so it does not emit client >>> requests on x32. >>> It could be done like this, because the x32 ABI says that __ILP32__ must >>> be defined (and it is not defined on amd64). >>> See abi.pdf in https://sites.google.com/site/x32abi/documents >>> >>> Regards >>> Matthias >>> >>> >>> --- a/include/valgrind.h >>> +++ b/include/valgrind.h >>> @@ -140,7 +140,7 @@ >>> # define PLAT_amd64_win64 1 >>> #elif defined(__linux__) && defined(__i386__) >>> # define PLAT_x86_linux 1 >>> -#elif defined(__linux__) && defined(__x86_64__) >>> +#elif defined(__linux__) && defined(__x86_64__) && !defined(__ILP32__) >>> # define PLAT_amd64_linux 1 >>> #elif defined(__linux__) && defined(__powerpc__) && >>> !defined(__powerpc64__) >>> # define PLAT_ppc32_linux 1 >> >> Hello Matthias, >> >> Has this patch been tested ? I think if you want the above to work >> correctly that you need to swap the x86 and amd64 detection code. >> >> Bart. >> > Hello Bart, > > yes, I did a compile check with a very simple c file calling > VALGRIND_PRINTF. > Then I compiled this with -m32, -m64 and -mx32. > > With my modified valgrind.h and using -mx32 the VALGRIND_PRINTF did not > leave traces in the executabe. > > Why should it be necessary to swap amd64 and x86 - it worked already > before I touched it and stays like this. > And x32 does not define __i386__. > > But I still don't know if it is necessary to exclude x32 or if it just > does not matter. Ah, right, your purpose is that the Valgrind macros do not emit any client requests on x32. Unless this is very clearly documented that might be a confusing outcome for x32 users ... Maybe these users expect that if they build a program for x32 and analyze it with Valgrind that these macros just work ? Bart. |
|
From: Tom H. <to...@co...> - 2015-08-12 06:09:45
|
On 12/08/15 03:25, Bart Van Assche wrote: > Ah, right, your purpose is that the Valgrind macros do not emit any > client requests on x32. Unless this is very clearly documented that > might be a confusing outcome for x32 users ... Maybe these users expect > that if they build a program for x32 and analyze it with Valgrind that > these macros just work ? Well how would they analyse such a program with valgrind? The launcher would reject an x32 binary on the grounds that it isn't supported... Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Tom H. <to...@co...> - 2015-08-12 08:56:37
|
On 12/08/15 07:09, Tom Hughes wrote: > On 12/08/15 03:25, Bart Van Assche wrote: > >> Ah, right, your purpose is that the Valgrind macros do not emit any >> client requests on x32. Unless this is very clearly documented that >> might be a confusing outcome for x32 users ... Maybe these users expect >> that if they build a program for x32 and analyze it with Valgrind that >> these macros just work ? > > Well how would they analyse such a program with valgrind? The launcher > would reject an x32 binary on the grounds that it isn't supported... On closer inspection it looks like the laucher won't actually refuse but I don't think it will work either. Basically select_platform will fail, because EI_CLASS will be ELFCLASS32 but e_machine will be EM_X86_64 which is not a combination we recognise. So we will fallback to using amd64-linux as the default platform. But that will of course use a 64 bit address space, so it's unlikely that an x32 binary will get very far. In fact I think once the tool tries to load the ELF readelf() in m_ume/elf.c will just abort because the class will be wrong. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Matthias S. <zz...@ge...> - 2015-08-12 15:19:55
|
Am 12.08.2015 um 10:56 schrieb Tom Hughes: > On 12/08/15 07:09, Tom Hughes wrote: >> On 12/08/15 03:25, Bart Van Assche wrote: >> >>> Ah, right, your purpose is that the Valgrind macros do not emit any >>> client requests on x32. Unless this is very clearly documented that >>> might be a confusing outcome for x32 users ... Maybe these users expect >>> that if they build a program for x32 and analyze it with Valgrind that >>> these macros just work ? >> >> Well how would they analyse such a program with valgrind? The launcher >> would reject an x32 binary on the grounds that it isn't supported... > > On closer inspection it looks like the laucher won't actually refuse but > I don't think it will work either. > > Basically select_platform will fail, because EI_CLASS will be ELFCLASS32 > but e_machine will be EM_X86_64 which is not a combination we recognise. > So we will fallback to using amd64-linux as the default platform. > > But that will of course use a 64 bit address space, so it's unlikely > that an x32 binary will get very far. > > In fact I think once the tool tries to load the ELF readelf() in > m_ume/elf.c will just abort because the class will be wrong. > Hi! you seem to be right: It cannot detect the platform, chooses amd64-linux and that complains about wrong ELF class. This is the output when calling valgrind on an x32 binary: # valgrind -d ./bin/bash --3928:1:debuglog DebugLog system started by Stage 1, level 1 logging requested --3928:1:launcher no tool requested, defaulting to 'memcheck' --3928:1:launcher no platform detected, defaulting platform to 'amd64-linux' --3928:1:launcher launching /usr/local/lib/valgrind/memcheck-amd64-linux --3928:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested --3928:1: main Welcome to Valgrind version 3.11.0.SVN debug logging --3928:1: main Checking current stack is plausible --3928:1: main Checking initial stack was noted --3928:1: main Starting the address space managerselect_platform --3928:1: main Address space manager is running --3928:1: main Starting the dynamic memory manager --3928:1:mallocfr newSuperblock at 0x802001000 (pszB 4194272) owner VALGRIND/core --3928:1:mallocfr deferred_reclaimSuperblock at 0x802001000 (pszB 4194272) (prev 0x0) owner VALGRIND/core --3928:1: main Dynamic memory manager is running --3928:1: main Initialise m_debuginfo --3928:1: main VG_(libdir) = /usr/local/lib/valgrind --3928:1: main Getting launcher's name ... --3928:1: main ... /usr/local/bin/valgrind --3928:1: main Get hardware capabilities ... --3928:1: cache warning: Unknown Intel cache config value (0x63), ignoring --3928:1: cache Autodetected cache info is sensible --3928:1: cache Cache info: [...deleted cache info...] --3928:1: main ... arch = AMD64, hwcaps = amd64-cx16-lzcnt-rdtscp-sse3-avx-avx2-bmi --3928:1: main Getting the working directory at startup --3928:1: main ... /data/x32 --3928:1: main Split up command line --3928:1: main (early_) Process Valgrind's command line options --3928:1: main Create initial image --3928:1: initimg Loading client valgrind: wrong ELF executable class (eg. 32-bit instead of 64-bit) valgrind: ./bin/bash: cannot execute binary file Regards Matthias |
|
From: Bart V. A. <bva...@ac...> - 2015-08-12 14:08:43
|
On 08/10/15 11:52, Matthias Schwarzott wrote: > Hi! > > I have seen that valgrind.h will missdetect x32 as amd64. > > So I wonder if this can cause any bad effects. > > If so, the header needs to be protected so it does not emit client > requests on x32. > It could be done like this, because the x32 ABI says that __ILP32__ must > be defined (and it is not defined on amd64). > See abi.pdf in https://sites.google.com/site/x32abi/documents > > Regards > Matthias > > > --- a/include/valgrind.h > +++ b/include/valgrind.h > @@ -140,7 +140,7 @@ > # define PLAT_amd64_win64 1 > #elif defined(__linux__) && defined(__i386__) > # define PLAT_x86_linux 1 > -#elif defined(__linux__) && defined(__x86_64__) > +#elif defined(__linux__) && defined(__x86_64__) && !defined(__ILP32__) > # define PLAT_amd64_linux 1 > #elif defined(__linux__) && defined(__powerpc__) && !defined(__powerpc64__) > # define PLAT_ppc32_linux 1 Applied as r15526 on the trunk. Thanks for the patch. Bart. |