ping

ping

Remove more unnecessary metadata from test

Address @kyulee 's comments

Update to use cmpValues() instead of cmpBasicBlock

Fix clang crash and retest

ping

ping

Properly refactor the code bc my last attempt was flawed -_-

I've spent some time myself working rebasing this stack and getting it green. Currently running into a runtime crash in libunwind where parseFDEInstructions is being called over and over and exhausting stack memory. Current best guess is that perhaps the stack probing is messing up the call frame information in such a way that causes a loop in the libunwind. If anyone has any suggestions of where to look or how to debug this I would appreciate it :)

ping

ping

Refactor CodeGen code

ping :^)

ping :)

Added checks for distinct metadata in operands to prevent merging unless it's just debug info. This ensures that distinct metadata, which should be treated as different, is not merged.

Generalize the metadata checks

Lets go back to what makes the least changes

Is there any reason why this would be emitting less instructions for just asan-check-memaccess-add.ll?

Make the target generic aarch64

Make sure we don't go from false to true.

Fix the test to be more normal

Jobs are now passing, CC: @nlopes @chandlerc @jgalenson for review :)

In D151276#4366712, @barannikov88 wrote:

I'm not sure this is the correct fix. The assertion specifically checks that MaxCallFrameSize and AdjustsStack computed here are the same as computed by MachineFrameInfo::computeMaxCallFrameSize.
Have you been able to figure out why the results of the calculations are different?

Add full context

I have y'all added here because of your past work on BoundsSan, if you know of anyone else who may be able to provide review please tag them!

clang-format 😺

Rebase on trunk :)

Turns out the lowering of ubsantrap() to a single instruction resulted in binaries that did NOT have nonmerged traps, so this is going back to what we had before. I also added tests to show that the trap gets preserved.

Update the diff to use the nomerge attribute

In D148654#4312478, @smeenai wrote:

Thinking about this a bit more, should the trap not have an associated stack trace that can be symbolicated to tell you which line of code was crashing? If the issue is that multiple traps can get folded together, the nomerge attribute (D78659) could be useful.

I am looking to add stack probing for linux AArch64 using this diff as a basis for my work. Are there any plans to re-introduce this diff for Darwin? Is that something I should take on as well? Context is I am working on mobile apps and we want to add -fstack-clash-protection support :)