TestRegisterVariables broken on FreeBSD in the last couple of days

A commit between r236411 (works) and r236595 (fails) broke
TestRegisterVariables on FreeBSD. I'll bisect the specific commit
later on but wanted to mention it in case the issue is obvious to the
author of the related chagnes:

..
python2.7 SBCommandInterpreter(0x801c6ac00)::HandleCommand
(command="expr c", SBCommandReturnObject(0x801c27b00),
add_to_history=0)
python2.7 SBCommandReturnObject(0x801c27b00)::GetError () => "error:
Couldn't materialize: couldn't get the value of variable c: Unable to
convert register kind=1 reg_num=4294967294 to a native register
number.

Errored out in Execute, couldn't PrepareToExecuteJITExpression
...

Hi,

If anyone, I could have "broken" it. However, I do not think I really
broke it. It was disabled for clang initially, I only enabled it.

Further, if I look at the stdio for the latest completed build on bot
(5512), I see this:

PASS: LLDB (clang-x86_64) :: test_with_dwarf_and_run_command
(TestRegisterVariables.RegisterVariableTestCase)

Can you tell me how you are running this? The error you are have given
should occur if you use GCC to compile the test case (and the hence
the test case is marked xfail for GCC).

Thanks,
Siva Chandra

Hi,

If anyone, I could have "broken" it. However, I do not think I really
broke it. It was disabled for clang initially, I only enabled it.

Indeed - sorry for being imprecise.

Further, if I look at the stdio for the latest completed build on bot
(5512), I see this:

PASS: LLDB (clang-x86_64) :: test_with_dwarf_and_run_command
(TestRegisterVariables.RegisterVariableTestCase)

Can you tell me how you are running this? The error you are have given
should occur if you use GCC to compile the test case (and the hence
the test case is marked xfail for GCC).

I observed the failure on my FreeBSD stable/10 desktop, which has
Clang 3.4.1. The buildbot is running a FreeBSD-HEAD snapshot with
Clang 3.5.1 -- I'll give it a try locally with a newer version.

Which Clang version are you using for the test?

I've tried on FreeBSD-HEAD with Clang 3.6.1 now as well, and it passes
there as well. Perhaps we need an expected failure for clang < 3.5?

That seems to be the best thing to do. Are you going to do it?

Yes, committed now as revision 236614.

As an aside, we'll have to update expectedCompilerVersion to stop
comparing the version numbers as strings before we get to Clang
10.0.0.