ET_EXEC vs ET_DYN

[H.J. Lu]

gABI has

ET_EXEC 2 Executable file
ET_DYN 3 Shared object file

These predate PIE. We should update their meanings for PIE.

--
H.J.

[Florian Weimer]

* H. J. Lu:

Agreed. We also have repurposed the same types for separate debugging
information.

Thanks,
Florian

[H.J. Lu]

Cary, is the new gABI repo on line now?

--
H.J.

[Suprateeka R Hegde]

PIE is not there on all platforms. I assume changes to the meanings do
not mandate any bindings to PIE.

--
Supra

[H.J. Lu]

On Mon, May 25, 2020 at 5:40 AM Suprateeka R Hegde
<hegdes...@gmail.com> wrote:
>
> PIE is not there on all platforms. I assume changes to the meanings do
> not mandate any bindings to PIE.

I am proposing:

#define ET_EXEC 2 /* Position-dependent executable file */
#define ET_DYN 3 /* Position-independent executable or
shared object file */

> --
> Supra
>
> On 25-May-2020 05:33 pm, H.J. Lu wrote:
> > gABI has
> >
> > ET_EXEC 2 Executable file
> > ET_DYN 3 Shared object file
> >
> > These predate PIE. We should update their meanings for PIE.
> >

--
H.J.

[Suprateeka R Hegde]

On 25-May-2020 06:14 pm, H.J. Lu wrote:
> On Mon, May 25, 2020 at 5:40 AM Suprateeka R Hegde
> <hegdes...@gmail.com> wrote:
>>
>> PIE is not there on all platforms. I assume changes to the meanings do
>> not mandate any bindings to PIE.
>
> I am proposing:
>
> #define ET_EXEC 2 /* Position-dependent executable file */
> #define ET_DYN 3 /* Position-independent executable or
> shared object file */

No conflicts. GO!

--
Supra

[Fangrui Song]

Looks good.

[Cary Coutant]

Actually, the key distinction between ET_EXEC and ET_DYN is whether or
not the binary has an entry point. That is, ET_EXEC files are meant to
be exec'ed, and ET_DYN files are meant to be dlopen'ed. This
distinction predates even the notion of position independence for
shared libraries. AT&T's original model for shared libraries used
absolute linking and you had to link the libraries to non-overlapping
address ranges. I'd be reluctant to change these definitions after so
long.

But it's still true that we need to mark position-independent
executables somehow, and it's clear that most platforms have chosen to
use ET_DYN for that. Ideally, we'd have come up with a better way --
perhaps a flag on the PT_LOAD record.

Maybe it's too late, and ET_DYN is a fait accompli. Ideas?

-cary

> --
> You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/20200525180207.sv2sztc5ls6bwe7x%40google.com.

[Suprateeka R Hegde]

On 26-May-2020 09:06 pm, Cary Coutant wrote:
> Actually, the key distinction between ET_EXEC and ET_DYN is whether or
> not the binary has an entry point. That is, ET_EXEC files are meant to
> be exec'ed, and ET_DYN files are meant to be dlopen'ed.

Just curious, what about DT_NEEDED/start-up shlibs? Or are these
considered specific cases of implicit dlopen(3) at startup?

> This
> distinction predates even the notion of position independence for
> shared libraries. AT&T's original model for shared libraries used
> absolute linking and you had to link the libraries to non-overlapping
> address ranges.

Wow! That sounds Paleolithic! Reminds me of text from John Levine ;-)

> I'd be reluctant to change these definitions after so
> long.

Hmm..

> But it's still true that we need to mark position-independent
> executables somehow, and it's clear that most platforms have chosen to
> use ET_DYN for that. Ideally, we'd have come up with a better way --
> perhaps a flag on the PT_LOAD record.
>
> Maybe it's too late, and ET_DYN is a fait accompli. Ideas?

That expands the scope to flags and attributes. And it can even help
identify ET_REL with and without PIC.

--
Supra

[Fangrui Song]

On 2020-05-26, Cary Coutant wrote:
>Actually, the key distinction between ET_EXEC and ET_DYN is whether or
>not the binary has an entry point. That is, ET_EXEC files are meant to
>be exec'ed, and ET_DYN files are meant to be dlopen'ed. This
>distinction predates even the notion of position independence for
>shared libraries. AT&T's original model for shared libraries used
>absolute linking and you had to link the libraries to non-overlapping
>address ranges. I'd be reluctant to change these definitions after so
>long.

