Check the upper bits of e_flags

[palmer-dabbelt]

No description provided.

[palmer-dabbelt]

#58

[aswaterman]

One thing though, it's possible that some flags will get introduced later that don't imply ABI incompatibility. I think the main place this will show up is linking against a newer libX.a / libX.so using an older linker. (The dynamic linker doesn't check e_flags at the moment, but it probably should, so this would also be a problem with using newer executables with an older dynamic linker.)

By going forward with this, we're basically saying that each e_flags setting represents its own, incompatible ABI. One thing we could consider doing is reserving the lower half-word for ABI, and the upper half-word for other stuff that doesn't imply incompatibility.

Probably best to research what other BFD ports do.

[palmer-dabbelt]

One thing I was thinking of doing was having a "equal flags are compatible" check, which is in ARMv8

  /* Identical flags must be compatible.  */
  if (in_flags == out_flags)
    return TRUE;

but just for the unknown bits, so the patch would look more like

+  if ((new_flags & EF_RISCV_RESERVED) != (old_flags & EF_RISCV_RESERVED))
 +    {
 +      (*_bfd_error_handler)
 +        (_("%B: Unknown ELF flag `%x'"),
 +	 ibfd, new_flags);
 +      return FALSE;
 +    }

but I decided not to. My reasoning had something to do with a version field, but that doesn't make any sense (so I was either too hungry or am now too full).

I don't see any EF_ in aarch64, and this http://infocenter.arm.com/help/topic/com.arm.doc.ihi0056c/IHI0056C_beta_aaelf64.pdf says "There are no processor-specific flags so [e_flags] shall contain zero." so this might not be relevant.

It looks like MIPS ran into a similar issue. I see

  /* Some IRIX 6 BSD-compatibility objects have this bit set.  It
     doesn't seem to matter.  */
  new_flags &= ~EF_MIPS_XGOT;
  old_flags &= ~EF_MIPS_XGOT;

the rest of the MIPS e_flags stuff is a mess, but I don't see them checking reserved bits anywhere.

Tilera doesn't appear to define any EF_ flags, they just check the target names explicitly. IIRC they never had any ISA subsets.

SPARC has some EF_ stuff, but it doesn't check them when merging.

The only reference to e_flags I can find anywhere in glibc is in ARM

      if (!ret && EF_ARM_EABI_VERSION (elf32_header->e_flags) == EF_ARM_EABI_VER5)
        {
          if (elf32_header->e_flags & EF_ARM_ABI_FLOAT_HARD)
            *flag = FLAG_ARM_LIBHF|FLAG_ELF_LIBC6;
          else if (elf32_header->e_flags & EF_ARM_ABI_FLOAT_SOFT)
            *flag = FLAG_ARM_LIBSF|FLAG_ELF_LIBC6;
          else
            /* We must assume the unmarked objects are compatible
               with all ABI variants. Such objects may have been
               generated in a transitional period when the ABI
               tags were not added to all objects.  */
            *flag = FLAG_ELF_LIBC6;
        }

which makes me think that maybe it's just not worth checking the reserved bits at all.

[aswaterman]

Yeah, I think not checking them at all is the better thing to do.

The psABI spec is the line of defense here. If people allocate reserved flags for their own purposes, then they are knowingly making an incompatibility. If future versions of binutils start to reject their libraries, it's their fault.

[palmer-dabbelt]

Works for me. I'm closing this and the PR.