LGTM. Thanks for the fix.

LGTM

In D81184#2089657, @psmith wrote:

Looking good so far. Would be good to add a range extension thunk test case. For example:

 .section .text.1, "ax", %progbits
 .global _start
 .type _start, %function
_start: .word callee@PLT - .

 .section .text.2, "ax", %progbits
 .global callee
 .type callee, %function        
callee: ret

Using a linker script to get a > 4gb gap. The AT is there to stop a multi gigabyte file being written.

SECTIONS {
  .text.1 0x10000 : { *(.text.1) }
  .text.2 0x200000000 : AT(0x20000) { *(.text.2) }
}

The .word should be an offset to the range extension thunk instead of the target.

Rebased and updated tests with assembly instead of yaml.

Lemme know if there's any more feedback. Will aim for committing this sometime at the end of the day.

D81446 is the LLVM counterpart.

• Removed the llvm changes to be moved to a separate patch.
• Added a test for checking the relocation used with an undefined weak symbol. IIRC, the behavior of this is unspecified anyway.
• Added test for checking overflow.

@rjmccall Would it be fine to submit this since you gave LGTM on D72959?

Rebased

In D80452#2064445, @leonardchan wrote:

Hi! I think this patch might be the cause of the bug at https://bugs.llvm.org/show_bug.cgi?id=46137.

Essentially, we get an error when attempting to create std::array<S, 0> if S has a non-trivial destructor (full example at the bug link):

test.cc:20:20: error: call to implicitly-deleted default constructor of 'std::array<S, 0>'
  std::array<S, 0> x;  // bad
                   ^
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-1-master-fuchsia-toolchain/install/bin/../include/c++/v1/array:252:7: note: default constructor of 'array<S, 0>' is implicitly deleted because field '__w' has a deleted destructor
    } __w;
      ^
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-1-master-fuchsia-toolchain/install/bin/../include/c++/v1/array:248:9: note: explicitly defaulted function was implicitly deleted here
        ~__wrapper() = default;
        ^
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-1-master-fuchsia-toolchain/install/bin/../include/c++/v1/array:251:13: note: destructor of '__wrapper' is implicitly deleted because variant field '__t' has a non-trivial destructor
        _Tp __t;
            ^
test.cc:20:20: error: attempt to use a deleted function
  std::array<S, 0> x;  // bad
                   ^

I believe std::arrays of size 0 should be legal regardless of constraints on the element type.

Hi! I think this patch might be the cause of the bug at https://bugs.llvm.org/show_bug.cgi?id=46137.

In D80692#2061739, @aeubanks wrote:

I foolishly submitted without running check-all, and it turns out this broke a test under check-clang.
Looks like https://reviews.llvm.org/D62888 added tests in sancov-new-pm.c to make sure that sancov + LTO work together, but they won't after this change since the (Thin)LTO pipeline doesn't run things under registerOptimizerLastEPCallback(). So I deleted those tests. Other sanitizers don't work under LTO right now (at least for non-O0) because of the same thing. Does this make sense?

Would be worthwhile to write a small test that asserts Sancov runs before the other sanitizers under the new PM?

*ping*

I decided to just include all the frontend changes here since most of them are tightly coupled. If this patch should be split up more, I don't mind splitting it again.

In D80412#2056353, @nagart wrote:

I don't have commit access. Could any one please help to commit this patch.
Thanks in advance.

LGTM. Confirmed the test passes after this and the correct assembly is generated. Thanks for the fix!

LGTM. Thanks for fixing this!

Hi! I believe commits 5425cdc3adf9998aeaf587d93417bd2f4f1373c9 and 91063cf85a4038537731f582a27936187fb0759c lead to the crash we're seeing in https://bugs.llvm.org/show_bug.cgi?id=46028.

Calculate the address points once beforehand such that we can get an address point from a vtable index.

Evidently I left a lot of spelling mistakes and leftover comments. Cleaned them up!

In D79698#2037425, @aeubanks wrote:

In D79698#2037305, @leonardchan wrote:

Just to followup on this: We believe the root cause of the error we're running into is that some sancov guards in one comdat are being referenced by symbols in another comdat, so due to linking order, the other comdat in question is referencing a sancov guard that was in a discarded comdat group. I posted full details of this on llvm-dev. We believe we're running into this error now because with this patch, inlining occurs after the sanitizers are run.

Based on some discussion in http://lists.llvm.org/pipermail/llvm-dev/2020-May/141558.html, it seems appropriate that the solution for this is to just run sanitizers after inlining, so we would avoid this error that's brought about by inlining after sanitizer runs. Since this has been breaking us for a few days, and unless other folks don't mind, I'm thinking it might be appropriate to temporarily revert this until there's a fix for either