A -static-pie linked program (ET_DYN) runs without a ld.so
Its segments are mapped directly by the kernel.

There are also shared objects which can run standalone, e.g. glibc
libc.so, musl libc.so(also ld.so)

% /lib/x86_64-linux-gnu/libc.so.6
GNU C Library (Debian GLIBC 2.29-9) stable release version 2.29.
...

>But it's still true that we need to mark position-independent
>executables somehow, and it's clear that most platforms have chosen to
>use ET_DYN for that. Ideally, we'd have come up with a better way --
>perhaps a flag on the PT_LOAD record.
>
>Maybe it's too late, and ET_DYN is a fait accompli. Ideas?
>
>-cary

The distinction might be different historically, but it is now whether
p_vaddr/sh_addr fields are absolute or relative to the image base.

>
>On Mon, May 25, 2020 at 11:02 AM 'Fangrui Song' via Generic System V
>Application Binary Interface <gener...@googlegroups.com> wrote:
>>
>> On 2020-05-25, Suprateeka R Hegde wrote:
>> >On 25-May-2020 06:14 pm, H.J. Lu wrote:
>> >> On Mon, May 25, 2020 at 5:40 AM Suprateeka R Hegde
>> >> <hegdes...@gmail.com> wrote:
>> >>>
>> >>> PIE is not there on all platforms. I assume changes to the meanings do
>> >>> not mandate any bindings to PIE.
>> >>
>> >> I am proposing:
>> >>
>> >> #define ET_EXEC 2 /* Position-dependent executable file */
>> >> #define ET_DYN 3 /* Position-independent executable or
>> >> shared object file */
>> >
>> >No conflicts. GO!
>> >
>> >--
>> >Supra
>>
>> Looks good.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/20200525180207.sv2sztc5ls6bwe7x%40google.com.
>
>--
>You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.

>To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/CAJimCsH5Kj-5bPdjhxf81xdRKiDMPfsUmaF3P%2BdBvxRsV1HiDw%40mail.gmail.com.

[Ali Bahrami]

On 5/26/20 9:36 AM, Cary Coutant wrote:
> Actually, the key distinction between ET_EXEC and ET_DYN is whether or
> not the binary has an entry point. That is, ET_EXEC files are meant to
> be exec'ed, and ET_DYN files are meant to be dlopen'ed. This
> distinction predates even the notion of position independence for
> shared libraries. AT&T's original model for shared libraries used
> absolute linking and you had to link the libraries to non-overlapping
> address ranges. I'd be reluctant to change these definitions after so
> long.
>
> But it's still true that we need to mark position-independent
> executables somehow, and it's clear that most platforms have chosen to
> use ET_DYN for that. Ideally, we'd have come up with a better way --
> perhaps a flag on the PT_LOAD record.
>
> Maybe it's too late, and ET_DYN is a fait accompli. Ideas?
>
> -cary

I think ET_DYN is fine as is. The problem is that we're
reading too much into what ET_EXEC and ET_DYN mean in this
discussion. The significant distinction between ET_EXEC and ET_DYN
is that of position independence. EXEC have their addresses fixed at
link-time, while DYN addresses are established by the runtime linker
at runtime. The names (EXEC, DYN) reflect their most common use, but
are a bit misleading --- they're more low level and general than the
names suggest. I'm definitely against trying to rename them though.
Some things are too old and fundamental to mess with.

An entry point (and for non-static executables the interpreter),
are what distinguish an object that can be the main object in a
process (the a.out "executable") from one that can't. The entry point
isn't the the distinction between ET_EXEC and ET_DYN though. Either
can have an entry, or not. For instance, consider this Solaris PIE,
which is ET_DYN, which by necessity also has an entry:

% file /usr/bin/ls
/usr/bin/ls: ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE2 SSE], position-independent executable, dynamically linked, not stripped, no debugging information available
% elfdump -e /usr/bin/ls

ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS64 ei_data: ELFDATA2LSB
ei_osabi: ELFOSABI_SOLARIS ei_abiversion: EAV_SUNW_CURRENT
e_machine: EM_AMD64 e_version: EV_CURRENT
e_type: ET_DYN
e_flags: 0
e_entry: 0x48d0 e_ehsize: 64 e_shstrndx: 32
e_shoff: 0xf878 e_shentsize: 64 e_shnum: 34
e_phoff: 0x40 e_phentsize: 56 e_phnum: 7

