|
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 |