From: Suprateeka R Hegde <hegdesmailbox@gmail.com>
To: "Jose E. Marchesi" <jose.marchesi@oracle.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, gnu-gabi@sourceware.org
Subject: Re: RFC: Program Properties
Date: Fri, 01 Jan 2016 00:00:00 -0000 [thread overview]
Message-ID: <836079bc-1309-146c-889e-7ceec926d1ad@gmail.com> (raw)
In-Reply-To: <87lgxsnmtl.fsf@oracle.com>
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
next prev parent reply other threads:[~2016-10-14 13:35 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-01 0:00 H.J. Lu
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 ` Jose E. Marchesi
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 ` Jose E. Marchesi
2016-01-01 0:00 ` Suprateeka R Hegde [this message]
2016-01-01 0:00 ` Joseph Myers
2016-01-01 0:00 ` Carlos O'Donell
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Maciej W. Rozycki
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Nick Clifton
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 ` Maciej W. Rozycki
2016-01-01 0:00 ` H.J. Lu
2016-01-01 0:00 ` H.J. Lu
-- strict thread matches above, loose matches on Subject: below --
2016-01-01 0:00 H.J. Lu
2016-01-01 0:00 H.J. Lu
2016-01-01 0:00 ` Suprateeka R Hegde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=836079bc-1309-146c-889e-7ceec926d1ad@gmail.com \
--to=hegdesmailbox@gmail.com \
--cc=gnu-gabi@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=jose.marchesi@oracle.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).