[PATCH] D86435: Profiling the code generated by MCJIT engine using Intel VTune profiler

[Jim Ingham via Phabricator via llvm-commits]

jingham added a comment.

In D86435#2342826 <https://reviews.llvm.org/D86435#2342826>, @lhames wrote:

> @jingham @clayborg Do either of you recognize the error that seems to be triggered? It looks like it's consistent across the tests, or at least the ones that I looked at:
>
>   FAIL: test_non_cpp_language_dwarf (TestImportStdModule.ImportStdModule)
>   ----------------------------------------------------------------------
>   Traceback (most recent call last):
>     File "/mnt/disks/ssd0/agent/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1825, in test_method
>       return attrvalue(self)
>     File "/mnt/disks/ssd0/agent/llvm-project/lldb/packages/Python/lldbsuite/test/decorators.py", line 134, in wrapper
>       return func(*args, **kwargs)
>     File "/mnt/disks/ssd0/agent/llvm-project/lldb/test/API/commands/expression/import-std-module/basic/TestImportStdModule.py", line 38, in test_non_cpp_language
>       lldbutil.run_to_source_breakpoint(self,
>     File "/mnt/disks/ssd0/agent/llvm-project/lldb/packages/Python/lldbsuite/test/lldbutil.py", line 953, in run_to_source_breakpoint
>       return run_to_breakpoint_do_run(test, target, breakpoint, launch_info,
>     File "/mnt/disks/ssd0/agent/llvm-project/lldb/packages/Python/lldbsuite/test/lldbutil.py", line 875, in run_to_breakpoint_do_run
>       test.assertEqual(process.GetState(), lldb.eStateStopped)
>   AssertionError: 10 != 5

That's the test failing to stop at the first breakpoint.  10 -> eStateExited, 5 -> eStateStopped.  This sequence, build the binary then do:

  lldbutil.run_to_source_breakpoint(self,
                                    "// Set break point at this line.",
                                    lldb.SBFileSpec("main.cpp"))

to set a breakpoint on that source pattern and run to it is how the vast majority of the Shell tests that actually run a target start up.  Moreover, in this test we actually did manage to resolve the breakpoint, or the test would have failed earlier.  So we must have had debug info we thought was okay.

IIRC the bots use the just-built clang as the builder for the test files, so it's possible that the presence of this patch in the clang we are using for building messes up the line table info so that the breakpoint ends up somewhere that doesn't correspond to code we actually run???   If you have a builder which still has the built products available, it would be interesting to grab one of the ones that is failing like this and try:

(lldb) break set -p "// Set break point at this line."
(lldb) run

and see if it hits the breakpoint.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86435/new/

https://reviews.llvm.org/D86435