Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

2015-09-14 Thread Todd Fiala via lldb-dev 
Checking the disposition of these now.

On Wed, Sep 9, 2015 at 8:10 AM, Todd Fiala  wrote:

> We have a chunk of tests that are marked xfail that pass right now on OS
> X.  I'll go through those in the near future.
>
> I'm also seeing several tests consistently unexpectedly pass on Linux
> x86_64 (Ubuntu 14.04) built with clang-3.6.  I think at least some of them
> fail with gcc-4.9, so they might need to be marked up based on the
> compiler.  I plan to look at those soonish as well.
>
> On Wed, Sep 9, 2015 at 6:21 AM, Ed Maste via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Two tests are currently decorated with a @unittest2.expectedFailure
>> referencing rdar tickets. These tests pass consistently for me on
>> FreeBSD. Can I ask the Apple folks to look at these tickets and put
>> details in a public PR if appropriate? Alternatively, shall I switch
>> the tests to expectedFailureDarwin?
>>
>> Also, are these tests passing on Linux?
>>
>> -Ed
>>
>> test/driver/batch_mode/TestBatchMode.py
>> @unittest2.expectedFailure(", lldb doesn't
>> reliably print the prompt when run under pexpect")
>>
>> test/functionalities/inferior-assert/TestInferiorAssert.py
>> @unittest2.expectedFailure("rdar://15367233")
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>
>
>
> --
> -Todd
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 24282] test_with_dwarf_formatters_api (TestFormattersSBAPI.SBFormattersAPITestCase) failing on FreeBSD

2015-09-14 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=24282

ema...@freebsd.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

2015-09-14 Thread Todd Fiala via lldb-dev 
Those radars are both listed as fixed.  I'm building and will run the tests
on OS X to verify I don't see them here.  Assuming they pass, I'll strip
the xfail marker.

-Todd

On Mon, Sep 14, 2015 at 7:32 AM, Todd Fiala  wrote:

> Checking the disposition of these now.
>
> On Wed, Sep 9, 2015 at 8:10 AM, Todd Fiala  wrote:
>
>> We have a chunk of tests that are marked xfail that pass right now on OS
>> X.  I'll go through those in the near future.
>>
>> I'm also seeing several tests consistently unexpectedly pass on Linux
>> x86_64 (Ubuntu 14.04) built with clang-3.6.  I think at least some of them
>> fail with gcc-4.9, so they might need to be marked up based on the
>> compiler.  I plan to look at those soonish as well.
>>
>> On Wed, Sep 9, 2015 at 6:21 AM, Ed Maste via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Two tests are currently decorated with a @unittest2.expectedFailure
>>> referencing rdar tickets. These tests pass consistently for me on
>>> FreeBSD. Can I ask the Apple folks to look at these tickets and put
>>> details in a public PR if appropriate? Alternatively, shall I switch
>>> the tests to expectedFailureDarwin?
>>>
>>> Also, are these tests passing on Linux?
>>>
>>> -Ed
>>>
>>> test/driver/batch_mode/TestBatchMode.py
>>> @unittest2.expectedFailure(", lldb doesn't
>>> reliably print the prompt when run under pexpect")
>>>
>>> test/functionalities/inferior-assert/TestInferiorAssert.py
>>> @unittest2.expectedFailure("rdar://15367233")
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 23747] test_process_list (TestPlatformCommand.PlatformCommandTestCase) failing on FreeBSD buildbot

2015-09-14 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=23747

ema...@freebsd.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from ema...@freebsd.org ---
Passes locally and the old FreeBSD LLDB buildbot has been retired. Will
investigate again if it fails on the new buildbot when it is set up.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 18533] Failing FreeBSD test case test_inferior_asserting_disassemble (TestInferiorAssert.AssertingInferiorTestCase)

2015-09-14 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=18533

ema...@freebsd.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from ema...@freebsd.org ---
Test changed in r198962 and r219544

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

2015-09-14 Thread Todd Fiala via lldb-dev 
I ran the tests against the latest official beta lldb on OS X and they are
passing (unexpected successes).  Flipping that now...

