From: "Maciej W. Rozycki" <macro@imgtec.com>
To: Carlos O'Donell <carlos@redhat.com>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, <gnu-gabi@sourceware.org>,
Nick Clifton <nickc@redhat.com>
Subject: Re: RFC: Program Properties
Date: Fri, 01 Jan 2016 00:00:00 -0000 [thread overview]
Message-ID: <alpine.LFD.2.20.1610160554120.1407@eddie.linux-mips.org> (raw)
In-Reply-To: <969fb6da-f13c-eb14-3e53-94a594384518@redhat.com>
On Thu, 13 Oct 2016, Carlos O'Donell wrote:
> > There are cases where linker and run-time loader need more information
> > about ELF objects beyond what the current gABI provides:
>
> I like the idea. Nick Clifton and I were discussing this at GNU Cauldron 2016.
I wish I was there. :(
> (6) Is there any historical implementations of anything like this?
The MIPS target has been using a mixture of ELF file header's `e_flags'
member flags (EF_MIPS_*) which we have now run out of, GNU attributes
(Tag_GNU_MIPS_ABI_*, Val_GNU_MIPS_ABI_*) interpreted by the static linker
only, and more recently a processor-specific "MIPS ABI Flags" section
(SHT_MIPS_ABIFLAGS) and segment (PT_MIPS_ABIFLAGS). Some of this
information although not necessarily all at once is interpreted by the
static linker, the Linux kernel (e.g. to verify the compatibility of a
binary against hardware and the dynamic loader), and finally the dynamic
loader.
I think it would make sense if the design of program properties let us
wire the existing target-specific data structures if possible, so that
e.g. a MIPS ABI Flags section/segment could be interpreted as a part of
the new data structures.
Also based on the experience with MIPS ABI Flags so far I would suggest
defining generic ABI flag flags so that individual object file's ABI flags
can be handled in a generic way in linking; the flags I'd initially
propose would be:
1. An OR flag: if such annotated the ABI flag produced in output is a
logical OR of the values of the ABI flag in input objects.
2. An AND flag: if such annotated the ABI flag produced in output is a
logical AND of the values of the ABI flag in input objects.
3. An equality flag: if such annotated linking fails if the values of the
ABI flag in input objects are not the same across all of them.
4. A reject flag: if such annotated the ABI flag requires explicit support
(special handling beyond the three variants above) and linking fails if
it is set in any input object and the linker does know this ABI flag.
Such annotation would of course have to be consistent across input files.
Such ABI flag flags would allow ABIs to define new ABI flags processed
automatically in static linking without the need to upgrade the linker
each time a flag is added.
Thoughts?
Maciej
next prev parent reply other threads:[~2016-10-17 13:33 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
2016-01-01 0:00 ` Joseph Myers
2016-01-01 0:00 ` Carlos O'Donell
2016-01-01 0:00 ` Maciej W. Rozycki [this message]
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 ` 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 ` H.J. Lu
2016-01-01 0:00 H.J. Lu
2016-01-01 0:00 ` Suprateeka R Hegde
2016-01-01 0:00 H.J. Lu
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=alpine.LFD.2.20.1610160554120.1407@eddie.linux-mips.org \
--to=macro@imgtec.com \
--cc=carlos@redhat.com \
--cc=gnu-gabi@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=nickc@redhat.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).