RE: Create a hook for inspecting program headers during library load

[Roland McGrath <roland at hack dot frob dot com>]

> Seems reasonable, I chose that style to follow this existing code though:
> 
>       if (! __glibc_likely (elf_machine_matches_host (ehdr)))
>         goto close_and_out;

Fair enough.  When I state an aesthetic ideal, it is not unlikely that
there are existing violations of that ideal.  It is yet another aesthetic
choice whether it's best to follow the newly-stated ideal and be
inconsistent with the existing analogous cases, or it's best to be
consistent.  It's not a big deal either way.  If everything else were
perfect in your patch and this were the only potential reason to hold up
committing it, then I probably would not have brought this up.

> I'm struggling to think of a good way to invert the sense of the name:
> 
> elf_machine_phdr_not_ok_p - still has a not in it.
> elf_machine_phdr_bad_p - doesn't really say the right thing
> elf_machine_phdr_incompatible_p - long winded but accurate

The latter is fine.  Or could be elf_machine_should_reject_phdr or
elf_machine_reject_phdr_p.

> There have been various threads edging in this direction and the last one
> asked if I could add some description of how MIPS loadable ABI information
> (beyond the ELF flags) was generally going to work. I'm not entirely sure
> what I'll put either but a basic flow of how information gets from compiler
> through to ld.so seems appropriate.

OK.  That makes sense.  I thought you were talking about a wiki explanation
of this dl-machine.h interface you are adding, which I don't think would
make sense.

> OK. I went for an attachment as the patch sprawled somewhat. I have a few
> thousand line patch coming next (sorry :-)), do you want everything inline
> unless it exceeds the message limit?

Size is irrelevant.  The only reason to use an attachment is if your MUA
otherwise mangles the text so that it cannot be fed into patch or git
apply.  (Size is very relevant to other issues such as whether anybody will
be willing or able to properly review your patch, but that's an unrelated
subject.)

> That sounds ideal but I'm not 100% sure what you mean. I am assuming a
> new header would be #included into all the dl-machine.h files?

No, there is no need for that.  The only place that uses the new function
is dl-load.c, so that is the only place that should include the new header.
That's how you touch only generic code (and later, mips-specific code that
you can yourself test thoroughly).


Thanks,
Roland