This is an archive of the discontinued LLVM Phabricator instance.

Add SBDebugger::GetBuildConfiguration and use it to skip an XML test
ClosedPublic

Authored by labath on Feb 15 2018, 4:14 AM.

Details

Summary

This adds a SBDebugger::GetBuildConfiguration static function, which
returns a SBStructuredData describing the the build parameters of
liblldb. Right now, it just contains one entry: whether we were built
with XML support.

I use the new functionality to skip a test which requires XML support,
but concievably the new function could be useful to other liblldb
clients as well (making sure the library supports the feature they are
about to use).

Diff Detail

Repository
rL LLVM

Event Timeline

labath created this revision.Feb 15 2018, 4:14 AM
clayborg accepted this revision.Feb 15 2018, 8:07 AM

Think if we want to cache the configuration in case we start using this a lot more in the test suite. Doesn't need to be done now.

packages/Python/lldbsuite/test/decorators.py
767–771 ↗(On Diff #134403)

Might be nice to read all values from lldb.SBDebugger.GetBuildConfiguration() and store them one time? If we start using this all the time for many decorators, it would be a good idea to cache it. Thinking something like:

lldb_config = None
def getLLDBConfig():
  global lldb_config
  if lldb_config is None:
      lldb_config = lldb.SBDebugger.GetBuildConfiguration()
  return lldb_config

def skipIfXmlSupportMissing(func):
  config = getLLDBConfig()
  ...
This revision is now accepted and ready to land.Feb 15 2018, 8:07 AM
jingham accepted this revision.Feb 15 2018, 10:57 AM

Caching this value wouldn't hurt, but the the multi-process runner will mostly defeat that so it doesn't seem crucial.

The API is fine, the name is pretty obvious, but still some doc wouldn't hurt.

I was wondering if there was a straightforward way we could document the elements. Be nice not to have to read source to see what these mean. OTOH, I don't think we want to produce it in this dictionary, that makes the checks more expensive. So if we find we need it we can add a doc API that generates a parallel doc tree. But I don't think it's necessary to do that right now.

clayborg added inline comments.Feb 15 2018, 11:09 AM
source/API/SBDebugger.cpp
497 ↗(On Diff #134403)

Do we want a more self documenting format of the JSON? Maybe "xml" is a dictionary instead of just a value?

{ 
  "xml" : {
    "value" : true, 
    "description" : "A boolean value that indicates if XML support is enabled in LLDB" 
  }
}
labath updated this revision to Diff 134564.Feb 16 2018, 1:15 AM

I've updated the format to include a description of the item. I don't we need to
worry about the expensiveness of this data structure too much, as it should
never be used in a hot loop (the only use case I can think of is querying the
configuration at start-up).

clayborg accepted this revision.Feb 16 2018, 7:04 AM

Looks good. Self describing and concise.

jingham accepted this revision.Feb 16 2018, 11:41 AM

Excellent, thanks.

This revision was automatically updated to reflect the committed changes.