I think you can use wc -c. See e.g. clang/test/Modules/rebuild.m.

A possible concern was that this could be constraining future development by exposing implementation details. But I think that as long as we are free to change how these options are interpreted, or start ignoring them entirely, this is probably fine.

LGTM

Where does the configuration need to live? If it just needs to be a build-time configuration, that may be simpler than exposing new mallopt options.

Any callee-saved register can be used.

Rebase

Add a tuning setting

In D72904#2164880, @MaskRay wrote:

See also @jhenderson's latest reply to the generic-abi thread "SHF_LINK_ORDER's original semantics make upgrade difficult"

# input.o:
<table header> [common]
- DW_TAG_compile_unit [common]
-- DW_TAG_variable [.data.foo]
-- DW_TAG_namespace [common]
--- DW_TAG_subprogram [.text.bar]
--- DW_TAG_variable [.data.baz]
<table footer> [common]

@pcc I sent the patches since you expressed a preference on more work on SHF_LINK_ORDER. Though, @jhenderson's needs (and my header/footer argument in that thread) make me think more whether we should continue patching SHF_LINK_ORDER or start pursuing another section flag.

Without metadata sections's override, SHF_LINK_ORDER will have very few use cases. The problems still exist but we probably don't really need to address them.

Doesn't this require a change to the parser to accept 0 in place of the linked symbol?

In D82251#2106010, @jhenderson wrote:

Seems reasonable, but the llvm-nm documentation needs updating (see llvm/docs/CommandGuide/llvm-nm.rst).

It may also be worth release-noting the change in behaviour too, since it will mean current ARM users who use llvm-nm will see their mapping symbols disappear from the output, if they aren't already using --special-syms.

Win32 has an API for disabling error reporting which is already implemented in sys::DisableSystemDialogsOnCrash(), gtest and relevant test cases such as compiler-rt/test/asan/TestCases/ill.cpp.

LGTM

Should we drop this and just let users set sh_link=self if they want these semantics?

In D80186#2068055, @phosek wrote:

In D80186#2067298, @pcc wrote:

Yeah. Thinking about it more, you may consider a different !associated scheme for the __prof*_ globals.

