LGTM. Thank you! will leave this to @MaskRay for the final check.

Thank you for testing this.

In D112297#3092429, @MaskRay wrote:

Agreed. Does this change address this patch's issue (ld.lld --plugin-opt=emit-llvm -mllvm -bitcode-flush-threshold=0 -o /dev/null %t.o)?

Can you post a patch? (Patching lld/ELF/LTO.cpp gives me a feeling working around a pitfall which might well hit others, so fixing the source would be nice.)

To limit the restriction to only devices-like file, this says character and block types are devices, using LLVM enums, it could be like this around here:

In D112297#3092055, @MaskRay wrote:

Thanks for the pointer. Do you have suggestion on how/where to fix the issue leveraging SupportsSeeking?

In D112297#3091836, @MaskRay wrote:

Before openLTOOutputFile is called, the output may be non-existent.
Then if (!sys::fs::is_regular_file(file)) will disable the D86905 memory optimization.

In D86905#3053392, @mehdi_amini wrote:

I didn't notice this was already committed, but numbers are still interesting to go with the change, can you post some here?

typos

tweak

explained what a trace and a chain are.

applied comments

https://github.com/llvm/llvm-project/commit/a806f933a2bf7db444c5687d8d4e07910150ed9c#diff-16afbead86e233f55f648488eae9df30bfd3467147380dfcdeb5a4df0a733905

In D106195#2898145, @gbalats wrote:

In D106195#2884750, @stephan.yichao.zhao wrote:

vfprintf is actually a potential output point, and can be considered as a sink.

It is like __dfsw_write, and needs a callback so that users can decide whether to take this as a sink.

Isn't this the same for fprintf then which is also discarded currently?

In D106594#2898097, @browneee wrote:

This makes issues silent by default.

Please remove vfprintf from the change's description or add a TODO in vfprintf about adding a callback to track it as an output point.

All changes in this CL were submitted in split CLs.

vfprintf is actually a potential output point, and can be considered as a sink.

In D105378#2861914, @morehouse wrote:

We may also want to consider creating a frontend flag like MSan's origin tracking (-fsanitize-memory-track-origins).

clang -> clange++

Added more comments to dfsan_get_track_origins.

update

added a missing file

Thank you for making this work!

Thank you for the refactoring.

Did anyone use mips64 or aarch64...?

In D104165#2814790, @vitalybuka wrote:

why __sanitizer_print_stack_trace is not enough?

How did we fix that alignment error from compiler-rt/test/dfsan/origin_ldst.c?

added a missing test case

The failed test cases from x64 debian > libFuzzer.libFuzzer::* seem related. They still use -dfsan-fast-16-labels.

update

update

update

switched back from option set to individual options.

Please split the sanitizer common change in a separate CL.

update

update

ping

update

update

rebased after D101649

In D101649#2742217, @morehouse wrote:

Change is fine with me, though I wish we understood why it's needed.

added comments

ping

rebased after D101877

update

rebased after D101666

update

update

update

update

update