(It's the same on Linux --- I just happen to have Solaris at hand)

There is precedence for ET_EXEC that are not used as "executables".
I know that we've used that for "dumped" shared objects in Solaris
(a feature we have since removed). I think that GNU prelink uses the
same idea for its prelinked shared objects. Those ET_EXEC have no
interpreter, or entry point, and so, are not "executables" in the a.out
sense.

Hence, it's not really necessary to mark PIE specifically.
Any ET_DYN with an entry and an interpreter is PIE.

That said, on Solaris, we do tag our PIE explicitly, by setting
the DF_1_PIE dynamic flag to positively identify a PIE built by
our ld, as distinguished from an ad hoc PIE. The difference between
the 2 cases is the presence of those invisible finishing touches that
go into building an object intended to be the a.out (finalizing more
relocations, etc). This marker is informational, but not essential,
and exec() doesn't look at it in making its decision to load it as
an a.out or not. I think it's probably OK to leave tagging PIE as
a non-essential OSABI matter.

Perhaps this would be a more accurate comment?

#define ET_EXEC 2 /* Position-dependent object */
#define ET_DYN 3 /* Position-independent object */

- Ali

[Cary Coutant]

> > Actually, the key distinction between ET_EXEC and ET_DYN is whether or
> > not the binary has an entry point. That is, ET_EXEC files are meant to
> > be exec'ed, and ET_DYN files are meant to be dlopen'ed.
>
> Just curious, what about DT_NEEDED/start-up shlibs? Or are these
> considered specific cases of implicit dlopen(3) at startup?

Yes, I was using dlopen as just a generic reference to the dynamic
loader, as distinguished from kernel exec.

-cary

[Michael Matz]

Hello,

On Tue, 26 May 2020, Cary Coutant wrote:

> Actually, the key distinction between ET_EXEC and ET_DYN is whether or
> not the binary has an entry point. That is, ET_EXEC files are meant to
> be exec'ed, and ET_DYN files are meant to be dlopen'ed. This distinction
> predates even the notion of position independence for shared libraries.
> AT&T's original model for shared libraries used absolute linking and you
> had to link the libraries to non-overlapping address ranges. I'd be
> reluctant to change these definitions after so long.
>
> But it's still true that we need to mark position-independent
> executables somehow, and it's clear that most platforms have chosen to
> use ET_DYN for that. Ideally, we'd have come up with a better way --
> perhaps a flag on the PT_LOAD record.
>
> Maybe it's too late, and ET_DYN is a fait accompli. Ideas?

Depends on what you suggest: we can't remove the possibility of the kernel
loading ET_DYN files as main object, as those exist since a number of
years already. In the end I think the original distinction of ET_EXEC vs
ET_DYN (having a valid entrypoint) is moot: that distinction can be made
by, well, having a valid e_entry or not (note that zero isn't valid
anywhere, as it would point to the ELF header even in normal base-0
files). So the other important distinction (is the loader allowed to load
the file with a bias) is the only remaining. We could use a flag, of
course. But given that ET_EXEC/ET_DYN works as well, we should continue
using that.

Another (fun) observation: even a main object doesn't necessarily have to
have an entry point: all the functionality could be done from static
initializers :-) So even from that perspective having or not having an
entry point isn't really important. Only if a bias is allowed for loading
matters, I think. So I'm with Ali here.


Ciao,
Michael.

[H.J. Lu]

On Tue, May 26, 2020 at 10:20 AM Ali Bahrami <Ali.B...@oracle.com> wrote:
>
> Perhaps this would be a more accurate comment?
>
> #define ET_EXEC 2 /* Position-dependent object */
> #define ET_DYN 3 /* Position-independent object */
>

This leaves a question whether a relocatable file is a
position-dependent object or
position-independent object since a relocatable file can be loaded
into memory and
execute. Then we need to clarify what they are.

--
H.J.

[Ali Bahrami]

A relocatable object is neither position dependent,
nor independent, because it's not mappable. Unlike
the others, it's not a final object (has no program headers).
Relocatable objects are just that:

#define ET_REL 1 /* Relocatable object */

They can be fed to the link-editor as input to build other
objects, or they can be processed into something that can
be loaded into memory (e.g. kernel modules), but they can't
be directly loaded without additional processing.

- Ali

[H.J. Lu]