On Mon, Sep 14, 2015 at 7:35 AM, Todd Fiala  wrote:

> Those radars are both listed as fixed.  I'm building and will run the
> tests on OS X to verify I don't see them here.  Assuming they pass, I'll
> strip the xfail marker.
>
> -Todd
>
> On Mon, Sep 14, 2015 at 7:32 AM, Todd Fiala  wrote:
>
>> Checking the disposition of these now.
>>
>> On Wed, Sep 9, 2015 at 8:10 AM, Todd Fiala  wrote:
>>
>>> We have a chunk of tests that are marked xfail that pass right now on OS
>>> X.  I'll go through those in the near future.
>>>
>>> I'm also seeing several tests consistently unexpectedly pass on Linux
>>> x86_64 (Ubuntu 14.04) built with clang-3.6.  I think at least some of them
>>> fail with gcc-4.9, so they might need to be marked up based on the
>>> compiler.  I plan to look at those soonish as well.
>>>
>>> On Wed, Sep 9, 2015 at 6:21 AM, Ed Maste via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 Two tests are currently decorated with a @unittest2.expectedFailure
 referencing rdar tickets. These tests pass consistently for me on
 FreeBSD. Can I ask the Apple folks to look at these tickets and put
 details in a public PR if appropriate? Alternatively, shall I switch
 the tests to expectedFailureDarwin?

 Also, are these tests passing on Linux?

 -Ed

 test/driver/batch_mode/TestBatchMode.py
 @unittest2.expectedFailure(", lldb doesn't
 reliably print the prompt when run under pexpect")

 test/functionalities/inferior-assert/TestInferiorAssert.py
 @unittest2.expectedFailure("rdar://15367233")
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Looking for info on two rdars: 18684124, 15367233

2015-09-14 Thread Todd Fiala via lldb-dev 
Done:
Sendingtest/driver/batch_mode/TestBatchMode.py
Sendingtest/functionalities/inferior-assert/TestInferiorAssert.py
Transmitting file data ..

On Mon, Sep 14, 2015 at 7:43 AM, Todd Fiala  wrote:

> I ran the tests against the latest official beta lldb on OS X and they are
> passing (unexpected successes).  Flipping that now...
>
> On Mon, Sep 14, 2015 at 7:35 AM, Todd Fiala  wrote:
>
>> Those radars are both listed as fixed.  I'm building and will run the
>> tests on OS X to verify I don't see them here.  Assuming they pass, I'll
>> strip the xfail marker.
>>
>> -Todd
>>
>> On Mon, Sep 14, 2015 at 7:32 AM, Todd Fiala  wrote:
>>
>>> Checking the disposition of these now.
>>>
>>> On Wed, Sep 9, 2015 at 8:10 AM, Todd Fiala  wrote:
>>>
 We have a chunk of tests that are marked xfail that pass right now on
 OS X.  I'll go through those in the near future.

 I'm also seeing several tests consistently unexpectedly pass on Linux
 x86_64 (Ubuntu 14.04) built with clang-3.6.  I think at least some of them
 fail with gcc-4.9, so they might need to be marked up based on the
 compiler.  I plan to look at those soonish as well.

 On Wed, Sep 9, 2015 at 6:21 AM, Ed Maste via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> Two tests are currently decorated with a @unittest2.expectedFailure
> referencing rdar tickets. These tests pass consistently for me on
> FreeBSD. Can I ask the Apple folks to look at these tickets and put
> details in a public PR if appropriate? Alternatively, shall I switch
> the tests to expectedFailureDarwin?
>
> Also, are these tests passing on Linux?
>
> -Ed
>
> test/driver/batch_mode/TestBatchMode.py
> @unittest2.expectedFailure(", lldb doesn't
> reliably print the prompt when run under pexpect")
>
> test/functionalities/inferior-assert/TestInferiorAssert.py
> @unittest2.expectedFailure("rdar://15367233")
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>



 --
 -Todd

>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>
>>
>>
>> --
>> -Todd
>>
>
>
>
> --
> -Todd
>



-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 24812] New: Expression evaluation crashes when definition of class not available for a class

2015-09-14 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=24812

Bug ID: 24812
   Summary: Expression evaluation crashes when definition of class
not available for a class
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Linux
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: tbergham...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 14877
  --> https://llvm.org/bugs/attachment.cgi?id=14877&action=edit
Source to reproduce the bug

Steps to reproduce:
* Compile the attached inferior with clang++ (tested with clang-3.5 on Linux
x86_64) with the following command line: "clang++ -g ss.cpp"
* lldb a.out
* (lldb) breakpoint set -n main
* (lldb) run
* (lldb) next
* (lldb) expression f

* Observed behavior: LLDB crashes with
"llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:2868: const
clang::ASTRecordLayout &clang::ASTContext::getASTRecordLayout(const
clang::RecordDecl *) const: Assertion `D && "Cannot get layout of forward
declarations!"' failed"
* Expected behavior: The content off the variable displayed correctly
* Acceptable behavior: LLDB displays an error message without crashing

The root cause of the problem is that clang only includes the declaration of
std::string in the debug info and expects that the debugger can access to it
from a different source. If "-fno-limit-debug-info" is specified to the
compiler, then the error disappears.

The crash can happen during any part of the debug session (e.g. single
stepping, back tracing), but reproducing it in those cases is more difficult.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] cleaning up unexpected successes on OS X

2015-09-14 Thread Todd Fiala via lldb-dev 
Hey all,

As of this change:
r247567 | tfiala | 2015-09-14 07:48:53 -0700 (Mon, 14 Sep 2015) | 7 lines

I'm seeing the following unexpected successes on OS X:

Unexpected Successes (16)

UNEXPECTED SUCCESS: LLDB (suite) :: TestCallStdStringFunction.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestCallWithTimeout.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestClassTypes.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestConstVariables.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestExprHelpExamples.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestFdLeak.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestMultipleDebuggers.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestObjCNewSyntax.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestPersistObjCPointeeType.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestProcessLaunch.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestRaise.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestRegisterVariables.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestRvalueReferences.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestStubSetSID.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestTargetAPI.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)

UNEXPECTED SUCCESS: LLDB (suite) :: TestThreadExit.py (Darwin
tfiala-mbp-01.local 15.0.0 Darwin Kernel Version 15.0.0: Thu Sep 10
17:51:41 PDT 2015; root:xnu-3247.10.9~1/DEVELOPMENT_X86_64 x86_64 i386)


I'm going to look at cleaning these up today.
-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 24813] New: TestBatchMode is not remote-ready

2015-09-14 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=24813

Bug ID: 24813
   Summary: TestBatchMode is not remote-ready
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: lab...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

The test fails for remote platforms as it does not know how to run processes
remotely.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 20273] TestTargetAPI.test_launch_new_process_and_redirect_stdout_with_* failing on Darwin

2015-09-14 Thread via lldb-dev 
https://llvm.org/bugs/show_bug.cgi?id=20273

Todd Fiala  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||todd.fi...@gmail.com
 Resolution|--- |FIXED

--- Comment #1 from Todd Fiala  ---
This is working now (at least, on El Capitan most recent beta).  Fixing up test
markings.

Sendingtest/python_api/target/TestTargetAPI.py
Sendingtest/tools/lldb-server/commandline/TestStubSetSID.py
Transmitting file data ..
Committed revision 247605.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Digging into Linux unexpected successes

2015-09-14 Thread Todd Fiala via lldb-dev 
On an Ubuntu 14.04 x86_64 system, I'm seeing the following results:

*cmake/ninja/clang-3.6:*

Testing: 395 test suites, 24 threads
395 out of 395 test suites processed - TestGdbRemoteKill.py
Ran 395 test suites (0 failed) (0.00%)
Ran 478 test cases (0 failed) (0.00%)

Unexpected Successes (6)
UNEXPECTED SUCCESS: LLDB (suite) :: TestConstVariables.py
UNEXPECTED SUCCESS: LLDB (suite) :: TestEvents.py
UNEXPECTED SUCCESS: LLDB (suite) :: TestMiBreak.py
UNEXPECTED SUCCESS: LLDB (suite) :: TestMiGdbSetShow.py
UNEXPECTED SUCCESS: LLDB (suite) :: TestMiInterpreterExec.py
UNEXPECTED SUCCESS: LLDB (suite) :: TestMiSyntax.py


*cmake/ninja/gcc-4.9.2:*

395 out of 395 test suites processed - TestMultithreaded.py
Ran 395 test suites (1 failed) (0.253165%)
Ran 457 test cases (1 failed) (0.218818%)
Failing Tests (1)
FAIL: LLDB (suite) :: TestRegisterVariables.py

Unexpected Successes (6)
UNEXPECTED SUCCESS: LLDB (suite) :: TestDataFormatterSynth.py
UNEXPECTED SUCCESS: LLDB (suite) :: TestMiBreak.py
UNEXPECTED SUCCESS: LLDB (suite) :: TestMiGdbSetShow.py
UNEXPECTED SUCCESS: LLDB (suite) :: TestMiInterpreterExec.py
UNEXPECTED SUCCESS: LLDB (suite) :: TestMiSyntax.py
UNEXPECTED SUCCESS: LLDB (suite) :: TestRaise.py


I will look into those.  I suspect some of them are compiler-version
specific, much like some of the OS X ones I dug into earlier.
-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] e not working when debugging llvm pass

2015-09-14 Thread Greg Clayton via lldb-dev 

> On Sep 13, 2015, at 4:26 PM, carr27 via lldb-dev  
> wrote:
> 
> Hello,
> 
> I'm working on an LLVM pass that I'm trying to debug it with LLDB, but I'm 
> running into a few problems.  I'm generally following this turtorial [1] but 
> I run my pass with opt instead from inside clang. So I run:
> 
> $ lldb ../build/bin/opt
> (lldb) break set --name MyPass::runOnModule
> (lldb) run -load ../build/lib/LLVMMyPass.so -MyPass test.ll
> 
> My runOnModule is just:
> 
> bool MyPass::runOnModule(Module &M) {
> for (auto& F : M) {
>for (auto& BB : F) {
>  for (auto& I : BB) {
>I.dump(); // step to here
>  }
>}
>  }
> }
> 
> It hits the breakpoint correctly then I single step into the inner most loop. 
>  Then I try the following LLDB commands:
> 
> "e I.dump()" gives me what I expect (it prints the LLVM instruction).
> 
> "e BB.dump()" gives me:
> error: no member named 'dump' in 'llvm::BasicBlock'
> error: 1 errors parsing expression
> 
> ...but llvm::BasicBlock definitely does have a member named dump.
> 

We would need to look at what LLDB thinks the llvm::BasicBlock type looks like. 
What does LLDB say in response to:

(lldb) image lookup -t llvm::BasicBlock

You may be running into a case where the debug info only has a forward 
declaration to llvm::BasicBlock... Let me know what the output of the above 
command looks like. The other thing is there is a lot of space savings that get 
enabled by default that omits important debug info where definitions of classes 
will be omitted from the debug info if they aren't directly used in the current 
source files. So it also depends on the debug info. If you have an ELF file for 
clang that you can make available, I can take a look and see what I can see.


> "e M.dump()" gives me:
> lldb: 
> /home/carr27/dataconf-workspace2/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:2883:
>  const clang::ASTRecordLayout &clang::ASTContext::getASTRecordLayout(const 
> clang::RecordDecl *) const: Assertion `D && "Cannot get layout of forward 
> declarations!"' failed.
> ./lldb.sh: line 1:  6736 Aborted (core dumped)

Sounds like we are trying to complete a forward declaration and things go bad. 
One of the drawbacks in llvm and clang and that the library likes to assert 
when it is unhappy. This is fine for development, but when you ship a debugger 
that uses clang, we don't want it asserting and killing the debugger. 
> 
> I don't know exactly what is going on, but it seems like LLDB doesn't know 
> about some of the LLVM classes.  Can anyone give me a pointer as to what 
> might be wrong?  

A few things can be going on:
1 - You are using the 3.6 release which is not good enough for debugging on 
linux. You will need to use the 3.7 release or preferably the top of tree SVN 
for llvm/clang/LLDB.
2 - The compiler that is compiling llvm/clang is pulling tricks and not 
emitting all of the debug info you need. clang has many optimizations that try 
to limit the amount of debug info that it emits and it often will omit base 
class definitions and many other things. There is an option that you can modify 
your build to pass if you are building with clang: -fstandalone-debug. This 
will ensure that debug info isn't emitted partially when it would affect the 
ability of a debugger to reconstruct a type from the debug info.

Let me know what your "llvm::BasicBlock" looks like and which of the above 
cases you think you might be running into.

Greg
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] 7th build slot?

