[PATCH users/roland/ld-depfile] ld, gold: Add --dependency-file option.

[Fangrui Song]

* Roland McGrath
>On Sun, Jun 14, 2020 at 11:33 PM Alan Modra <amodra@gmail.com> wrote:
>> This should be moved later in the function, at least past the point
>> where incompatible library versions are excluded.  I think I'd put it
>> after the point where we exclude libc.so.1 being loaded if we've
>> already loaded libc.so (when libc.so is a symlink to libc.so.1).
>
>I disagree.  The criterion for inclusion in a dependency file is
>simply that the file was read and its contents (or even mere presence)
>might have influenced the work done.
>
>I think the analogous case to an ELF file that was ignored because of
>its contents (e.g. its e_machine value) is a C header file that is
>entirely empty or has no tokens have preprocessing (e.g. its entire
>contents where inside `#ifdef not_defined_for_this_machine`).  Such
>source files are and must be included in dependency files, even though
>they contributed nothing to the compilation directly.  If the contents
>of that file changed, then repeating the compilation or link step that
>reads that file may very well have different results.  The details of
>what the compiler or linker saw or didn't see inside the file are
>irrelevant to that fact.
>
>The only exception is that files that were never opened at all because
>they didn't exist or because a different file's existence preempted it
>on a search path are not recorded as dependencies, even though
>creating such a file in the future will indeed affect the results of
>repeating the compilation or link step.  That's hard to avoid with the
>way dependencies and search paths work, so we accept that lack.  It's
>exactly the same as for -I paths in the compiler.

Yes. GNU ld and gold support skipping incompatible (e_machine,etc)
files. They should be listed. (LLD does not support the feature).

On 2020-06-15, Roland McGrath wrote:
>On Sat, Jun 13, 2020 at 9:44 AM Fangrui Song <i@maskray.me> wrote:
>> Sorry, but I am not convinced this option provides additional features.
>
>You are mistaken.
>
>> You'd want to link https://sourceware.org/bugzilla/show_bug.cgi?id=22843
>
>I hadn't noticed it had been filed.  I've updated the ChangeLog items
>to mention it and updated the bug.
>Thanks for the pointer!
>
>> tl;dr -t satisfies your needs: { echo -n 'a: '; clang a.o -o a -Wl,-t | sed 's/(.*//' | sort -u | sed '$!s/$/ \\/';} > a.d
>
>This is frankly ludicrous on its face, even if it were technically
>accurate (which it's not).
>
>The possibility of a ridiculous kludge is not a reason to avoid adding
>a sensible feature that is straightforward to use and fits existing
>models.
>
>A kludge like that is hopelessly impractical to integration into build
>systems, which is where this feature is useful.

I don't agree with your argument. If an option just transforms the
output of another one, I am not sure we want to support it.

That being said, this disagreement does not affect my acceptance of this
option, which I have acknowledged previously:

>This is a valid point. However, we still have a problem of lingering
>files in the dependency list, which will be flagged by the next make
>invocation.
>In the traditional make+cc model, -MP is needed
>(https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html )

>Moreover, it's not semantically equivalent.  While it's true that ld
>does print -t output on stdout (gold is incompatible in putting it on
>stderr), it's not true that -t output has equivalent information.
>
>The criterion for -t output is "input object file was included in the
>link".  The criterion for dependency files is "input file was read by
>the linker".
>The -t output omits archives from which no members were taken, input
>linker scripts, -T linker scripts, version scripts, etc.  All of these
>are important in dependency file output.

I agree with this point.  Please make sure the code is organized well so that a future
--reproduce can be easily implemented
(https://sourceware.org/bugzilla/show_bug.cgi?id=26119 I thought I filed
a feature request but it turns that I haven't)



Please ensure INCLUDE/INPUT/GROUP are handled. Please also consider how
to address the -MP problem.