Re: Difference between --oformat binary, and objcopy -O binary of --oformat elf32-i386

[linuxyne citadel <linuxyne at gmail dot com>]

On Wed, Jul 20, 2016 at 10:40:38AM +0100, Nick Clifton wrote:
> Hi linuxyne,
> 
> > When you talk about deprecating --oformat use, do you also mean
> > deprecating OUTPUT_FORMAT in the linker scripts? The problem is seen
> > with both, as they seem to be aliases with --oformat overriding the
> > other one.
> 
> I do mean both methods. although now that I have thought about it, deprecating
> is too strong a term.  What I am contemplating is whether it would be a good
> idea for --oformat (or OUTPUT_FORMAT) to fail if the requested output file format
> was not the similar to the input file format.  Perhaps with exceptions for targets
> where the translation is known to work.  This is just an idea though, I have not
> tried writing any code to implement it yet.

Understood. If deprecation were indeed chosen, then the linker could be made to 
assume (regardless of the switches provide) that the output format is the same as 
(or a superset of) the input format(s) and that it becomes the responsibility 
of the user to invoke objcopy for any required transformation, however trivial it 
may be.


If N is the set of all supported formats (assuming both input and output),
then the transformation tuple (input, output) = (X, binary), where X = N -
{binary}, is a special transformation because each format in X is a
well-structured and practically extremely useful but still a 'binary' format
nonetheless, and the linker ought to be able to *directly* transform any format
from X into binary *successfully* (this currently fails, as described, for
i386 because of GOT and other problems). 

The transformation into the raw but a properly-executable format becomes the
responsibility of each of the other formats, whereas, currently, it seems that
that responsibility is held by a specially written generic layer which cannot
know about other formats enough to create a valid raw executable. 

I believe objcopy provides the type of transformation of which I spoke above.
If that is true, then the --oformat binary, as it is implemented currently,
can be declared as unsupported and can be deprecated (or made to fail loudly
as was suggested by Alan, in addition to you), with providing objcopy as the 
alternative. In the other direction, the functionality of objcopy can be 
incorporated into the direct linking process, but that would become 
too risky a change.

Thanks,
linuxyne.