Once we’re no longer using DIA this should be a lot easier to control on our side On Tue, Oct 16, 2018 at 11:17 AM Vedant Kumar <v...@apple.com> wrote:
> > > On Oct 16, 2018, at 10:59 AM, Stella Stamenova <sti...@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:* v...@apple.com <v...@apple.com> > *Sent:* Monday, October 15, 2018 8:34 PM > *To:* Frédéric Riss <fr...@apple.com> > *Cc:* reviews+d50478+public+7e86b794a0909...@reviews.llvm.org; Adrian > Prantl <apra...@apple.com>; paul.robin...@sony.com; jdevliegh...@apple.com; > Jim Ingham <jing...@apple.com>; ztur...@google.com; Stella Stamenova < > sti...@microsoft.com>; abidh....@gmail.com; teempe...@gmail.com; > sgraen...@apple.com; mgr...@codeaurora.org; dblai...@gmail.com; > lldb-commits@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 <fr...@apple.com> wrote: > > > > > On Oct 15, 2018, at 4:40 PM, Vedant Kumar <v...@apple.com> wrote: > > > > > On Oct 15, 2018, at 3:47 PM, Stella Stamenova via Phabricator < > revi...@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%7C9ce5a5c509814cfbe40c08d633183492%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636752576410558617&sdata=FAl5MxKngJHYaphvhHxwZmkM%2FYzOFNN%2F1tc%2B9tn%2B9a4%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%7C9ce5a5c509814cfbe40c08d633183492%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636752576410558617&sdata=QxwDMhgyu1zOnJjSMtG2QzOmhwBtOiRGRKHuyU0gJoU%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)=<unavailable>) > 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] > ^ > <stdin>:3:2: note: scanning from here > frame #1: 0x00000000004005b8 a.out`main(argc=1, (null)=<unavailable>) at > main.cpp:28:3 [opt] > ^ > <stdin>:3:80: note: possible intended match here > frame #1: 0x00000000004005b8 a.out`main(argc=1, (null)=<unavailable>) 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%7C9ce5a5c509814cfbe40c08d633183492%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636752576410558617&sdata=LikQhFyzQHlkQnx39JzJileqEWz4i9BLZe3nRmNeYSM%3D&reserved=0> > > >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
