[Lldb-commits] [PATCH] D50478: Add support for artificial tail call frames

Fri Oct 19 17:37:00 PDT 2018

Hi Stella,

The logs are really helpful, thanks. This part is unexpected:

python           Finding frames between main and sink(), retn-pc=0x4005b8
python           GetCallEdges: Attempting to parse call site info for main
python           CollectCallEdges: Found call site info in main
python           CollectCallEdges: Found call origin: _Z5func2v (retn-PC: 0x4005b8)
python           CollectCallEdges: Found call origin: _Z5func1v (retn-PC: 0x4005c2)
python           FindInterveningFrames: found call with retn-PC = 0x800a38
python           FindInterveningFrames: found call with retn-PC = 0x800a42

LLDB finds a call from main() with return PC = 0x4005b8. It’s able to parse the call site info within main’s debug info. It finds a call from main() into func2 with that exact return PC. But, the address calculation in CallEdge::GetReturnPCAddress adds the wrong slide to this return PC, giving 0x800a38. This doesn’t match the PC value in the register state, so lldb can’t create a tail call frame.

I think Address::GetLoadAddress is the right API to use, but it’s clearly not achieving the right result here. I’ll experiment with replacing return PC addresses with function-local offsets to the instruction after a call. The idea would be to simply add this offset to the base address of the function, instead of doing a load address calculation.

vedant