2015-09-14 Thread Todd Fiala via lldb-dev 
Hi Chaoren,

While looking at the Ubuntu 14.04 x86_64 build bot, I was looking at the
test configurations for the test slots.  6 of them are described in the
build summary on the upper right

 There
is a 7th and 8th test slot that are not described --- what happens in those
slots?  Are they just unconfigured and thus not used?

Thanks!

-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] 7th build slot?

2015-09-14 Thread Chaoren Lin via lldb-dev 
We gave each bot 8 slots due to some limitation with the build master.
Slots 1-6 will notify us of failures, and slots 7-8 are sort of reserved
for tests/builds that are expected to be broken. Ying can provide more
details.

On Mon, Sep 14, 2015 at 10:12 PM, Todd Fiala  wrote:

> Hi Chaoren,
>
> While looking at the Ubuntu 14.04 x86_64 build bot, I was looking at the
> test configurations for the test slots.  6 of them are described in the
> build summary on the upper right
> 
>   There
> is a 7th and 8th test slot that are not described --- what happens in those
> slots?  Are they just unconfigured and thus not used?
>
> Thanks!
>
> -Todd
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] 7th build slot?

2015-09-14 Thread Todd Fiala via lldb-dev 
Okay, thanks.

It would be awesome if the summary listed the specific versions of clang
being used.  TOT is obvious, but "clang" being 3.5 is less so.

