This is an archive of the discontinued LLVM Phabricator instance.

[DebugInfo] Fix ARM/AArch64 prologue_end position
AbandonedPublic

Authored by kubamracek on Jul 16 2015, 8:21 AM.

Details

Reviewers
rengolin
echristo
Summary

It seems that DWARF prologue_end flag, which should be placed right after the function prologue, is often placed at the function entry point for ARM and AArch64. I filed https://llvm.org/bugs/show_bug.cgi?id=24117 about it, where I thought this was a recent regression for -O1, but in fact I found an even easier test case which reproduces this bug with basically all versions of LLVM and at -O0:

int func(void);
void prologue_end_test() {
  func();
  func();
}

compiles to (with -g -O0 -armv7):

_prologue_end_test:
Lfunc_begin0:
    .file   1 "foo.c"
    .loc    1 2 0                   @ foo.c:2:0
    .cfi_startproc
@ BB#0:                                 @ %entry
    .loc    1 3 3 prologue_end      @ foo.c:3:3
    push    {r7, lr}
    mov r7, sp
    sub sp, #8
    bl  _func
    .loc    1 4 3                   @ foo.c:4:3
    str r0, [sp, #4]            @ 4-byte Spill
    bl  _func
    ...

Obviously, the prologue isn't empty, and the prologue_end line should actually be placed before the first bl _func call.

This bug is not present on x86/x86_64. The reason why this happens is that the ARM and AArch64 backends emit line number information for the prologue's MIs. When generating the prologue, the DebugLoc from the first MI is copied to all the instructions of the prologue (but the first MI's DebugLoc can be empty in which case things are fine). The X86 backend doesn't do that and it never assigns line information to the prologue. The DWARF debug info writer attaches the prologue_end flag to the first instruction that has a non-empty debug location.

This patch changes the ARM and AArch64 prologues not to have line information.

Diff Detail

Event Timeline

kubamracek updated this revision to Diff 29914.Jul 16 2015, 8:21 AM
kubamracek retitled this revision from to [DebugInfo] Fix ARM/AArch64 prologue_end position.
kubamracek updated this object.

There should be a comment explaining that the DebugLocs are dropped because of the LLVM convention that the prologue end is marked by the first instruction with a non-empty DebugLoc.

There should be a comment explaining that the DebugLocs are dropped because of the LLVM convention that the prologue end is marked by the first instruction with a non-empty DebugLoc.

In the test cases or in the backend changes? (Sorry, I'm not really familiar with these parts of LLVM)

asl added a subscriber: asl.Jul 16 2015, 9:08 AM
asl set the repository for this revision to rL LLVM.Jul 16 2015, 9:20 AM
asl added a subscriber: iid_iunknown.

ARM and AArch64 appear to be not the only backends with this problem.
Mips, SystemZ and Sparc backends similarly place prologue_end at the function entry point.

BTW, I think this is why ASan test cases, such as https://github.com/llvm-mirror/compiler-rt/blob/master/test/asan/TestCases/use-after-free.cc need to be currently XFAIL'd on ARM.

kubamracek updated this revision to Diff 30142.Jul 20 2015, 3:24 AM
kubamracek removed rL LLVM as the repository for this revision.

Extending the fix to all backends that attach debug locations to generated prologue. Added test cases for all these targets. Added a comment explaining why we want to use empty/invalid location (actually, I found that comment in the XCore backend, and just copied it).

asl added inline comments.Jul 20 2015, 3:35 AM
lib/Target/Mips/Mips16InstrInfo.cpp
448 ↗(On Diff #30142)

Wow. Looks like MIPS backend certainly deserves a good run of clang-format! (unrelated to this patch :) )

asl added a comment.Jul 22 2015, 7:35 AM

In general, LGTM. But we certainly need to ping the maintainers of the backends :)

In D11268#209702, @asl wrote:

In general, LGTM. But we certainly need to ping the maintainers of the backends :)

Could you please CC them on this patch?

rengolin accepted this revision.Jul 22 2015, 8:03 AM
rengolin added a reviewer: rengolin.

LGTM.

This revision is now accepted and ready to land.Jul 22 2015, 8:03 AM

One inline comment. My general preference would be an explicit DebugLoc in all of these uses, but maybe it doesn't matter that much. The inline comment does :)

-eric

lib/Target/ARM/ARMFrameLowering.cpp
327–328

The DebugLoc for all uses of emitSPUpdate is now just DebugLoc so you can remove the parameter.

kubamracek added inline comments.Jul 23 2015, 8:06 AM
lib/Target/ARM/ARMFrameLowering.cpp
327–328

Hm, but emitSPUpdate is also used from emitEpilogue and eliminateCallFramePseudoInstr, where some debug location is still used (and it's not relevant to the bug I'm trying to fix, which is wrong prologue_end in DWARF).

echristo accepted this revision.Sep 9 2015, 12:48 PM
echristo edited edge metadata.

Sure, if you could look at that and write it in a way that doesn't it'd be appreciated because it's mostly dead at this point, but please go ahead here.

-eric

Hi Kuba,

This review has been hold for some time.
There are merge conflicts with the current trunk now. I rebased your changes, solved the conflicts and updated the patch for your convenience. It is not possible to update someone else's patch so I created a new request: http://reviews.llvm.org/D14338.

Please note that the changes in MipsSEFrameLowering.cpp, MipsSEInstrInfo.cpp, Mips/prologue_end.ll and delay-slot.ll are no longer needed as they have been done in r246309.

The prologue_end.ll tests fail as the subprogram definitions are required to be distinct. They have been marked distinct to make the tests pass.

Would you take a look at the new patch and let me know if you were going to commit your changes, please? I could commit it for you if this would be more convenient.

Thank you.

Thanks for doing this! Please go ahead and commit (this patch was already LGTM'd so I think it's okay). Please note that when you commit, you might see a buildbot failure in ARM/AArch64 tests in compiler-rt/sanitizers/ASan/TSan -- this might actually be okay, IIRC there are a few XFAILs because of this bug. Let me know if you see such a test failure.

iid_iunknown added a comment.EditedNov 5 2015, 9:54 AM

Thank you for your review and remarks!
D14338 has been committed. I will let you know if such problems with the tests arise.

kubamracek abandoned this revision.Nov 12 2015, 1:45 AM