> On Oct 18, 2018, at 9:47 AM, Stella Stamenova <stilis at microsoft.com> wrote:
> 
> Hey Vedant,
>  
> I’ve attached the logs from Linux.
>  
> Most of the tests now pass on Windows with the exception of TestSteppingOutWithArtificialFrames and TestTailCallFrameSBAPI. Both of these attempt to get a specific frame by calling GetFrameAtIndex which only works partially on Windows right now. I think we should mark these as XFAIL on Windows and link them to: https://bugs.llvm.org/show_bug.cgi?id=26265 <https://bugs.llvm.org/show_bug.cgi?id=26265>.
>  
> Thanks,
> -Stella
>  
> From: vsk at apple.com <mailto:vsk at apple.com> <vsk at apple.com <mailto:vsk at apple.com>> 
> Sent: Tuesday, October 16, 2018 11:17 AM
> To: Stella Stamenova <stilis at microsoft.com <mailto:stilis at microsoft.com>>
> Cc: Frédéric Riss <friss at apple.com <mailto:friss at apple.com>>; reviews+D50478+public+7e86b794a09096e3 at reviews.llvm.org <mailto:reviews+D50478+public+7e86b794a09096e3 at reviews.llvm.org>; Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>>; paul.robinson at sony.com <mailto:paul.robinson at sony.com>; jdevlieghere at apple.com <mailto:jdevlieghere at apple.com>; Jim Ingham <jingham at apple.com <mailto:jingham at apple.com>>; zturner at google.com <mailto:zturner at google.com>; abidh.haq at gmail.com <mailto:abidh.haq at gmail.com>; teemperor at gmail.com <mailto:teemperor at gmail.com>; sgraenitz at apple.com <mailto:sgraenitz at apple.com>; mgrang at codeaurora.org <mailto:mgrang at codeaurora.org>; dblaikie at gmail.com <mailto:dblaikie at gmail.com>; lldb-commits at lists.llvm.org <mailto:lldb-commits at lists.llvm.org>
> Subject: Re: [PATCH] D50478: Add support for artificial tail call frames
>  
>  
> 
> 
> On Oct 16, 2018, at 10:59 AM, Stella Stamenova <stilis at microsoft.com <mailto:stilis at microsoft.com>> wrote:
>  
> The windows error is because the names are different, as you expected:
> AssertionError: 'void sink(void)' != 'sink()'
> You can probably update the test to look for a different name on Windows (though if I recall correctly, different versions of the DIA sdk provide different detail on the names, so that might not be robust either) or look for a substring in the full name.
>  
> I used a substring check in r344634.
>  
> 
> 
> I’ll look into the Linux error as well and let you know what I find.
>  
> Thank you very much! I really appreciate your help and patience with this.
>  
> The "step" logging channel should provide detailed information about what goes wrong when parsing the DWARF for call site information and creating artificial frames.
>  
> vedant
> 
> 
> From: vsk at apple.com <mailto:vsk at apple.com> <vsk at apple.com <mailto:vsk at apple.com>> 
> Sent: Monday, October 15, 2018 8:34 PM
> To: Frédéric Riss <friss at apple.com <mailto:friss at apple.com>>
> Cc: reviews+D50478+public+7e86b794a09096e3 at reviews.llvm.org <mailto:reviews+D50478+public+7e86b794a09096e3 at reviews.llvm.org>; Adrian Prantl <aprantl at apple.com <mailto:aprantl at apple.com>>; paul.robinson at sony.com <mailto:paul.robinson at sony.com>; jdevlieghere at apple.com <mailto:jdevlieghere at apple.com>; Jim Ingham <jingham at apple.com <mailto:jingham at apple.com>>; zturner at google.com <mailto:zturner at google.com>; Stella Stamenova <stilis at microsoft.com <mailto:stilis at microsoft.com>>; abidh.haq at gmail.com <mailto:abidh.haq at gmail.com>; teemperor at gmail.com <mailto:teemperor at gmail.com>; sgraenitz at apple.com <mailto:sgraenitz at apple.com>; mgrang at codeaurora.org <mailto:mgrang at codeaurora.org>; dblaikie at gmail.com <mailto:dblaikie at gmail.com>; lldb-commits at lists.llvm.org <mailto:lldb-commits at lists.llvm.org>
> Subject: Re: [PATCH] D50478: Add support for artificial tail call frames
> 
> 
> 
> On Oct 15, 2018, at 4:46 PM, Frédéric Riss <friss at apple.com <mailto:friss at apple.com>> wrote:
> 
> 
> 
> 
> On Oct 15, 2018, at 4:40 PM, Vedant Kumar <vsk at apple.com <mailto:vsk at apple.com>> wrote:
> 
> 
> 
> 
> On Oct 15, 2018, at 3:47 PM, Stella Stamenova via Phabricator <reviews at reviews.llvm.org <mailto:reviews at reviews.llvm.org>> wrote:
> 
> stella.stamenova added a comment.
> 
> In https://reviews.llvm.org/D50478#1262717 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD50478%231262717&data=02%7C01%7Cstilis%40microsoft.com%7Cf9216ae492894050d92c08d633939d6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753106442955534&sdata=B7OOidlsIkojfOmNrwDf77eFvcMGnusASMyjrYa8lEI%3D&reserved=0>, @vsk wrote:
> 
> 
> 
> In https://reviews.llvm.org/D50478#1262710 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD50478%231262710&data=02%7C01%7Cstilis%40microsoft.com%7Cf9216ae492894050d92c08d633939d6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753106442955534&sdata=%2BdQxQwN%2B5svfM%2FFNvOR%2FpUhf3lArVs%2FEeeshtYk2qsM%3D&reserved=0>, @stella.stamenova wrote:
> 
> 
> 
> Unfortunately, the bots are broken because of the FileCheck issue, so I can't confirm with them, but I see a number of these tests fail in our local testing. Some fail on both Windows and Linux and some just fail on Linux. Here are the failing tests:
> 
> Linux:
> lldb-Suite :: functionalities/tail_call_frames/disambiguate_call_site/TestDisambiguateCallSite.py
> lldb-Suite :: functionalities/tail_call_frames/disambiguate_paths_to_common_sink/TestDisambiguatePathsToCommonSink.py
> lldb-Suite :: functionalities/tail_call_frames/disambiguate_tail_call_seq/TestDisambiguateTailCallSeq.py
> lldb-Suite :: functionalities/tail_call_frames/inlining_and_tail_calls/TestInliningAndTailCalls.py
> lldb-Suite :: functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
> lldb-Suite :: functionalities/tail_call_frames/thread_step_out_message/TestArtificialFrameStepOutMessage.py
> lldb-Suite :: functionalities/tail_call_frames/unambiguous_sequence/TestUnambiguousTailCalls.py
> 
> Windows:
> lldb-Suite :: functionalities/tail_call_frames/sbapi_support/TestTailCallFrameSBAPI.py
> lldb-Suite :: functionalities/tail_call_frames/thread_step_out_or_return/TestSteppingOutWithArtificialFrames.py
> 
> 
> Let me know what you need to investigate.
> 
> 
> Strange, I didn't get any bot failure notifications in the days after this landed. Could you share the output from the failing tests?
> 
> 
> All the failures on Windows are happening when validating the function name. For example:
> 
> ======================================================================
> 
> FAIL: test_tail_call_frame_sbapi (TestTailCallFrameSBAPI.TestTailCallFrameSBAPI)
> 
> ----------------------------------------------------------------------
> 
> Traceback (most recent call last):
> 
> File "E:\_work\55\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\tail_call_frames\sbapi_support\TestTailCallFrameSBAPI.py", line 19, in test_tail_call_frame_sbapi
> 
> self.do_test()
> 
> File "E:\_work\55\s\llvm\tools\lldb\packages\Python\lldbsuite\test\functionalities\tail_call_frames\sbapi_support\TestTailCallFrameSBAPI.py", line 64, in do_test
> 
> self.assertTrue(frame.GetDisplayFunctionName() == name)
> 
> It could be that the display name of a function is formatted differently on Windows. Do you have an easy way of determining what frame.GetDisplayFunctionName() is?
> If you use assertEqual(a,b) instead of assertTrue, it will print out the values and make it easier to debug.
> Thanks, done in r344581.
> vedant
> 
> 
> 
> Fred
> 
> 
> 
> 
> 
> 
> 
> AssertionError: False is not True
> 
> Config=x86_64-E:\_work\55\b\LLVMBuild\Release\bin\clang.exe
> 
> ----------------------------------------------------------------------
> 
> There are several different failures on Linux. Here's the first one:
> 
> FAIL: LLDB (/vstsdrive/_work/38/b/LLVMBuild/bin/clang-8-x86_64) :: test_dwarf (lldbsuite.test.lldbtest.TestDisambiguateCallSite)
> 
> --- FileCheck trace (code=1) ---
> /vstsdrive/_work/38/b/LLVMBuild/bin/FileCheck /vstsdrive/_work/38/s/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp -implicit-check-not=artificial
> 
> FileCheck input:
> * thread #1, name = 'a.out', stop reason = breakpoint 1.1
> * frame #0: 0x0000000000400580 a.out`sink() at main.cpp:13:4 [opt]
> frame #1: 0x00000000004005b8 a.out`main(argc=1, (null)=) at main.cpp:28:3 [opt]
> frame #2: 0x00007f980aff7830 libc.so.6`__libc_start_main + 240
> frame #3: 0x00000000004004a9 a.out`_start + 41
> 
> It looks like we're not generating tail call frames on Linux at all. It would help to have logs from "log enable -f /tmp/linux-stepping.log lldb step".
> 
> I'm headed out of the office now, but If you need to disable the tests on Windows/Linux , the fastest way to do that would be to add a platform check to skipUnlessHasCallSiteInfo in decorators.py.
> 
> vedant
> 
> 
> 
> 
> 
> 
> FileCheck output:
> 
> /vstsdrive/_work/38/s/llvm/tools/lldb/packages/Python/lldbsuite/test/functionalities/tail_call_frames/disambiguate_call_site/main.cpp:15:17: error: CHECK-NEXT: expected string not found in input
> // CHECK-NEXT: func2{{.*}} [opt] [artificial]
> ^
> :3:2: note: scanning from here
> frame #1: 0x00000000004005b8 a.out`main(argc=1, (null)=) at main.cpp:28:3 [opt]
> ^
> :3:80: note: possible intended match here
> frame #1: 0x00000000004005b8 a.out`main(argc=1, (null)=) at main.cpp:28:3 [opt]
> ^
> 
> Let me know if you need more logs.
> 
> 
> Repository:
> rLLDB LLDB
> 
> https://reviews.llvm.org/D50478 <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD50478&data=02%7C01%7Cstilis%40microsoft.com%7Cf9216ae492894050d92c08d633939d6f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636753106442955534&sdata=NtVhAL0OUf26pOdcD2EdILhwqG8Mfgrc3kEEywrZ5as%3D&reserved=0>
>  
> <linux-stepping.log>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20181019/840586d6/attachment-0001.html>