Seeing as clang behavior can change between releases, perhaps we can use
the other slots for other clang versions?

TOT clearly makes sense if more than one is being done. But if 4 slots
could be dedicated to clang, it seems like:
TOT (latest, 3.8 now)
TOT - 1 (3.7)
TOT - 2 (3.6)
TOT - 3 (3.5)

Or perhaps:
TOT (latest, 3.8)
TOT - 1 (3.7)
TOT - 2 (3.6)
TOT - *HISTORICALLY INTERESTING CLANG* (perhaps 3.4, 3.2, 3.0, whatever).

Just some thoughts.  Nice that the tests run so fast.  I've only got them
running in 2.5 minutes here, looks like your build bot does it in 1.5 :-)

-Todd

On Mon, Sep 14, 2015 at 10:49 PM, Chaoren Lin  wrote:

> We gave each bot 8 slots due to some limitation with the build master.
> Slots 1-6 will notify us of failures, and slots 7-8 are sort of reserved
> for tests/builds that are expected to be broken. Ying can provide more
> details.
>
> On Mon, Sep 14, 2015 at 10:12 PM, Todd Fiala  wrote:
>
>> Hi Chaoren,
>>
>> While looking at the Ubuntu 14.04 x86_64 build bot, I was looking at the
>> test configurations for the test slots.  6 of them are described in the
>> build summary on the upper right
>> 
>>   There
>> is a 7th and 8th test slot that are not described --- what happens in those
>> slots?  Are they just unconfigured and thus not used?
>>
>> Thanks!
>>
>> -Todd
>>
>
>


-- 
-Todd
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev