Re: [PATCH] ld: Correct private data merging for DSOs

[Richard Sandiford <rdsandiford at googlemail dot com>]

First of all, if the handling of DSOs depends on whether or not the DSO
gets chosen as the "dynobj", then I agree that's a bug.  As you say,
it's unlikely that many people hit it in practice, since "proper" links
will have the crt files earlier.  But it's still a bug.

I think the behaviour that people usually see is the correct one though.
The DSO attributes and flags shouldn't carry over to the executable.
If we think the dynamic loader should skip a DSO as being incompatible,
then we should treat it as incompatible too (and skip it when searching
for a DSO rather than loading from an explicit pathname).  There is
already code to do that.  If a DSO passes that test, then its attributes
and flags should be ignored when merging.

To take one flags example, it doesn't IMO make sense to mark an
otherwise MIPS64 executable as Octeon simply because one of the
DSOs used at static link time was an Octeon one.  The executable
flags should describe the code in the executable and users should
be free to substitute a compatible "pure" MIPS64 DSO at runtime if
necessary.  The loader is responsible for checking that each DSO
chosen at runtime is compatible with the system and executable.

Attributes as defined by ARM are explicitly for relocatable objects,
with program headers being used to record DSO compatibility.
I think we're not supposed to merge any attributes that a DSO
happens to have into an executable.  Hopefully Richard E can confirm.

Which I suppose means I disagree with this part:

"Maciej W. Rozycki" <macro@codesourcery.com> writes:
> 4. Dynamic shared object, non-empty input sections present.  Such objects 
>    are supposed to be checked for compatibility with other objects 
>    involved in the link (there's explicit code in 
>    _bfd_mips_elf_merge_private_bfd_data to handle DSOs and besides I 
>    think we should treat them consistently with relocatable objects).  

Richard