|
From: Matthias S. <zz...@ge...> - 2015-02-02 06:51:24
|
Hi! Just out of interest: Is the new x32 ABI for amd64 already supported in valgrind? From looking at the source-code I would guess not. What would be necessary to support this? Ideas: * Support the missing syscalls. * Support for more "secondary" archs (Makefile cleanup) * A valgrind-loader for x32 * Making 32bit vs. 64bit memory management depend on ABI and not on cpu architecture. Regards Matthias |
|
From: Philippe W. <phi...@sk...> - 2015-02-02 21:41:13
|
On Mon, 2015-02-02 at 07:51 +0100, Matthias Schwarzott wrote: > Hi! > > Just out of interest: Is the new x32 ABI for amd64 already supported in > valgrind? From looking at the source-code I would guess not. No, it is not supported. > > What would be necessary to support this? Good question, not clear to me. > > Ideas: > * Support the missing syscalls. Is there a lot of x32 specific syscalls ? Or is it needed to rewrite all/a lot of the wrappers ? What about VEX lib, which I guess might be impacted a lot ? > * Support for more "secondary" archs (Makefile cleanup) Wondering if we shouldn't drop the idea of having primary and secondary platforms, and just have a kind of 'top' configure/make that would be called once per arch. That might be simpler than having a primary, secondary and tertiary approach. At least, at my work, for strange reasons, we have to use 2 different compilers for 32 bits and 64 bits. The easiest was just to have a configure/make with one compiler, and then with the other compiler in another directory, and have make install called twice (thereby adding files, or replacing files). The only thing to pay attention to is that some programs (e.g. valgrind, vgdb, ...) have to be 'multi-arch', i.e. support whatever is necessary, and that the 'richer' arch is to be installed latest. (richer = e.g. the vgdb 64 bit version, that can work with both 32 bits and 64 bits 'clients'). At least initially, adding a new primary arch x32 might be already a gigantic first step, the concept of tertiary platform can for sure be done later :). > * A valgrind-loader for x32 You mean the 'normal' executable that launches the tool. This one is pretty independent of the arch, to my knowledge. > * Making 32bit vs. 64bit memory management depend on ABI and not on cpu > architecture. Not clear what you mean here. For sure, assuming x32 starts to be used significantly, adding x32 support will be a nice thing to have. (note however that I saw no request/demand up to now). Philippe |
|
From: Matthias S. <zz...@ge...> - 2015-02-11 19:49:47
|
On 02.02.2015 22:42, Philippe Waroquiers wrote: > On Mon, 2015-02-02 at 07:51 +0100, Matthias Schwarzott wrote: >> Hi! >> >> Just out of interest: Is the new x32 ABI for amd64 already supported in >> valgrind? From looking at the source-code I would guess not. > No, it is not supported. > >> >> What would be necessary to support this? > Good question, not clear to me. > An x32 executable runs in the same processor mode as normal amd64 applications. It also uses the exact same syscalls, just with a high bit set: #define __X32_SYSCALL_BIT 0x40000000 The kernel masks this high bit and calls exactly the same code as for amd64 executables. >> >> Ideas: >> * Support the missing syscalls. > Is there a lot of x32 specific syscalls ? Only the syscalls that differ in some aspect to amd64 have a new number assigned (starting from 512, for my kernel sources this are 33 syscalls). See /usr/src/linux/arch/x86/syscalls/syscall_64.tbl > Or is it needed to rewrite all/a lot of the wrappers ? > What about VEX lib, which I guess might be impacted a lot ? I don't have a running system for x32 but I guess that for VEX not much is to be done if all the used 32bit instructions in 64-bit mode are supported. > >> * Support for more "secondary" archs (Makefile cleanup) > Wondering if we shouldn't drop the idea of having primary > and secondary platforms, and just have a kind of 'top' > configure/make that would be called once per arch. > That might be simpler than having a primary, secondary and > tertiary approach. > At least, at my work, for strange reasons, we have to use > 2 different compilers for 32 bits and 64 bits. > The easiest was just to have a configure/make with one compiler, > and then with the other compiler in another directory, and have > make install called twice (thereby adding files, or replacing files). Sounds like a simpler approach, just the compilation has to be triggered 2 times. For this an out-of-source build is needed even more (does it work currently?) > The only thing to pay attention to is that some programs (e.g. valgrind, > vgdb, ...) have to be 'multi-arch', i.e. support whatever is necessary, > and that the 'richer' arch is to be installed latest. > (richer = e.g. the vgdb 64 bit version, that can work with both 32 bits > and 64 bits 'clients'). If the helper apps don't need to much memory, it might not even be relevant for which platform they are built. At least for valgrind, I don't see anything that is bound to the primary platform. For vgdb I don't know. > > At least initially, adding a new primary arch x32 might be already > a gigantic first step, the concept of tertiary platform can for sure > be done later :). > :) > >> * A valgrind-loader for x32 > You mean the 'normal' executable that launches the tool. This one > is pretty independent of the arch, to my knowledge. An x32 executable is basically an elf32 file for target architecture EM_X86_64. So it is simple in launcher-linux.c to detect this. > >> * Making 32bit vs. 64bit memory management depend on ABI and not on cpu >> architecture. > Not clear what you mean here. > How does valgrind decide how much memory it can use? By sizeof(void*)? This would also work for x32. Idea: As the kernel allows normal syscalls, it might be possible for x32 valgrind to even use full 64-bits addrspace and just restrict client addresses to 32bits. This might allow even applications that use almost all of their 32bit addrspace on their own to run under valgrind. > For sure, assuming x32 starts to be used significantly, adding x32 > support will be a nice thing to have. > (note however that I saw no request/demand up to now). > I also see no demand until now. But this might appear as soon as some distributions use x32 for majority of programs. Regards Matthias |