[lld] r293792 - Strip file path from the -o option while creating reproduce.txt.

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Fri Feb 3 21:28:42 PST 2017

On Fri, Feb 3, 2017 at 11:39 AM, Ed Maste via llvm-commits <
llvm-commits at lists.llvm.org> wrote:

> On 1 February 2017 at 18:52, Rafael Avila de Espindola
> <rafael.espindola at gmail.com> wrote:
> >
> > Can you expand a bit on the use case of preserving the full path?
> During some FreeBSD experiments I built with make -i (ignore
> failures), then set the reproduce environment variable and reran with
> make -i.

How did you avoid having all of the LLD invocations from stomping on the
same .tar file when building with `make -i`? I assume you used the
LLD_REPRODUCE environment variable. After I initially came up with the idea
for the LLD_REPRODUCE environment variable (while watching Davide chasing
through the FreeBSD makefiles trying to add --reproduce), one of the
immediate follow-on thoughts was how to prevent all the different
invocations from writing to the same file when you set the environment
variable. One idea is to have some sort of escape sequences like `%b` or
something that expands to the output binary name (or something like that).

E.g. you can imagine something like
`LLD_REPRODUCE=/tmp/lld_reproduce/%b_%u.txt build_everything.sh`. %b is the
basename of the output binary, %u is a unique identifier (in case multiple
output binaries happen to have the same basename; e.g. if building the base
system builds 32 and 64-bit versions of everything or if there is a 3-stage
bootstrap or something).

Probably the simplest approach would be `--reproduce %o_repro.tar` and %o
expands to the full absolute path of the output binary. I.e. `-o bin/clang
--reproduce %o_repro.tar` would create `/path/to/bin/clang_repro.tar` and
`-o bin/clang --reproduce /tmp%o_repro.tar` would create
`/tmp/path/to/bin/clang_repro.tar` (this case would not work on windows but
meh :|).

-- Sean Silva

> That gave me a reproduction .tar and response file for each
> failing case, which I reran with ld.bfd to produce the output directly
> in the target directory. This was mainly a convenience because the
> FreeBSD build builds its own toolchain so it's not necessarily
> straightforward to find the exact invocation used, or rebuild one
> component with special CFLAGS etc. All of that said, for FreeBSD we're
> beyond the point where this is needed now and I don't have a strong
> feeling on it.
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170203/0eec528f/attachment.html>

More information about the llvm-commits mailing list