I do not like these argv0 tricks, I intend to implement normal options parsing for the direct mode. One of the options would take the file descriptor number and do what your trick does. I think that this is better than the trick since it allows to easily invoke and test the functionality from the shell.

That said, please commit the rename of parse_libdir now. This is the change which is definitely needed for the options parser.

In D10751#222729, @kib wrote:

I do not like these argv0 tricks, I intend to implement normal options parsing for the direct mode. One of the options would take the file descriptor number and do what your trick does. I think that this is better than the trick since it allows to easily invoke and test the functionality from the shell.

You're right, that would be better. Were you thinking of getopt-style parsing (but without pulling in getopt) or environment variables (e.g., LD_BINARY_FD=xx)? The environment variable approach has the benefit of not requiring any new parsing code, but an explicit --fd xx will look more familiar. Then again, if we provide options people might come to expect --help and --usage options. :)

That said, please commit the rename of parse_libdir now. This is the change which is definitely needed for the options parser.

Ok, I'll do that this morning (currently building from a clean checkout, then I'll run the LD_LIBRARY_PATH_FDS test again).

In D10751#222780, @jonathan wrote:

Were you thinking of getopt-style parsing (but without pulling in getopt) or environment variables (e.g., LD_BINARY_FD=xx)? The environment variable approach has the benefit of not requiring any new parsing code, but an explicit --fd xx will look more familiar. Then again, if we provide options people might come to expect --help and --usage options. :)

I intended to provide syntax like

ld-elf.so.1 [-ph] [-f fd] [--] binary args

-h outputs short usage summary, -p means search the $PATH paths for binary, -f fd starts binary pointed to by the filedescriptor fd, -- ends the options list.

Yes, I do not want to reference getopt(3) routine from libc, it would not work anyway, but very similar code is due.

For environment variables I agree that this is not very convenient, but my other concern is that somebody must clean the environment for the started image, since LD_BINARY_FD does not make a sense after ld.so acted, and even is detrimental. ld.so can do the censorship, but I prefer to keep the environment intact.

Two small notes, this is not a review. Mostly to inform you about D10750.

In D10751#222929, @jonathan wrote:

• Merge 'origin/master' into arcpatch-D10751

This merge pulls in the changes from D10750, dropping the now-redundant checks on executable permission bits.

Ok, I think I've addressed all of these points now. I suppose that my use of strncmp comes from... my fingers just don't want to type functions that start with strc? :) Anyhow, I've changed all of the strncmp to strcmp and strnlen to strlen as you've asked.

Overall this looks good.

In D10751#223329, @kib wrote:

For new functions in rtld, I use normal style(9), so rtld slowly migrates to proper indentation. For smaller changes to existing functions I do follow existing style of 4 spaces indent/2 spaces continuation.

Ah, I see... then I suppose I should put the tabs back before committing.