Maybe the fix is to use registerScalarOptimizerLateEPCallback() instead of registerPipelineStartEPCallback(). But I'm not sure how to test that, could you try that and lmk if that fixes the issue?

@pcc Do you happen to have a list of platforms that you suspect use libgcc and will break with this CFI? If this is a bug compatibility issue, we're thinking that instead of just disabling this for everyone, we should instead disable it for a blacklisted set of targets. So all targets by default would go through this branch except for those that actively crash from this.

Just to followup on this: We believe the root cause of the error we're running into is that some sancov guards in one comdat are being referenced by symbols in another comdat, so due to linking order, the other comdat in question is referencing a sancov guard that was in a discarded comdat group. I posted full details of this on llvm-dev. We believe we're running into this error now because with this patch, inlining occurs after the sanitizers are run.

Hello, a bisect seems to show this breaks our 2 stage toolchain build from assertion errors:

This patch seems to lead to the undefined symbol error we're seeing when building fuchsia:

LGTM

In D79445#2021502, @aeubanks wrote:

In D79445#2021311, @leonardchan wrote:

In addSanitizersAtO0, could you make something similar to the ASanPass lambda for the MSan passes and also apply it when adding kernel MSan?

It ends up calling an extra MPM.addPass(createModuleToFunctionPassAdaptor()) in the KernelMemory case, is that okay?

In addSanitizersAtO0, could you make something similar to the ASanPass lambda for the MSan passes and also apply it when adding kernel MSan?

Updated to use builders for constructing the vtable in "leaf" functions instead of returning a value and propagating it back up to a builder. Also extended ConstantAggregateBuilderBase with a method to add a relative offset to a specific position in the aggregate being constructed.

In D77592#2002148, @rjmccall wrote:

Okay. The plan sounds good to me. So you want to roll out this enum in this patch, but not really use it for much until the follow-up?

Updated to reflect the changes in D72959 which make the vtable 4-byte aligned under the Relative layout.

• Remove fuchsia pair from the argument and LangOpt.
• Make the virtual base offset and offset to top 32-bits to make the whole vtable 32-bit aligned.
• Introduce and check against the ItaniumVTableContext::VTableComponentLayout enum which will indicate that vtable components should be relative instead of pointers. Use this instead of making overridable virtual methods in ABI classes since this shouldn't be customized between ABIs.
• Update tests.

Okay, sure, if there are already offsets in bytes already in the AST-level layout, I agree that we should be able to compute all of the byte offsets at that level.

How are you planning to handle alignments here? Currently alignment doesn't affect the layout because all the entries are uniformly pointer-sized. If you're planning to make the offset-to-top and vcall offsets 64-bit on 64-bit architectures, you're going to either have interior padding or those offsets might not be naturally-aligned.

Personally, I would just use 32-bit offsets unless you really think you need to support types with base adjustments more than ±2GB. And that has the nice impact of making all the offsets within the v-table uniformly scaled again, just by 4 bytes instead of the pointer size.

In D77592#1985740, @rjmccall wrote:

I'm not sure if the AST-level v-table layout abstraction really cares about these differences. I don't think it vends byte offsets into the v-table, just slot indices (i.e. word offsets).

LGTM

I'm not sure how to test it yet without adding all the mechanisms for actually laying out the components, but at the very least this adds the switch for it.

Rebased

Updated to address comments and added an RAII class for easier checking before exiting functions.

In D77592#1979030, @rjmccall wrote:

This is a global switch, right, not something that's mix-and-match between hierarchies or even between classes? I think I would prefer that the ABI object just tell us the expected layout of a v-table entry (as an enum) rather than forcing a bunch of different callbacks. Seems more composable, among other things.

In D77592#1975629, @rjmccall wrote:

This is a weird point to allow further ABI customization of. I understand why you want to customize this, but I wonder if it's actually worthwhile to make a virtual function for it vs. just checking some sort of flag in the builder. Isn't there quite a lot of structure you're going to have to duplicate just to call addRelativeAddress at the leaves?

In D57226#1969227, @vabridgers wrote:

https://reviews.llvm.org/D77721 depends on this serialization change for fixed point literals.

Updated such that this ABI is only usable on Fuchsia and if -fexperimental-fuchsia-relative-c++-abi-vtables is passed.

*ping*

Marking WIP for now since (I think for testing), this will require some separate clang changes first.