On Thu, Dec 30, 2010 at 4:25 PM, H.J. Lu <hjl.to...@gmail.com> wrote:
> On Thu, Dec 30, 2010 at 3:00 PM, Joseph S. Myers
> <jos...@codesourcery.com> wrote:
>> 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.guent...@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.
>>
>
> I am checking in ILP32 binutils so that people can play with it.
>
I checked in this patch to avoid using ELF32 relocations on ELF64
inputs and vice verse.
--
H.J.
---
2010-12-30 H.J. Lu <hongjiu...@intel.com>
* elf64-x86-64.c (elf_x86_64_relocs_compatible): New.
(elf_backend_relocs_compatible): Defined to
elf_x86_64_relocs_compatible.
diff --git a/bfd/elf64-x86-64.c b/bfd/elf64-x86-64.c
index a50dccc..3dd16ba 100644
--- a/bfd/elf64-x86-64.c
+++ b/bfd/elf64-x86-64.c
@@ -4496,6 +4496,17 @@ elf_x86_64_hash_symbol (struct elf_link_hash_entry *h)
return _bfd_elf_hash_symbol (h);
}
+/* Return TRUE iff relocations for INPUT are compatible with OUTPUT. */
+
+static bfd_boolean
+elf_x86_64_relocs_compatible (const bfd_target *input,
+ const bfd_target *output)
+{
+ return ((xvec_get_elf_backend_data (input)->s->elfclass
+ == xvec_get_elf_backend_data (output)->s->elfclass)
+ && _bfd_elf_relocs_compatible (input, output));
+}
+
static const struct bfd_elf_special_section
elf_x86_64_special_sections[]=
{
@@ -4536,7 +4547,7 @@ static const struct bfd_elf_special_section
elf_x86_64_reloc_name_lookup
#define elf_backend_adjust_dynamic_symbol elf_x86_64_adjust_dynamic_symbol
-#define elf_backend_relocs_compatible _bfd_elf_relocs_compatible
+#define elf_backend_relocs_compatible elf_x86_64_relocs_compatible
#define elf_backend_check_relocs elf_x86_64_check_relocs
#define elf_backend_copy_indirect_symbol elf_x86_64_copy_indirect_symbol
#define elf_backend_create_dynamic_sections elf_x86_64_create_dynamic_sections
