Re: [Valgrind-developers] Support for x32 ABI

[Matthias S. <zz...@ge...>]

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