Re: RFC: Add 32bit x86-64 support to binutils

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Thu, 30 Dec 2010, H. Peter Anvin wrote:

> On 12/30/2010 02:21 PM, Robert Millan wrote:
> > 2010/12/30 Richard Guenther <richard.guenther@gmail.com>:
> >> Would be nice if LFS would be mandatory on the new ABI, thus
> >> off_t being 64bits.
> > 
> > Please do also consider time_t.
> > 
> 
> Changing the kernel-facing time_t might completely wreck the reuse of
> the i386 kernel ABI; I'm not sure.

Before changing time_t for a new ILP32 ABI, you probably want to work out 
what is required - on both the libc and kernel sides - to change it for 
existing 32-bit ABIs (whether providing a new ABI variant like 
_FILE_OFFSET_BITS does, or changing it unconditionally and using symbol 
versioning for compatibility with old binaries built for 32-bit time_t).  
Having done that you then have whatever new syscalls may be needed to work 
with 64-bit time_t on IA32, and can make the new ILP32 ABI not use the old 
32-bit time_t syscalls if desired.

Of course making LFS (or 64-bit time_t) mandatory doesn't help with those 
interfaces that hardcode types such as "int" or "long" - you'll still have 
code that uses fseek rather than fseeko, for example.  If you follow the 
GNU principles of avoiding arbitrary (or at least inappropriate) limits, 
there are quite a lot of libc interfaces that can be problematic in 
extreme cases (large files, strings over 2GB (e.g. regoff_t - glibc bug 
5945 - which is probably one of the easier cases), etc.).  It would be 
good to fix these things, both on the GNU principles and for general 
robustness (there are probably various security holes related to these 
issues - integer overflow issues are always tricky to avoid in C, but bad 
choice of types in APIs certainly doesn't help), but it's quite tricky 
(lots of core ISO C interfaces are involved) and really needs to be kept 
separate from the introduction of new ABIs at the level of x86_64 ILP32.

-- 
Joseph S. Myers
joseph@codesourcery.com