• __profc_* and __profn_* are associated with a dummy global (to allow the sections to be GC'd).
• __profd_* is associated with the corresponding __profc_* section.

Now no special rules are required for inlining. __profc_* is kept alive via the references in the functions, __profd_ is kept alive via !associated and __profn_* is kept alive by direct reference.

I tried that, but now we get an error ld.lld: error: /tmp/instrprof-gc-sections-5f007f.o:(__llvm_prf_cnts): sh_link points to discarded section /tmp/instrprof-gc-sections-5f007f.o:(__llvm_prf_dummy) because the dummy global was discarded which creates a broken sh_link.

Yeah. Thinking about it more, you may consider a different !associated scheme for the __prof*_ globals.

In this case you might consider replacing the global reference with null and implementing my proposal in https://bugs.llvm.org/show_bug.cgi?id=41734#c2 to make the section SHF_LINK_ORDER with a zero-length .init_array section.

And instead of returning (global_begin, global_end) you could return something like an ArrayRef<hwasan_global> (I don't think we have ArrayRef in compiler-rt, but you could add one, it's pretty simple). Now the client code just looks like

for (hwasan_global &g : HwasanGlobalsFor(phdr, ...)) {
 ...
}

In D80599#2058889, @hctim wrote:

In D80599#2056315, @pcc wrote:

Instead of adding these callbacks would it be simpler to have a function that takes the pointer to phdrs and returns (global_begin, global_end) (both 0 if not present)?

That would require duplicating the global iteration logic across the reporting and initialisation paths, which I was trying to avoid. Having a callback that recieves a single global is easier for my brain, but please let me know if you'd prefer it the other way around.

LGTM

Instead of adding these callbacks would it be simpler to have a function that takes the pointer to phdrs and returns (global_begin, global_end) (both 0 if not present)?

LGTM

In D79818#2035301, @phosek wrote:

In D79818#2035232, @MaskRay wrote:

@mehdi_amini @pcc @tejohnson

I just saw another issue saying that clang -Os -flto=thin a.c does not work https://bugs.llvm.org/show_bug.cgi?id=45913 (+ @manojgupta)
I marked it as yet another duplicate of PR42445

For -Os, clang driver passes -plugin-opt=Os (https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChains/CommonArgs.cpp#L402) but neither LLVMgold.so nor LLD recognizes -plugin-opt=Os.
-Oz is similar. What is the concrete suggestion here? For quick reference, the -plugin-opt=O logic was added by rL256146.

The issue form my perspective is the inconsistency. Today, lld accepts -plugin-opt=O<number> but it doesn't accept -plugin-opt=O<letter>, but Clang automatically translates -O<anything> to -plugin-opt=O<anything> which results in a failure when your try to use -Os, -Oz or -Og with (Thin)LTO.

Not sure if there's a good way to test this @eugenis?

It is unclear to me whether removing the nounwind condition is necessary. The wording in the langref talks about "asynchronous exceptions" but only provides semantics for "exception handling schemes that are recognized by LLVM to handle asynchronous exceptions, such as SEH". Since we don't support anything like that on non-Windows. I don't believe that we need to support throwing exceptions past such functions on DWARF platforms, and the unwind info can only be used for the purpose of creating a stack trace.

LGTM

The architecture may need to be different here IMHO because of subsections. Don't forget that you need to map relocations onto subsections in order to implement gc-sections, and depending on the number of subsections you have per section, that could get expensive without an intermediate data structure. On top of that you'd still need the O(M log N) at output time. To me it seemed better to pay the O(M log N) up front once and avoid the cost at gc-sections time.

In D77283#1984188, @cryptoad wrote:

Thanks Peter & Mitch!
As a side issue, do you have an idea on how to support the interface functions (__scudo_*) for both allocators once we get svelte support?

LGTM

• Replace the fuzzer with one written by mitchp and fix an overflow bug
• Move RegionInfo alignment to field to avoid alignment requirement for getErrorInfo callers

In D77823#1972883, @cryptoad wrote:

Did you verify this works on Fuchsia by chance?

• Fix build error

• Add fuzzer, fix bugs found using it

• Address review comments

It looks like this change broke the sanitizer-x86_64-linux-autoconf buildbot.
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/48824

/b/sanitizer-x86_64-linux-autoconf/build/llvm-project/compiler-rt/lib/tsan/rtl/tsan_clock.cpp:190:13: error: use of undeclared identifier 'dst'
  DCHECK_LE(dst->size_, kMaxTid);
            ^
1 error generated.

Can you please take a look?

This change broke the sanitizer-x86_64-linux bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/26313
Please take a look.

Having given this some more thought, I'm still not in favour of this change even with start/stop symbols excluded, since there are other cases where enumeration of SHF_LINK_ORDER sections may be possible/desirable. To give one example, imagine that you have .init_array sections linked to the globals that they initialize (this may be possible if you can prove that the constructor has no side effects other than initializing the object). With this change we may for example have multiple .init_array sections for .bss and .data, which would need to be accounted for when computing DT_INIT_ARRAY/DT_INIT_ARRAY_SZ. There are various ways that you could deal with this sort of situation, but it seems like the simplest one would be to stick with one output section per file.

This change broke the msan buildbot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/39755

==70358==WARNING: MemorySanitizer: use-of-uninitialized-value
    #0 0x5a602b2 in deleteParallelRegions /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/IPO/OpenMPOpt.cpp:127:9
    #1 0x5a602b2 in (anonymous namespace)::OpenMPOpt::run() /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/IPO/OpenMPOpt.cpp:116:16
    #2 0x5a94252 in (anonymous namespace)::OpenMPOptLegacyPass::runOnSCC(llvm::CallGraphSCC&) /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Transforms/IPO/OpenMPOpt.cpp:559:19
    #3 0x3f53893 in RunPassOnSCC /b/sanitizer-x86_64-linux-fast/build/llvm-project/llvm/lib/Analysis/CallGraphSCCPass.cpp:139:23

In D75617#1908240, @evgeny777 wrote:

@pcc Just to clarify: I'm using this patch to identify problems with WPD (typically those are either invalid reinterpret_cast or open type hierarchy). I find it convenient to obtain a list of devirtualized functions using pass remarks, "undevirtualize" some of them relink and run. With attributes it seems to be much harder

There is already a way to do this, with the attribute [[clang::lto_visibility_public]]. Why do you need another one?

This should be fixed by rG0414c5694073de26fd33a0276c47c6adea5284cf.

Now that llvm-go has been brought back, I've reverted this change.

LGTM

Does it make sense to write a test for this?