[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Program Properties

On 13-Oct-2016 11:38 PM, Jose E. Marchesi wrote:



    >     > 1. Minimum ISAs.  Executables and shared objects, which are optimized
    >     > specifically to run on a particular processor, will not run on processors
    >     > which don't support the same set of ISAs.  Since x86 only has EM_IAMCU,
    >     > EM_386 and EM_X86_64 ELF machine codes, run-time loader needs additional
    >     > information to tell if an executable or a shared object is compatible
    >     > with available ISAs.
    >
    >     Why cant the following be defined as processor specific e_flags (like
    >     other processors do) in elf.h itself?
    >
    > It is easy to exhaust the space of EF_* flags.  In sparc this happened
    > many years ago, so we had to start using the tags Tag_GNU_SPARC_HWCAPS
    > and Tag_GNU_SPARC_HWCAPS2 to denote hardware capabilities.

    Hmm. Looks reasonable. But I still have some points to ponder:

    e_flags is processor specific and I thought each processor has its own
    space. And e_flags is also 4 byte size (purpose is unsigned integer).

    The proposed numbering scheme is already at 17 and 14 more left-shifts
    left. It would be same as e_flags capacity.

In SPARC we have more than 32 hardware capabilities, that can be
combined in any way, so 4 bytes are not enough.
Ah! Thats the key here. Combination is possible. So you need unique bit positions. 

And the case is true here too. The following is valid as per the proposal:
GNU_PROPERTY_X86_ISA_1_USED = GNU_PROPERTY_X86_ISA_1_486 | GNU_PROPERTY_X86_ISA_1_686 

Then we may soon need more bits.

On 14-Oct-2016 07:54 AM, Carlos O'Donell wrote:

To kick off that discussion I have questions that range from the compiler
to the dynamic loader:
We may want to propagate this to package managers to enforce minimum ISA. If the machine does not support minimum ISA, then do not install or issue warning.
And then propagate this to archive libraries too. For instance, allow an archive library to contain two foo.o files one built with minimum ISA-1 and another built with minimum ISA-2. And depending on the main program's minimum ISA, let the linker pick the right one.
And there are two parts in case of hardware capabilities. One that is recorded in the ELF. And the other, the actual one (machine) where this ELF runs. Is the loader going to check actual hardware using cpuid? Or do we want to propagate this proposal to the kernel also and keep the actual hardware capabilities in the ELF image of the kernel (may not work with a UEFI based kernel) ?
Its better we discuss as many use cases as possible (as you said) and make relevant changes in the design right now. 


(6) Is there any historical implementations of anything like this?
On HP-UX (both on PA-RISC and Intel Itanium) we have similar things. We also have a tool called "chatr" (stands for CHange program ATtRibutes) that can be used to change program attributes post build. 

--
Supra