This is an archive of the discontinued LLVM Phabricator instance.

[ARM] Restore the right frame pointer register in Int_eh_sjlj_longjmp
ClosedPublic

Authored by mstorsjo on Sep 25 2017, 1:02 PM.

Details

Summary

In setupEntryBlockAndCallSites in CodeGen/SjLjEHPrepare.cpp, we fetch and store the actual frame pointer, but on return via the longjmp intrinsic, it always was restored into the r7 variable.

On windows, the frame pointer should be restored into r11 instead of r7.

On Darwin (where sjlj exception handling is used by default), the frame pointer is always r7, both in arm and thumb mode, and likewise, on windows, the frame pointer always is r11.

On linux however, if sjlj exception handling is enabled (which it isn't by default), libcxxabi and the user code can be built in differing modes using different registers as frame pointer. Therefore, when restoring registers on a platform where we don't always use the same register depending on code mode, restore both r7 and r11.

Diff Detail

Repository
rL LLVM

Event Timeline

mstorsjo created this revision.Sep 25 2017, 1:02 PM
compnerd edited edge metadata.Sep 26 2017, 1:55 PM

Um, doesn't that clobber a register which is unexpected?

Um, doesn't that clobber a register which is unexpected?

I would think it doesn't really matter. Since the __builtin_longjmp only restores fp, sp and pc, the landing pad needs to restore any other registers it expects to have any specific value anyway, so I would expect it not to matter if we additionally modify r7/r11 here.

If you disagree, I can at least provide a version of this patch that only restores one single register, based on useR7AsFramePointer(). That should work in all cases except on linux, if cxxabi and the user code are built in differing arm/thumb modes.

FWIW, this was more or less approved by @t.p.northover on IRC:

"The second one is ugly, but that describes SjLj as a whole so I doubt we'd be making the world a worse place." and "There was actually some talk about standardising FP a while ago. Doesn't seem to have gone anywhere yet though."

So unless there's further comments, I'll probably push this later today/tomorrow.

This revision was automatically updated to reflect the committed changes.
MatzeB added a subscriber: MatzeB.Sep 29 2017, 8:34 AM

FWIW, this was more or less approved by @t.p.northover on IRC:

"The second one is ugly, but that describes SjLj as a whole so I doubt we'd be making the world a worse place." and "There was actually some talk about standardising FP a while ago. Doesn't seem to have gone anywhere yet though."

This is NOT how patch aproval works in llvm!! Please revert!

Just glancing at this I can see this changes the asmprinter output but not the modelling of the instruction which now changes r11 in some cases but does not model that fact with machine operands.

llvm/trunk/lib/Target/ARM/ARMAsmPrinter.cpp
1207

There’s no need to put those statements on the hot path of this function.

mstorsjo added a subscriber: xtkoba.

FWIW, this was more or less approved by @t.p.northover on IRC:

"The second one is ugly, but that describes SjLj as a whole so I doubt we'd be making the world a worse place." and "There was actually some talk about standardising FP a while ago. Doesn't seem to have gone anywhere yet though."

This is NOT how patch aproval works in llvm!! Please revert!

Really sorry about this - I entirely missed this comment back then... :-( At this point, though, reverting is a bit late/harsh...

Just glancing at this I can see this changes the asmprinter output but not the modelling of the instruction which now changes r11 in some cases but does not model that fact with machine operands.

A suggested follow-up patch in D109041 adds r11 for tInt_eh_sjlj_longjmp in ARMInstrThumb.td - does that fix this particular concern (if we'd do the same for Int_eh_sjlj_longjmp in ARMInstrInfo.td too)?

llvm/trunk/lib/Target/ARM/ARMAsmPrinter.cpp
1207

Good point, I'll send a separate patch to fix that, if they aren't used elsewhere now.

Herald added a project: Restricted Project. · View Herald TranscriptSep 1 2021, 12:24 AM