Page MenuHomePhabricator

[debuginfo-tests] Add some optnone tests
ClosedPublic

Authored by Orlando on Mar 1 2021, 1:45 AM.

Details

Summary

Add dexter tests using the optnone attribute in various scenarios. Our users
have found optnone useful when debugging optimised code. We have these tests
downstream (and one upstream already: D89873) and we would like to contribute
them if there is any interest.

The tests are fairly self explanatory. Testing optnone with:

  • optnone-fastmath.cpp: floats and -ffast-math,
  • optnone-simple-functions: simple functions and integer arithmetic,
  • optnone-struct-and-methods: a struct with methods,
  • optnone-vectors-and-functions: templates and integer vector arithmetic.

optnone-vectors-and-functions contains two FIXMEs. The first problem is that
lldb seems to struggle with evaluating expressions with the templates used
here (example below). Perhaps this is PR42920?

(lldb) p TypeTraits<int __attribute__((ext_vector_type(4)))>::NumElements
error: <user expression 0>:1:1: no template named 'TypeTraits'
TypeTraits<int __attribute__((ext_vector_type(4)))>::NumElements
^

The second is that while lldb cannot evaluate the following expression, gdb
can, but it reports that the variable has been optimzed away. It does this when
compiling at O0 too. llvm-dwarfdump shows that MysteryNumber does have a
location. I don't know whether the DIE is bad or if both debuggers just don't
support it.

TypeTraits<int __attribute__((ext_vector_type(4)))>::MysteryNumber

DW_TAG_variable
    DW_AT_specification   (0x0000006b "MysteryNumber")
    DW_AT_location        (DW_OP_addr 0x601028)
    DW_AT_linkage_name    ("_ZN10TypeTraitsIDv4_iE13MysteryNumberE")

Diff Detail

Event Timeline

Orlando requested review of this revision.Mar 1 2021, 1:45 AM
Orlando created this revision.
rnk accepted this revision.Mar 1 2021, 1:38 PM

lgtm

This is probably more integration testing than I think optnone needs, but I don't see any reason to say no to it.

debuginfo-tests/dexter-tests/optnone-fastmath.cpp
21

I sent a github pull request to turn these off:
https://github.com/google/llvm-premerge-checks/pull/276
Hopefully that works in the future.

This revision is now accepted and ready to land.Mar 1 2021, 1:38 PM
This revision was landed with ongoing or failed builds.Mar 2 2021, 1:01 AM
This revision was automatically updated to reflect the committed changes.

The optnone-simple-functions.cpp test fails on macOS since this commit landed (both on the bot and on my local system). The tests are run as part of the LLDB macOS bot here: http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/ (it's both check-lldb and check-debuginfo so you might have to scroll up to find the check-debuginfo failures).

Traceback (most recent call last):
  File "/Users/buildslave/jenkins/workspace/lldb-cmake@2/llvm-project/debuginfo-tests/dexter/dex/../dexter.py", line 20, in <module>
    return_code = main()
  File "/Users/buildslave/jenkins/workspace/lldb-cmake@2/llvm-project/debuginfo-tests/dexter/dex/tools/Main.py", line 193, in main
    return tool_main(context, module.Tool(context), args)
  File "/Users/buildslave/jenkins/workspace/lldb-cmake@2/llvm-project/debuginfo-tests/dexter/dex/tools/Main.py", line 162, in tool_main
    return_code = tool.go()
  File "/Users/buildslave/jenkins/workspace/lldb-cmake@2/llvm-project/debuginfo-tests/dexter/dex/tools/run_debugger_internal_/Tool.py", line 58, in go
    self.debugger_controller.run_debugger(debugger)
  File "/Users/buildslave/jenkins/workspace/lldb-cmake@2/llvm-project/debuginfo-tests/dexter/dex/debugger/DebuggerControllers/DebuggerControllerBase.py", line 24, in run_debugger
    self._run_debugger_custom()
  File "/Users/buildslave/jenkins/workspace/lldb-cmake@2/llvm-project/debuginfo-tests/dexter/dex/debugger/DebuggerControllers/DefaultController.py", line 55, in _run_debugger_custom
    update_step_watches(step_info, self.watches, self.step_collection.commands)
  File "/Users/buildslave/jenkins/workspace/lldb-cmake@2/llvm-project/debuginfo-tests/dexter/dex/debugger/DebuggerControllers/ControllerHelpers.py", line 30, in update_step_watches
    if (os.path.exists(loc.path)
  File "/usr/local/Cellar/python/3.7.1/Frameworks/Python.framework/Versions/3.7/lib/python3.7/genericpath.py", line 19, in exists
    os.stat(path)
TypeError: stat: path should be string, bytes, os.PathLike or integer, not NoneType

Thanks @teemperor. I've added a quick fix in 61d314024dc4 which fixes the immediate issue of passing in None to os.path.exists (it seems like loc.path being None is a valid state in dexter). I don't have a machine running macOS to test on so I'll keep my eye on the bot.

Thanks @teemperor. I've added a quick fix in 61d314024dc4 which fixes the immediate issue of passing in None to os.path.exists (it seems like loc.path being None is a valid state in dexter). I don't have a machine running macOS to test on so I'll keep my eye on the bot.

Thanks, that fixes my local build so that should also fix the bot.