On Thu, May 28, 2020 at 6:44 AM Ali Bahrami <Ali.B...@oracle.com> wrote:
>
> On 5/28/20 5:52 AM, H.J. Lu wrote:
> > On Tue, May 26, 2020 at 10:20 AM Ali Bahrami <Ali.B...@oracle.com> wrote:
> >>
> >> Perhaps this would be a more accurate comment?
> >>
> >> #define ET_EXEC 2 /* Position-dependent object */
> >> #define ET_DYN 3 /* Position-independent object */
> >>
> >
> > This leaves a question whether a relocatable file is a
> > position-dependent object or
> > position-independent object since a relocatable file can be loaded
> > into memory and
> > execute. Then we need to clarify what they are.
> >
>
>
> A relocatable object is neither position dependent,
> nor independent, because it's not mappable. Unlike

That is the clarification I was referring to. ET_EXEC and
ET_DYN are also used on files which store separate debugging
information. I don't know how we should call such files.

> the others, it's not a final object (has no program headers).
> Relocatable objects are just that:
>
> #define ET_REL 1 /* Relocatable object */
>
> They can be fed to the link-editor as input to build other
> objects, or they can be processed into something that can
> be loaded into memory (e.g. kernel modules), but they can't
> be directly loaded without additional processing.

--
H.J.

[Ali Bahrami]

On 5/28/20 7:50 AM, H.J. Lu wrote:
>> A relocatable object is neither position dependent,
>> nor independent, because it's not mappable. Unlike
> That is the clarification I was referring to. ET_EXEC and
> ET_DYN are also used on files which store separate debugging
> information. I don't know how we should call such files.
>

Ultimately, header file comments are not going to
be a satisfying way to document all of that. There are
too many possibilities.

Let me show you the comments in the Solaris <sys/elf.h>:

#define ET_NONE 0 /* e_type */
#define ET_REL 1
#define ET_EXEC 2
#define ET_DYN 3
#define ET_CORE 4
#define ET_NUM 5
#define ET_LOOS 0xfe00 /* OS specific range */
#define ET_LOSUNW 0xfefe
#define ET_SUNW_ANCILLARY 0xfefe
#define ET_SUNW_PSEUDO 0xfeff
#define ET_SUNWPSEUDO ET_SUNW_PSEUDO /* Alias: Older published name */
#define ET_HISUNW 0xfeff
#define ET_HIOS 0xfeff
#define ET_LOPROC 0xff00 /* processor specific range */
#define ET_HIPROC 0xffff

Right, we totally punt, and leave it to other documentation,
particularly our Linker and Libraries Manual. :-)

Note also that we created an OSABI specific type for our
separate debug files (ET_SUNW_ANCILLARY) rather than
overloading the other types for that. That solved multiple
problems, including this one. In terms of the gABI, I'm not
sure how I'd categorize ET_EXEC and ET_DYN used only for
separate debug. They're not a gABI thing.

In terms of the GNU header of course, the gABI is beside
the point. I'm not sure how to add a short comment
to those things that captures all the options, so I
think leaving it to other documentation might be the
easiest path.

- Ali

[Fangrui Song]

On 2020-05-28, H.J. Lu wrote:
>On Thu, May 28, 2020 at 6:44 AM Ali Bahrami <Ali.B...@oracle.com> wrote:
>>
>> On 5/28/20 5:52 AM, H.J. Lu wrote:
>> > On Tue, May 26, 2020 at 10:20 AM Ali Bahrami <Ali.B...@oracle.com> wrote:
>> >>
>> >> Perhaps this would be a more accurate comment?
>> >>
>> >> #define ET_EXEC 2 /* Position-dependent object */
>> >> #define ET_DYN 3 /* Position-independent object */
>> >>

Is this proposal coining two new terms? :)

The term "position-dependent object" may not occur before. People always
call them "position-dependent executable". The same goes for
"position-independent object".

>> > This leaves a question whether a relocatable file is a
>> > position-dependent object or
>> > position-independent object since a relocatable file can be loaded
>> > into memory and
>> > execute. Then we need to clarify what they are.
>> >
>>
>>
>> A relocatable object is neither position dependent,
>> nor independent, because it's not mappable. Unlike
>
>That is the clarification I was referring to. ET_EXEC and
>ET_DYN are also used on files which store separate debugging
>information. I don't know how we should call such files.
>
>> the others, it's not a final object (has no program headers).
>> Relocatable objects are just that:
>>
>> #define ET_REL 1 /* Relocatable object */
>>
>> They can be fed to the link-editor as input to build other
>> objects, or they can be processed into something that can
>> be loaded into memory (e.g. kernel modules), but they can't
>> be directly loaded without additional processing.
>
>
>--
>H.J.
>

>--
>You received this message because you are subscribed to the Google Groups "Generic System V Application Binary Interface" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to generic-abi...@googlegroups.com.

>To view this discussion on the web visit https://groups.google.com/d/msgid/generic-abi/CAMe9rOqG8S0kBoLOWY1cFvnJGwDg6Tz%2BnsXawguaZLT%2BrKVocg%40mail.gmail.com.

[Carlos O'Donell]

On 5/26/20 1:18 PM, Ali Bahrami wrote:
> Perhaps this would be a more accurate comment?
>
>     #define ET_EXEC        2       /* Position-dependent object */
>     #define ET_DYN         3       /* Position-independent object */

I agree.

There is confusion among userspace processing tools about what this
markup means and Florian worked on eu-elfclassify to help such tooling
make sense of what it is examining. Mark Wielaard and I did the review
of the logic there, so at least 3 of us have reviewed what it means to
be "an executable", but I urge others to review eu-elfclassify.

In eu-elfclassify the 'is executable' is predicated on:
- Is it loadable?
AND is it *not* a shared library?

And "Is it loadable" is predicated on:
- Is it ET_EXEC *or* ET_DYN
AND has a PT_LOAD segment
AND has some allocated sections (SHF_ALLOC)

The latter helps exclude "debug information" objects.

The above logic seems to line up with what you are saying.

You might ask "What does it mean to be a shared library?" Well one of
the key distinctions is that it must *not* have DF_1_PIE, which is as
you say, exactly what Solaris is doing. It must have ET_DYN.

Historically Roland McGrath had intended PIE to be ET_DYN + DT_DEBUG,
but this never reached criticality as a key feature of PIE, and DT_DEBUG
was never specific to executables:
https://www.sourceware.org/ml/libc-alpha/2015-03/msg00605.html

For reference this is all cleanly spelled out in: elfutils/src/elfclassify.c

--
Cheers,
Carlos.

[Ali Bahrami]

On 5/29/20 5:47 AM, Carlos O'Donell wrote:
> You might ask "What does it mean to be a shared library?" Well one of

> the key distinctions is that it must*not* have DF_1_PIE, which is as

> you say, exactly what Solaris is doing. It must have ET_DYN.

That's largely the case, but it's fun to poke at
both assumptions. I guess you could say that part of the
definition is a form of duck typing. "If it looks as a
library, and works as a library, it's a library." :-)

First off, if you recall the Linux prelink example, those
are ET_EXEC libraries that are produced by loading the
original ET_DYN, relocating it, and then writing it out
as an ET_EXEC. Hence, a "position dependent library".
Of course, these are not used by the link-editor, so
it's a runtime-only library.

The DF_1_PIE aspect is also an interesting point, because
with care, one can construct an ET_DYN that could serve as
both a shared library, and an executable. This is more of a
party trick (for certain sorts of parties :-) ), because it's
a bit too cute/clever/obscure to be a good idea. However, I
do know that our runtime linker won't reject a library that
has DF_1_PIE set, as long as it has the other attributes
needed by a library.

Irrelevant Historical Side Note: The first OS I ever used
with dynamic linking was VAX/VMS, which had that stuff about
a decade earlier than Unix. On VMS, this dual executable/library
use was a supported feature, though rarely used. These don't
have to be either/or concepts, though it's cleaner not to
mix them.

This flexibility is why ELF survives when other formats have
died out. However, it's also why we tag our objects with
DF_1_PIE and DF_1_KMOD. It's helpful to be able to label
what your intent was when you make these, because it's not
necessarily clear what they are just by looking at the ELF header.

The need to understand what the caller is trying to build
(a library, an executable, a kernel module) rather than
what they think it should be made from (ET_EXEC, ET_DYN)
led us to introducedthe '-z type' option to our ld,
superseding the use of the lower level ELF specific
options for object type (-a, -G/--shared, -r). This lets
us do the right type specific operations for each type
(relocations, etc), but also drives the DF_1_xxx tagging
for the cases not directly conveyed by the ELF type.
That addresses both the intent (used by ld), and ELF
details (used by the runtime linker).

https://docs.oracle.com/cd/E88353_01/html/E37839/ld-1.html

- Ali

[Carlos O'Donell]

On 5/29/20 12:45 PM, Ali Bahrami wrote:
> On 5/29/20 5:47 AM, Carlos O'Donell wrote:
>> You might ask "What does it mean to be a shared library?" Well one of
>> the key distinctions is that it must*not*  have DF_1_PIE, which is as
>> you say, exactly what Solaris is doing. It must have ET_DYN.
>
>    That's largely the case, but it's fun to poke at
> both assumptions. I guess you could say that part of the
> definition is a form of duck typing. "If it looks as a
> library, and works as a library, it's a library." :-)
>
> First off, if you recall the Linux prelink example, those
> are ET_EXEC libraries that are produced by loading the
> original ET_DYN, relocating it, and then writing it out
> as an ET_EXEC. Hence, a "position dependent library".
> Of course, these are not used by the link-editor, so
> it's a runtime-only library.

Right.

> The DF_1_PIE aspect is also an interesting point, because
> with care, one can construct an ET_DYN that could serve as
> both a shared library, and an executable. This is more of a
> party trick (for certain sorts of parties :-) ), because it's
> a bit too cute/clever/obscure to be a good idea.  However, I
> do know that our runtime linker won't reject a library that
> has DF_1_PIE set, as long as it has the other attributes
> needed by a library.

We use the cute party trick in libc.so.6, setting PT_INTERP,
and the elf entry point. You can run /lib64/libc.so.6. It is
not PIE and this is important.

However, we disallow loading DF_1_PIE in glibc because such
objects are exectuables and as such have very specific rules
about how to load them and you can't easily, load two different
executables into the same in memory process image without having
semantic difficulties.

How do you handle COPY relocations from multiple loaded DF_1_PIE
objects?

> Irrelevant Historical Side Note: The first OS I ever used
> with dynamic linking was VAX/VMS, which had that stuff about
> a decade earlier than Unix. On VMS, this dual executable/library
> use was a supported feature, though rarely used. These don't
> have to be either/or concepts, though it's cleaner not to
> mix them.

I agree it is cleaner not to mix them. In the case of libc.so.6
it is a historical artifact, but you could equally just ship a
'glibc-info' binary that provides all the relevant information.

> This flexibility is why ELF survives when other formats have
> died out. However, it's also why we tag our objects with
> DF_1_PIE and DF_1_KMOD. It's helpful to be able to label
> what your intent was when you make these, because it's not
> necessarily clear what they are just by looking at the ELF header.

Yes. I'd like to see some more robust markup for deubginfo objects,
which we currently derive from:

- it is ET_REL, ET_DYN or ET_EXEC
AND it has debug sections or a symbol table
AND it has no allocatable sections

> The need to understand what the caller is trying to build
> (a library, an executable, a kernel module) rather than
> what they think it should be made from (ET_EXEC, ET_DYN)
> led us to introducedthe '-z type' option to our ld,
> superseding the use of the lower level ELF specific
> options for object type (-a, -G/--shared, -r). This lets
> us do the right type specific operations for each type
> (relocations, etc), but also drives the DF_1_xxx tagging
> for the cases not directly conveyed by the ELF type.
> That addresses both the intent (used by ld), and ELF
> details (used by the runtime linker).
>
>     https://docs.oracle.com/cd/E88353_01/html/E37839/ld-1.html

Yes, -z type is cleaner, rather than all this process of
inference we're getting into today in the GNU Toolchain.

--
Cheers,
Carlos.

[Ali Bahrami]

On 5/29/20 12:37 PM, Carlos O'Donell wrote:
> We use the cute party trick in libc.so.6, setting PT_INTERP,
> and the elf entry point. You can run /lib64/libc.so.6. It is
> not PIE and this is important.

Now that I think of it, the Solaris runtime linker
also plays this trick, and also without the PIE flag.
It's a debugging feature that lets you inject the ld.so.1
you're working on into just one process, before you take
the step of putting it on the system and seeing if it bricks:

% ./ld.so.1 /usr/bin/ls

This is getting increasingly obscure... :-)

>
> However, we disallow loading DF_1_PIE in glibc because such
> objects are exectuables and as such have very specific rules
> about how to load them and you can't easily, load two different
> executables into the same in memory process image without having
> semantic difficulties.
>
> How do you handle COPY relocations from multiple loaded DF_1_PIE
> objects?

If the code was non-PIC, that would probably be a train wreck.
I'd expect the runtime linker to perform the relocation, copying
data from some source, and then, the multiple objects would all
be accessing their own separate copies. No good can come of that
scenario.

For PIC code, which I would expect to be used for an ET_DYN object,
you won't get COPY relocations, so that particular problem is
ducked. There might be others.

- Ali