This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [binutils-gdb] Fix the linker so that it will not silently generate ELF binaries with invalid program headers. Fix
On Fri, 9 Dec 2016, Alan Modra wrote:
> > Well, TBH I think it's all but clear, given that nowhere in the ELF gABI
> > that I can find there is an actual definition of what "the memory image"
> > is.
>
> I'm not going to argue this point except to note that all specs I've
> ever read rely on some background knowledge and require
> interpretation. Those that try to specify endless detail might
> satisfy lawyers, but often become so unwieldy that they aren't as
> useful as they should be to engineers.
True, we've been applying common sense over the years to the original
MIPS SVR psABI as well, which has areas which are grey to say the least
if not outright broken. All I have written is that I think we need to
be careful stating that something is clear where indeed I think we can
have serious doubts about it.
There is this also this note in the "Program Header" section:
"Some entries describe process segments; others give supplementary
information and do not contribute to the process image."
-- if that said say:
"Loadable entries describe process segments..."
or something similar to the same effect, then it would make things
clear about PT_LOAD segments being *the* process image, at least to me.
Otherwise we can of course make a *decision* to interpret a
specification one way or another, or declare that our (or someone
else's) implementation has become the de-facto standard, and then follow
that choice. I think it would also be great to have such decisions and
any backing analysis recorded with commits themselves as well, now that
we've departed from the "ChangeLog entry only for commit logs" rule.
NB I'm not arguing about the actual decision made here, it does seem
reasonable to me.
> > There may be no loader available to load the program headers or the ELF
> > file header if a bare-metal ELF image has been externally loaded according
> > to some interpretation of the headers, and the binary wants to access its
> > own structures at run time. Existing environments may rely on our current
> > semantics even if it is not strictly compliant.
>
> This is true but I was arguing about the validity of the ELF file. I
> mentioned a loader only to say what might be done.
>
> We do know that on reasonably up to date Linux with glibc, that
> linking a simple program with a script that leaves no room for headers
> results in a segfault before Nick's patch, but runs after Nick's
> patch. My suggestion to remove PHDR (patch attached) results in the
> same ld.so segfault. It would certainly be useful to know how vxworks
> behaves with similar tests.
>
> We've also found that Nick's patch broke linux kernel builds, which is
> why I was exploring alternative fixes.
Thanks for your and Nick's effort; I'll be looking into these patches
once I have offloaded my immediately pending queue, which has to take
precedence over any VxWorks cleanups. As I say, what would really help
is if someone who has a suitable test environment available verified the
recent PHDR changes, and if they are indeed fine, then we can then deal
with test suite adjustments ourselves.
Maciej