Re: [lldb-dev] lldb status at windows

[Nico Weber via lldb-dev]

On Fri, Jan 22, 2016 at 3:30 PM, Zachary Turner via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Under llvm/tools also checkout lld.  So your directories should look like
> this:
>
> llvm
> \-- tools
> \-- clang
> \-- lldb
> \-- lld
>
> Then re-run cmake to generate build files again, recompile, and then it
> should work.  Right now the problem is that lld-link.exe hasn't been
> compiled yet.
>

(Note that in my experience, cmake won't discover when new subprojects are
checked out unless you use a new build directory -- it seems to cache too
aggressively.)


>
> On Fri, Jan 22, 2016 at 12:22 PM Red Skotina 
> wrote:
>
>> yes, i miss it. but anyway dont work
>>
>>
>> d:\code\Unity_Unpacker\tests\test2>clang -v -fuse-ld=lld main.cpp
>> clang version 3.9.0 (trunk 258509)
>> Target: i686-pc-windows-msvc
>> Thread model: posix
>> InstalledDir: d:\code\llvm\build\bin
>>  "d:\\code\\llvm\\build\\bin\\clang.exe" -cc1 -triple
>> i686-pc-windows-msvc18.0.0
>>  -emit-obj -mrelax-all -mincremental-linker-compatible -disable-free
>> -disable-ll
>> vm-verifier -main-file-name main.cpp -mrelocation-model static
>> -mthread-model po
>> six -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
>> -target-c
>> pu pentium4 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir
>> "d:\\code\\
>> llvm\\build\\bin\\..\\lib\\clang\\3.9.0" -internal-isystem
>> "d:\\code\\llvm\\buil
>> d\\bin\\..\\lib\\clang\\3.9.0\\include" -internal-isystem "C:\\Program
>> Files (x8
>> 6)\\Microsoft Visual Studio 14.0\\VC\\INCLUDE" -internal-isystem
>> "C:\\Program Fi
>> les (x86)\\Microsoft Visual Studio 14.0\\VC\\ATLMFC\\INCLUDE"
>> -internal-isystem
>> "C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.10240.0\\ucrt"
>> -intern
>> al-isystem "C:\\Program Files (x86)\\Windows
>> Kits\\NETFXSDK\\4.6.1\\include\\um"
>>  -internal-isystem "C:\\Program Files (x86)\\Windows
>> Kits\\8.1\\includeshare
>> d" -internal-isystem "C:\\Program Files (x86)\\Windows
>> Kits\\8.1\\includeum"
>>  -internal-isystem "C:\\Program Files (x86)\\Windows
>> Kits\\8.1\\includewinrt
>> " -fdeprecated-macro -fdebug-compilation-dir
>> "d:\\code\\Unity_Unpacker\\tests\\t
>> est2" -ferror-limit 19 -fmessage-length 80 -fms-extensions
>> -fms-compatibility -f
>> ms-compatibility-version=18 -std=c++11 -fno-threadsafe-statics
>> -fdelayed-templat
>> e-parsing -fobjc-runtime=gcc -fdiagnostics-show-option
>> -fcolor-diagnostics -o "C
>> :\\Users\\Red\\AppData\\Local\\Temp\\main-71fc84.o" -x c++ main.cpp
>> clang -cc1 version 3.9.0 based upon LLVM 3.9.0svn default target
>> i686-pc-windows
>> -msvc
>> #include "..." search starts here:
>> #include <...> search starts here:
>>  d:\code\llvm\build\bin\..\lib\clang\3.9.0\include
>>  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE
>>  C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE
>>  C:\Program Files (x86)\Windows Kits\10\include\10.0.10240.0\ucrt
>>  C:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um
>>  C:\Program Files (x86)\Windows Kits\8.1\include\\shared
>>  C:\Program Files (x86)\Windows Kits\8.1\include\\um
>>  C:\Program Files (x86)\Windows Kits\8.1\include\\winrt
>> End of search list.
>>  "d:\\code\\llvm\\build\\bin\\lld-link.exe" -out:a.exe -defaultlib:libcmt
>> -nolog
>> o "C:\\Users\\Red\\AppData\\Local\\Temp\\main-71fc84.o"
>>
>> d:\code\Unity_Unpacker\tests\test2>lldb a.exe
>> (lldb) target create "a.exe"
>> Current executable set to 'a.exe' (i686).
>> (lldb) run
>>
>> Process 6448 launching
>>
>> --
>> process hang
>>
>> 2016-01-22 22:13 GMT+03:00 Zachary Turner :
>>
>>> When you compile, you need to use -fuse-ld=lld.  Most people miss this
>>> step.
>>>
>>> That said, it's not supposed to hang, but it is supposed to not work.
>>>
>>> What's the command line you used with clang?
>>>
>>> On Fri, Jan 22, 2016 at 11:08 AM Red Skotina 
>>> wrote:
>>>
 Look like I miss something , but i cant debug simple program program
 compiled with clang from trunk (258016), msvc 2015 stdlib, from vs2015 x86
 developer console .
  i use lldb from trunk
 #include "stdio.h"

 int main(int argc, char **argv)
 {
 printf("hello1\n");
 printf("hello2\n");
 return 0;
 }

 d:\code\tests\test2>lldb a.exe
 (lldb) target create "a.exe"
 Current executable set to 'a.exe' (i686).
 (lldb) run

 Process 6264 launching

 ---
 a.exe and lldb hangs

 What i doing wrong ?


 2016-01-08 0:42 GMT+03:00 Red Skotina :

> Nice to hear. I should answer after some time of using
>
> 2016-01-07 21:04 GMT+03:00 Zachary Turner :
>
>> Feel free to file bugs or post your feedback here after you use about
>> what worked, what didn't 

Re: [lldb-dev] clang-format now supports return type on separate line

[Sean Callanan via lldb-dev]

Wow, that’s a super handy feature and probably goes a long way toward 
alleviating concerns about tables.
I have to say, I always feel good vibes about a source base when they have lint 
directives in comments.  Shows they run lint as a matter of course.

Sean
 
> On Jan 22, 2016, at 12:29 PM, Pavel Labath via lldb-dev 
>  wrote:
> 
> Apparently, you can also disable the formatting of a piece of code by
> a magic comment. Could be quite useful for those tables. From the
> docs:
> -
> Clang-format understands also special comments that switch formatting
> in a delimited range. The code between a comment // clang-format off
> or /* clang-format off */ up to a comment // clang-format on or /*
> clang-format on */ will not be formatted. The comments themselves will
> be formatted (aligned) normally.
> -
> 
> 
> On 22 January 2016 at 17:09, Todd Fiala via lldb-dev
>  wrote:
>> Okay, thanks for the tip!
>> 
>> On Fri, Jan 22, 2016 at 8:32 AM, Zachary Turner  wrote:
>>> 
>>> By the way, one place where you are guaranteed to get undesirable results
>>> is where you have a large array formatted so that the columns line up.  Like
>>> in our options tables in the CommandObjects.  If you're using git, one way
>>> to avoid having clang-format touch these files is to commit that file by
>>> itself, then run git clang-format (since it only looks at staged files),
>>> then git commit --amend.  But of course that will gloss over any other
>>> changes you made to the file as well.  But in any case, it's another trick
>>> I've found useful occasionally.
>>> 
>>> On Fri, Jan 22, 2016 at 7:09 AM Kate Stone 
>>> wrote:
 
 Agreed.  My guidance has been that we go ahead and require submitters to
 use clang-format for patches, but to acknowledge that there may be cases
 where this produces undesirable results.  Manual formatting to correct 
 these
 issues is acceptable and should lead to discussions about concrete examples
 where the automated approach is imperfect.
 
 Kate Stone k8st...@apple.com
  Xcode Runtime Analysis Tools
 
 On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev
  wrote:
 
 Okay, sounds like a reasonable thing to try.  We can always review it if
 it causes any real issues.
 
 On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner 
 wrote:
> 
> 
> 
> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan 
> wrote:
>> 
>> I tend to agree with Zachary on the overall principle – and I would be
>> willing to clang-format functions when I modify them.  I’m concerned 
>> about a
>> specific class of functions, though.  Let’s say I have a function that 
>> has
>> had lots of activity (I’m thinking of, for example, ParseType off in the
>> DWARF parser).  Unfortunately, such functions tend to be the ones that
>> benefit most from clang-format.
>> 
>> In such a function, there’s a lot of useful history available via svn
>> blame that helps when fixing bugs.  My concern is that if someone
>> clang-formats this function after applying the kth fix, suddenly I've 
>> lost
>> convenient access to that history.  It’s only available with a fair 
>> amount
>> of pain, and this pain increases as more fixes are applied because now I
>> need to interleave the info before and after reformatting.
>> 
>> Would it be reasonable to mark such functions as “Don’t clang-format”?
>> That could be also interpreted as a “// TODO add comments so what this 
>> does
>> is more understandable”
> 
> 
> Well again by default it's only going to format the code you touch in
> yoru diff plus 1 or 2 surrounding lines.  So having it format an entire
> function is something you would have to explicitly go out of your way to 
> do.
> So it's a judgement call.  If you think the function would be better off
> clang-formatting the entire thing, do that.  If you just want to format 
> the
> lines you're touching because you were in there anyway, that's the default
> behavior.
 
 
 
 
 --
 -Todd
 
 ___
 
 
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
>> 
>> 
>> 
>> --
>> -Todd
>> 
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>> 
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

___
lldb-dev mailing list
lldb-dev@lists.llvm.org

Re: [lldb-dev] clang-format now supports return type on separate line

[Zachary Turner via lldb-dev]

Oh neat, I didn't know about that.  I'll play around with that when I have
some time and see how the behavior works with respect to git clang-format
(which formats diffs instead of entire files)

On Fri, Jan 22, 2016 at 12:29 PM Pavel Labath  wrote:

> Apparently, you can also disable the formatting of a piece of code by
> a magic comment. Could be quite useful for those tables. From the
> docs:
> -
> Clang-format understands also special comments that switch formatting
> in a delimited range. The code between a comment // clang-format off
> or /* clang-format off */ up to a comment // clang-format on or /*
> clang-format on */ will not be formatted. The comments themselves will
> be formatted (aligned) normally.
> -
>
>
> On 22 January 2016 at 17:09, Todd Fiala via lldb-dev
>  wrote:
> > Okay, thanks for the tip!
> >
> > On Fri, Jan 22, 2016 at 8:32 AM, Zachary Turner 
> wrote:
> >>
> >> By the way, one place where you are guaranteed to get undesirable
> results
> >> is where you have a large array formatted so that the columns line up.
> Like
> >> in our options tables in the CommandObjects.  If you're using git, one
> way
> >> to avoid having clang-format touch these files is to commit that file by
> >> itself, then run git clang-format (since it only looks at staged files),
> >> then git commit --amend.  But of course that will gloss over any other
> >> changes you made to the file as well.  But in any case, it's another
> trick
> >> I've found useful occasionally.
> >>
> >> On Fri, Jan 22, 2016 at 7:09 AM Kate Stone 
> >> wrote:
> >>>
> >>> Agreed.  My guidance has been that we go ahead and require submitters
> to
> >>> use clang-format for patches, but to acknowledge that there may be
> cases
> >>> where this produces undesirable results.  Manual formatting to correct
> these
> >>> issues is acceptable and should lead to discussions about concrete
> examples
> >>> where the automated approach is imperfect.
> >>>
> >>> Kate Stone k8st...@apple.com
> >>>  Xcode Runtime Analysis Tools
> >>>
> >>> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev
> >>>  wrote:
> >>>
> >>> Okay, sounds like a reasonable thing to try.  We can always review it
> if
> >>> it causes any real issues.
> >>>
> >>> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner 
> >>> wrote:
> 
> 
> 
>  On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan 
>  wrote:
> >
> > I tend to agree with Zachary on the overall principle – and I would
> be
> > willing to clang-format functions when I modify them.  I’m concerned
> about a
> > specific class of functions, though.  Let’s say I have a function
> that has
> > had lots of activity (I’m thinking of, for example, ParseType off in
> the
> > DWARF parser).  Unfortunately, such functions tend to be the ones
> that
> > benefit most from clang-format.
> >
> > In such a function, there’s a lot of useful history available via svn
> > blame that helps when fixing bugs.  My concern is that if someone
> > clang-formats this function after applying the kth fix, suddenly
> I've lost
> > convenient access to that history.  It’s only available with a fair
> amount
> > of pain, and this pain increases as more fixes are applied because
> now I
> > need to interleave the info before and after reformatting.
> >
> > Would it be reasonable to mark such functions as “Don’t
> clang-format”?
> > That could be also interpreted as a “// TODO add comments so what
> this does
> > is more understandable”
> 
> 
>  Well again by default it's only going to format the code you touch in
>  yoru diff plus 1 or 2 surrounding lines.  So having it format an
> entire
>  function is something you would have to explicitly go out of your way
> to do.
>  So it's a judgement call.  If you think the function would be better
> off
>  clang-formatting the entire thing, do that.  If you just want to
> format the
>  lines you're touching because you were in there anyway, that's the
> default
>  behavior.
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> -Todd
> >>>
> >>> ___
> >>>
> >>>
> >>> lldb-dev mailing list
> >>> lldb-dev@lists.llvm.org
> >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> >
> >
> > --
> > -Todd
> >
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] clang-format now supports return type on separate line

[Pavel Labath via lldb-dev]

Apparently, you can also disable the formatting of a piece of code by
a magic comment. Could be quite useful for those tables. From the
docs:
-
Clang-format understands also special comments that switch formatting
in a delimited range. The code between a comment // clang-format off
or /* clang-format off */ up to a comment // clang-format on or /*
clang-format on */ will not be formatted. The comments themselves will
be formatted (aligned) normally.
-


On 22 January 2016 at 17:09, Todd Fiala via lldb-dev
 wrote:
> Okay, thanks for the tip!
>
> On Fri, Jan 22, 2016 at 8:32 AM, Zachary Turner  wrote:
>>
>> By the way, one place where you are guaranteed to get undesirable results
>> is where you have a large array formatted so that the columns line up.  Like
>> in our options tables in the CommandObjects.  If you're using git, one way
>> to avoid having clang-format touch these files is to commit that file by
>> itself, then run git clang-format (since it only looks at staged files),
>> then git commit --amend.  But of course that will gloss over any other
>> changes you made to the file as well.  But in any case, it's another trick
>> I've found useful occasionally.
>>
>> On Fri, Jan 22, 2016 at 7:09 AM Kate Stone 
>> wrote:
>>>
>>> Agreed.  My guidance has been that we go ahead and require submitters to
>>> use clang-format for patches, but to acknowledge that there may be cases
>>> where this produces undesirable results.  Manual formatting to correct these
>>> issues is acceptable and should lead to discussions about concrete examples
>>> where the automated approach is imperfect.
>>>
>>> Kate Stone k8st...@apple.com
>>>  Xcode Runtime Analysis Tools
>>>
>>> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev
>>>  wrote:
>>>
>>> Okay, sounds like a reasonable thing to try.  We can always review it if
>>> it causes any real issues.
>>>
>>> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner 
>>> wrote:



 On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan 
 wrote:
>
> I tend to agree with Zachary on the overall principle – and I would be
> willing to clang-format functions when I modify them.  I’m concerned 
> about a
> specific class of functions, though.  Let’s say I have a function that has
> had lots of activity (I’m thinking of, for example, ParseType off in the
> DWARF parser).  Unfortunately, such functions tend to be the ones that
> benefit most from clang-format.
>
> In such a function, there’s a lot of useful history available via svn
> blame that helps when fixing bugs.  My concern is that if someone
> clang-formats this function after applying the kth fix, suddenly I've lost
> convenient access to that history.  It’s only available with a fair amount
> of pain, and this pain increases as more fixes are applied because now I
> need to interleave the info before and after reformatting.
>
> Would it be reasonable to mark such functions as “Don’t clang-format”?
> That could be also interpreted as a “// TODO add comments so what this 
> does
> is more understandable”


 Well again by default it's only going to format the code you touch in
 yoru diff plus 1 or 2 surrounding lines.  So having it format an entire
 function is something you would have to explicitly go out of your way to 
 do.
 So it's a judgement call.  If you think the function would be better off
 clang-formatting the entire thing, do that.  If you just want to format the
 lines you're touching because you were in there anyway, that's the default
 behavior.
>>>
>>>
>>>
>>>
>>> --
>>> -Todd
>>>
>>> ___
>>>
>>>
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>
>
> --
> -Todd
>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] lldb status at windows

[Red Skotina via lldb-dev]

Look like I miss something , but i cant debug simple program program
compiled with clang from trunk (258016), msvc 2015 stdlib, from vs2015 x86
developer console .
 i use lldb from trunk
#include "stdio.h"

int main(int argc, char **argv)
{
printf("hello1\n");
printf("hello2\n");
return 0;
}

d:\code\tests\test2>lldb a.exe
(lldb) target create "a.exe"
Current executable set to 'a.exe' (i686).
(lldb) run

Process 6264 launching

---
a.exe and lldb hangs

What i doing wrong ?


2016-01-08 0:42 GMT+03:00 Red Skotina :

> Nice to hear. I should answer after some time of using
>
> 2016-01-07 21:04 GMT+03:00 Zachary Turner :
>
>> Feel free to file bugs or post your feedback here after you use about
>> what worked, what didn't work, what's missing, etc.  Anything that doesn't
>> work is a bug that I would like to fix.
>>
>> On Thu, Jan 7, 2016 at 10:02 AM Zachary Turner 
>> wrote:
>>
>>> Hi, I guess I should make a new blog post at some point, or post status
>>> on the website.  Here's my best estimate at what you can expect.
>>>
>>> * Most common debugging scenarios should work.  Run under debugger,
>>> attach to process, interrupt, continue, print variable values, evaluate
>>> expressions, etc.
>>> * Step-over might be unstable in certain scenarios
>>> * Conditional breakpoints don't work
>>> * Hardware watchpoints don't work
>>> * Expression evaluation might not work in some advanced cases.
>>>
>>> The main big feature that has been added since the original blog post is
>>> support for windows minidump files.  So you can create a minidump of a
>>> stopped process from inside LLDB, and you can load up a minidump and do
>>> post-mortem debugging.
>>>
>>> On Wed, Jan 6, 2016 at 10:39 PM Red Skotina via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
 Where can i look lldb status for native debug at Windows?
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org
 http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] Ubuntu version-based fail/skip

[Todd Fiala via lldb-dev]

Hey all,

What do you think about having some kind of way of marking the (in this
case, specifically) Ubuntu distribution for fail/skip test decorators?
I've had a few cases where I've needed to mark tests failing on for Ubuntu
where it really was only a particular release of an Ubuntu distribution,
and wasn't specifically the compiler.  (i.e. it was a constellation of more
moving parts that clearly occur on a particular release of an Ubuntu
distribution but not on others, and certainly not generically across all
Linux distributions).

I'd love to have a way to skip and xfail a test for a specific Ubuntu
distribution release.  I guess it could be done uber-genrically, but with
Linux distributions this can get complicated due to the os/distribution
axes.  So I'd be happy to start off with just having them at a distribution
basis:

@skipIfUbuntu(version_check_list)  # version_check_list contains one or
more version checks that, if passing, trigger the skip

@expectedFailureUbuntu(version_check_list)  # similar to above

Or possibly more usefully,

@skipIfLinuxDistribution(version_check_list)  # version_check_list contains
one or more version checks that, if passing, trigger the skip, includes the
distribution

@expectedFailureLinuxDistribution(version_check_list)  # similar to above


It's not clear to me how to work in the os=linux, distribution=Ubuntu into
the more generic checks like and get distribution-level version checking
working right otherwise, but I'm open to suggestions.

The workaround for the short term is to just use blanket-linux @skipIf and
@expectedFailure style calls.

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

Re: [lldb-dev] lldb status at windows

[Zachary Turner via lldb-dev]

When you compile, you need to use -fuse-ld=lld.  Most people miss this step.

That said, it's not supposed to hang, but it is supposed to not work.

What's the command line you used with clang?

On Fri, Jan 22, 2016 at 11:08 AM Red Skotina  wrote:

> Look like I miss something , but i cant debug simple program program
> compiled with clang from trunk (258016), msvc 2015 stdlib, from vs2015 x86
> developer console .
>  i use lldb from trunk
> #include "stdio.h"
>
> int main(int argc, char **argv)
> {
> printf("hello1\n");
> printf("hello2\n");
> return 0;
> }
>
> d:\code\tests\test2>lldb a.exe
> (lldb) target create "a.exe"
> Current executable set to 'a.exe' (i686).
> (lldb) run
>
> Process 6264 launching
>
> ---
> a.exe and lldb hangs
>
> What i doing wrong ?
>
>
> 2016-01-08 0:42 GMT+03:00 Red Skotina :
>
>> Nice to hear. I should answer after some time of using
>>
>> 2016-01-07 21:04 GMT+03:00 Zachary Turner :
>>
>>> Feel free to file bugs or post your feedback here after you use about
>>> what worked, what didn't work, what's missing, etc.  Anything that doesn't
>>> work is a bug that I would like to fix.
>>>
>>> On Thu, Jan 7, 2016 at 10:02 AM Zachary Turner 
>>> wrote:
>>>
 Hi, I guess I should make a new blog post at some point, or post status
 on the website.  Here's my best estimate at what you can expect.

 * Most common debugging scenarios should work.  Run under debugger,
 attach to process, interrupt, continue, print variable values, evaluate
 expressions, etc.
 * Step-over might be unstable in certain scenarios
 * Conditional breakpoints don't work
 * Hardware watchpoints don't work
 * Expression evaluation might not work in some advanced cases.

 The main big feature that has been added since the original blog post
 is support for windows minidump files.  So you can create a minidump of a
 stopped process from inside LLDB, and you can load up a minidump and do
 post-mortem debugging.

 On Wed, Jan 6, 2016 at 10:39 PM Red Skotina via lldb-dev <
 lldb-dev@lists.llvm.org> wrote:

> Where can i look lldb status for native debug at Windows?
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>

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

Re: [lldb-dev] [3.8 Release] Schedule and call for testers

[Hans Wennborg via lldb-dev]

On Fri, Dec 11, 2015 at 3:14 PM, Hans Wennborg  wrote:
> It's not quite time to start the 3.8 release process, but it's time to
> start planning.
>
> Please let me know if you want to help with testing and building
> release binaries for your favourite platform. (If you were a tester on
> the previous release, you're cc'd on this email.)

I just realized no one actually signed up for testing and packaging on
Darwin. Any takers?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] CFP for the 6th European LLVM conference on March 17-18, 2016 in Barcelona, Spain

[Arnaud Allard de Grandmaison via lldb-dev]

Reminder: the deadline for submitting papers for the EuroLLVM is Monday.

Kind regards,
--
Arnaud


On Sun, Dec 13, 2015 at 10:42 PM, Arnaud Allard de Grandmaison <
arnaud.ad...@gmail.com> wrote:

> We are pleased to announce the 6th European LLVM conference on March
> 17-18, 2016 in Barcelona, Spain.
>
> This will be a full two-day conference which aims to present the latest
> developments around LLVM and help strengthen the network of LLVM developers
> and users. The format will be similar to that of the previous meetings,
> with ample time for presentations, discussion, and networking between
> participants. The meeting is open to anyone whether from industry or
> academia, professional or enthusiast and is not restricted to those from
> Europe - attendees from all regions are welcome !
>
> EuroLLVM 2016 will be held at Princesa Sofia Hotel (
> http://www.princesasofia.com/en), collocated with the International
> Compiler Construction conference (http://cc2016.eew.technion.ac.il/) and
> CGO (http://cgo.org/cgo2016/)
>
> We invite academic, industrial and hobbyist speakers to present their work
> on developing or using LLVM, Clang, etc. Proposals for technical
> presentations, posters, workshops, demonstrations and BoFs are welcome.
> Material will be chosen to cover a broad spectrum of themes and topics at
> various depths, some technical deep-diving, some more community focused.
>
> We are looking for:
> - Keynote speakers.
> - Technical presentations (30 minutes plus questions and discussion)
> related to the development of LLVM, Clang, LLD, LLDB, Polly, ...
> - Presentations relating to academic or commercial use of LLVM, Clang
> etc.
> - Lightning talks (5 minutes, no questions, no discussion).
> - Workshops and in-depth tutorials (1-2 hours - please specify in your
> submission).
> - Poster presentations.
> - Birds of a Feather sessions (BoFs).
>
> **Important dates**
> The deadline for receiving submissions is January 25, 2016.
> Speakers will be notified of acceptance or rejection by February 15th,
> 2016.
>
> **Submissions**
> Submissions should be done using the Easychair platform:
> - https://easychair.org/conferences/?conf=eurollvm2016
>
> Please note that presentation materials and videos for the technical
> sessions will be posted on llvm.org after the conference. We have
> reserved additional spots for speakers, such that they can attend the
> conference even though we have reached our registration limit.
>
> In terms of submission style, we are looking for:
> - A title and an extended abstract,
> OR
> - A title, abstract and slides.
>
> Please make clear the status of the slides (are they a skeleton of your
> presentation with the detail missing ?), or, perhaps a section of detail
> that lacks introduction and conclusions?  Also make sure to give enough
> information in the extended abstract: the more you can give us and tell us
> the easier it will be for us to be positive about your submission.
>
> Proposals that are not sufficiently detailed (talks lacking a
> comprehensive abstract for example) are likely to be rejected. Slides and
> posters must be in PDF format.
>
> **About LLVM**
> The LLVM Infrastructure is a collection of libraries and tools that make
> it easy to build compilers, optimizers, Just-In-Time code generators, and
> many other compiler-related programs.  LLVM uses a single,
> language-independent virtual instruction set both as an offline code
> representation (to communicate code between compiler phases and to run-time
> systems) and as the compiler internal representation (to analyse and
> transform programs).
>
> This persistent code representation allows a common set of sophisticated
> compiler techniques to be applied at compile-time, link-time, install-time,
> run-time, or "idle-time" (between program runs). The strengths of the LLVM
> infrastructure are its extremely simple design (which makes it easy to
> understand and use), source-language independence, powerful mid-level
> optimizer, automated compiler debugging support, extensibility, and its
> stability and reliability.
>
> LLVM is currently being used to host a wide variety of Academic Research
> projects and commercial projects.
>
> For more information, please visit:
> - http://llvm.org/devmtg/2016-03/
>
> We are looking forward to seeing you in Barcelona !
> --
> Arnaud A. de Grandmaison
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 26261] New: gtest failure in PythonDataObjectsTest.TestPythonBytes on OS X 10.11

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26261

Bug ID: 26261
   Summary: gtest failure in PythonDataObjectsTest.TestPythonBytes
on OS X 10.11
   Product: lldb
   Version: unspecified
  Hardware: Macintosh
OS: MacOS X
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: todd.fi...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

[ RUN  ] PythonDataObjectsTest.TestPythonBytes
/Users/tfiala/lldb/tot/git-svn/lldb/unittests/ScriptInterpreter/Python/PythonDataObjectsTests.cpp:212:
Failure
Value of: python_bytes.GetObjectType()
  Actual: 4-byte object <05-00 00-00>
Expected: PyObjectType::Bytes
Which is: 4-byte object <06-00 00-00>

This test is causing the gtest run to fail.

I'll need to disable it on OS X as soon as I get the OS X Green Dragon buildbot
to run (instead of just build) the lldb-gtest target.  (I just discovered it
was only building and not running it while investigating this).

-- 
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 26265] New: [Windows] Evaluating arguments gives incorrect values except for frame 0

[via lldb-dev]

https://llvm.org/bugs/show_bug.cgi?id=26265

Bug ID: 26265
   Summary: [Windows] Evaluating arguments gives incorrect values
except for frame 0
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: Windows NT
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: amcca...@google.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

TextConditionalBreak.py fails on Windows when trying to evaluate a function
argument in frame 1.

Manual experiments indicates this is problem for arguments in any frame other
than frame 0.  This is observable in expression and backtraces.

(lldb) thread backtrace
* thread #1: tid = 0x1144, 0x0112b08a a.out`c(val=3) + 10 at main.c:39, stop
reason = breakpoint 2.1
  * frame #0: 0x0112b08a a.out`c(val=3) + 10 at main.c:39
frame #1: 0x0112b03e a.out`a(val=4586500) + 62 at main.c:27
frame #2: 0x0112b12b a.out`main(argc=0, argv=0x0045fc04) + 139 at main.c:50
frame #3: 0x0112b88f a.out`$LN27 + 224

Note that the correct value for val in frame #0 is correct (3), but incorrect
in frame #1.

(lldb) thread step-out
(lldb) Process 9808 stopped
* thread #1: tid = 0x1144, 0x0112b03e a.out`a(val=3) + 62 at main.c:27, stop
reason = step out
frame #0: 0x0112b03e a.out`a(val=3) + 62 at main.c:27
   24   if (val <= 1)
   25   return b(val);
   26   else if (val >= 3)
-> 27   return c(val); // Find the line number where c's parent frame
is a here.
   28
   29   return val;
   30   }
thread back
* thread #1: tid = 0x1144, 0x0112b03e a.out`a(val=3) + 62 at main.c:27, stop
reason = step out
  * frame #0: 0x0112b03e a.out`a(val=3) + 62 at main.c:27
frame #1: 0x0112b12b a.out`main(argc=3, argv=0x0003) + 139 at main.c:50
frame #2: 0x0112b88f a.out`$LN27 + 224

After stepping back out to what was frame #1, and val is now correctly shown.

-- 
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] LLDB OS X buildbot/testbot details

[Todd Fiala via lldb-dev]

Hi all,

The llvm.org Green Dragon (i.e. Jenkins-based) LLDB OS X buildbot/testbot
has received some improvements today.  The Jenkins build now uses the xUnit
plugin to process xUnit-based test suite results, which are displayed more
usefully on the "build and test" page here
.

A few notes on some relevant details:

* The summary page allows you to click the test details and see the
pass/fail and timing info for each of the tests

* If the test is in failure/error, the backtrace will show up in the
details for the test method when you drill through the test results.

* The test summary information that you would normally see in the output of
a local test run is available in the bottom of the "Console Output" page
for a given build.  This can be useful  as xUnit/JUnit only really has the
concept of a pass/fail/error, but we also have timeouts, unexpected
successes, exceptional exits, etc. that all have to get mapped to the JUnit
pass/fail/error model.  The JUnit test method run details try to capture
this, but I find it useful from time to time to go to the consule output to
see the "real" results.  (Rerun info is only available on the Console
Output).

* The Jenkins jobs are set up in a 2-level job/sub-job structure.  The link
I sent above is the most useful one to look at because it does the build
and test phase, and that covers 95% of what you want to look at.  BUT, if
you want to check what code is actually contained in the build and test
run, you need to go to the parent job (will be listed under here
, which lists the main job), then
find its first sub-job called "Acquire Sources".  That will tell you which
changes were synched for this job.  (I may do something about this in the
future since the workflow on this seems suboptimal, but this is how it is
right now and is similar for other LLVM projects on Jenkins).

* Right now the gtests are built, but not run.  I'll be addressing this as
soon as Zachary and I straighten out a failing gtest on OS X.  Those test
results will just show up in the Console Output for the build and test
phase, and will fail the build if they either fail to build or have a test
run failure.

* Currently the equivalent of the python test session directory is not
collected and archived.  I plan to remedy that in the future.  I currently
*do* archive the JUnit.xml output file from the XunitResultsFormatter
output.

Let me know if you have any questions or feedback.

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

Re: [lldb-dev] clang-format now supports return type on separate line

[Todd Fiala via lldb-dev]

Okay, thanks for the tip!

On Fri, Jan 22, 2016 at 8:32 AM, Zachary Turner  wrote:

> By the way, one place where you are guaranteed to get undesirable results
> is where you have a large array formatted so that the columns line up.
> Like in our options tables in the CommandObjects.  If you're using git, one
> way to avoid having clang-format touch these files is to commit that file
> by itself, then run git clang-format (since it only looks at staged files),
> then git commit --amend.  But of course that will gloss over any other
> changes you made to the file as well.  But in any case, it's another trick
> I've found useful occasionally.
>
> On Fri, Jan 22, 2016 at 7:09 AM Kate Stone 
> wrote:
>
>> Agreed.  My guidance has been that we go ahead and require submitters to
>> use clang-format for patches, but to acknowledge that there may be cases
>> where this produces undesirable results.  Manual formatting to correct
>> these issues is acceptable and should lead to discussions about concrete
>> examples where the automated approach is imperfect.
>>
>> Kate Stone k8st...@apple.com
>>  Xcode Runtime Analysis Tools
>>
>> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Okay, sounds like a reasonable thing to try.  We can always review it if
>> it causes any real issues.
>>
>> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner 
>> wrote:
>>
>>>
>>>
>>> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan 
>>> wrote:
>>>
 I tend to agree with Zachary on the overall principle – and I would be
 willing to clang-format functions when I modify them.  I’m concerned about
 a specific class of functions, though.  Let’s say I have a function that
 has had lots of activity (I’m thinking of, for example, ParseType off in
 the DWARF parser).  Unfortunately, such functions tend to be the ones that
 benefit most from clang-format.

 In such a function, there’s a lot of useful history available via svn
 blame that helps when fixing bugs.  My concern is that if someone
 clang-formats this function after applying the *k*th fix, suddenly
 I've lost convenient access to that history.  It’s only available with a
 fair amount of pain, and this pain increases as more fixes are applied
 because now I need to interleave the info before and after reformatting.

 Would it be reasonable to mark such functions as “Don’t clang-format”?
 That could be also interpreted as a “// TODO add comments so what this does
 is more understandable”

>>>
>>> Well again by default it's only going to format the code you touch in
>>> yoru diff plus 1 or 2 surrounding lines.  So having it format an entire
>>> function is something you would have to explicitly go out of your way to
>>> do.  So it's a judgement call.  If you think the function would be better
>>> off clang-formatting the entire thing, do that.  If you just want to format
>>> the lines you're touching because you were in there anyway, that's the
>>> default behavior.
>>>
>>
>>
>>
>> --
>> -Todd
>>
>> ___
>>
>>
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>


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

Re: [lldb-dev] clang-format now supports return type on separate line

[Kate Stone via lldb-dev]

Agreed.  My guidance has been that we go ahead and require submitters to use 
clang-format for patches, but to acknowledge that there may be cases where this 
produces undesirable results.  Manual formatting to correct these issues is 
acceptable and should lead to discussions about concrete examples where the 
automated approach is imperfect.

Kate Stone k8st...@apple.com
 Xcode Runtime Analysis Tools

> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev 
>  wrote:
> 
> Okay, sounds like a reasonable thing to try.  We can always review it if it 
> causes any real issues.
> 
>> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner  wrote:
>> 
>> 
>>> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan  wrote:
>>> I tend to agree with Zachary on the overall principle – and I would be 
>>> willing to clang-format functions when I modify them.  I’m concerned about 
>>> a specific class of functions, though.  Let’s say I have a function that 
>>> has had lots of activity (I’m thinking of, for example, ParseType off in 
>>> the DWARF parser).  Unfortunately, such functions tend to be the ones that 
>>> benefit most from clang-format.
>>> 
>>> In such a function, there’s a lot of useful history available via svn blame 
>>> that helps when fixing bugs.  My concern is that if someone clang-formats 
>>> this function after applying the kth fix, suddenly I've lost convenient 
>>> access to that history.  It’s only available with a fair amount of pain, 
>>> and this pain increases as more fixes are applied because now I need to 
>>> interleave the info before and after reformatting.
>>> 
>>> Would it be reasonable to mark such functions as “Don’t clang-format”?  
>>> That could be also interpreted as a “// TODO add comments so what this does 
>>> is more understandable”
>> 
>> Well again by default it's only going to format the code you touch in yoru 
>> diff plus 1 or 2 surrounding lines.  So having it format an entire function 
>> is something you would have to explicitly go out of your way to do.  So it's 
>> a judgement call.  If you think the function would be better off 
>> clang-formatting the entire thing, do that.  If you just want to format the 
>> lines you're touching because you were in there anyway, that's the default 
>> behavior. 
> 
> 
> 
> -- 
> -Todd
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] clang-format now supports return type on separate line

[Zachary Turner via lldb-dev]

By the way, one place where you are guaranteed to get undesirable results
is where you have a large array formatted so that the columns line up.
Like in our options tables in the CommandObjects.  If you're using git, one
way to avoid having clang-format touch these files is to commit that file
by itself, then run git clang-format (since it only looks at staged files),
then git commit --amend.  But of course that will gloss over any other
changes you made to the file as well.  But in any case, it's another trick
I've found useful occasionally.

On Fri, Jan 22, 2016 at 7:09 AM Kate Stone 
wrote:

> Agreed.  My guidance has been that we go ahead and require submitters to
> use clang-format for patches, but to acknowledge that there may be cases
> where this produces undesirable results.  Manual formatting to correct
> these issues is acceptable and should lead to discussions about concrete
> examples where the automated approach is imperfect.
>
> Kate Stone k8st...@apple.com
>  Xcode Runtime Analysis Tools
>
> On Jan 21, 2016, at 9:46 PM, Todd Fiala via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Okay, sounds like a reasonable thing to try.  We can always review it if
> it causes any real issues.
>
> On Thu, Jan 21, 2016 at 11:34 AM, Zachary Turner 
> wrote:
>
>>
>>
>> On Thu, Jan 21, 2016 at 11:18 AM Sean Callanan 
>> wrote:
>>
>>> I tend to agree with Zachary on the overall principle – and I would be
>>> willing to clang-format functions when I modify them.  I’m concerned about
>>> a specific class of functions, though.  Let’s say I have a function that
>>> has had lots of activity (I’m thinking of, for example, ParseType off in
>>> the DWARF parser).  Unfortunately, such functions tend to be the ones that
>>> benefit most from clang-format.
>>>
>>> In such a function, there’s a lot of useful history available via svn
>>> blame that helps when fixing bugs.  My concern is that if someone
>>> clang-formats this function after applying the *k*th fix, suddenly I've
>>> lost convenient access to that history.  It’s only available with a fair
>>> amount of pain, and this pain increases as more fixes are applied because
>>> now I need to interleave the info before and after reformatting.
>>>
>>> Would it be reasonable to mark such functions as “Don’t clang-format”?
>>> That could be also interpreted as a “// TODO add comments so what this does
>>> is more understandable”
>>>
>>
>> Well again by default it's only going to format the code you touch in
>> yoru diff plus 1 or 2 surrounding lines.  So having it format an entire
>> function is something you would have to explicitly go out of your way to
>> do.  So it's a judgement call.  If you think the function would be better
>> off clang-formatting the entire thing, do that.  If you just want to format
>> the lines you're touching because you were in there anyway, that's the
>> default behavior.
>>
>
>
>
> --
> -Todd
>
> ___
>
>
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] LLDB test questions

[Todd Fiala via lldb-dev]

Hi Ted!

I hope you don't mind - I'm going to CC lldb-dev since there is some useful
general info in here for others who are getting started with the test
system.  (And others can fact-check anything I may gloss over here).

On Thu, Jan 21, 2016 at 2:00 PM, Ted Woodward 
wrote:

> Hi Todd,
>
>
>
> I’m working on getting the LLDB tests running with Hexagon, but I’m
> confused about some things. Here are my initial results:
>
> ===
>
> Test Result Summary
>
> ===
>
> Test Methods:967
>
> Reruns:2
>
> Success: 290
>
> Expected Failure: 25
>
> Failure:  89
>
> Error:   111
>
> Exceptional Exit: 13
>
> Unexpected Success:2
>
> Skip:434
>
> Timeout:   3
>
> Expected Timeout:  0
>
>
>
>
>
> First question – How can I tell what certain tests are doing?
>

There are two places you can look for more information.  Of those
categories that are counted, the following should list the specific tests
that are failing in a section called something like "Test Details" directly
above the "Test Result Summary" section:
* Failure
* Error
* Exceptional Exit
* Timeout

Those will tell you which test method names (and file path relative to the
packages/Python/lldbsuite/test directory).  You should also get a stack
trace above that section when it is counting out the tests that are running.

But, that's not really the heavy detail info.  The heavy details are in a
"test session directory", which by default is created in the current
directory when the test suite is kicked off, and has a name something like:

2016-01-21-15_14_26/

This is a date/time encoded directory with a bunch of files in it.  For
each of the classes of failure above, you should have a file that beings
with something like:

"Failure-"
"Error-"

(i.e. the status as the first part), followed by the test
package/class/name/architecture, then followed by .log.  That file records
build commands and any I/O from the process.  That is the best place to
look when a test goes wrong.

Here is an example failure filename from a test suite run I did on OS X
that failed recently:

Failure-TestPublicAPIHeaders.SBDirCheckerCase.test_sb_api_directory_dsym-x86_64-clang.log



> For example, TestExprPathSynthetic, from
> packages/Python/lldbsuite/test/python_api/exprpath_synthetic/TestExprPathSynthetic.py
> .
>
>
>
> TestExprPathSynthetic.py has:
>
> import lldbsuite.test.lldbinline as lldbinline
>
> import lldbsuite.test.lldbtest as lldbtest
>
>
>
> lldbinline.MakeInlineTest(__file__, globals(),
> [lldbtest.skipIfFreeBSD,lldbtest.
>
> skipIfLinux,lldbtest.skipIfWindows])
>
>
>
> I’m going to want to add a skip in there for Hexagon, but what does this
> test actually do?
>

I haven't worked directly, but in general, the MakeInlineTest tests are
used to generate the python side of the test run logic, and assume there is
a main.c/main.cpp/main.mm file in the directory (as there is in that one).
The main.* file will have comments with executable expressions in them that
basically contain everything needed to drive the test using the compiled
main.* file as the test inferior subject.

This particular test looks like it is attempting to test synthetic children
in expression parsing for objective C++.  This one probably should say
something like "skipUnlessDarwin" rather than manually adding all the other
platforms that should skip. (Objective-C++ and Cocoa tests should only run
on Darwin).


>
>
>
>
>
> Second question – a lot of tests are skipped. Are the skipped tests always
> skipped because of something like @benchmarks_test being false, or
> @skipIfFreeBSD being true?
>
>
>
>
>

Skipped tests are any test that is listed as @skipifXYZ, @unittest2.skip or
the like.  Skips happen for a ton of reasons.  Most of our tests now get
turned automagically into 3 or so tests - one for each type of debuginfo
that a test inferior subject can be compiled as.  Those are:
* dsym-style debuginfo, only available on OS X
* dwarf (in-object-file dwarf, all platforms generally have this)
* dwo (only on Linux right now I think)

So each test method defined typically has three variants run, one created
for each debuginfo type.  On any platform, only two (at most) typically
run, the rest being listed as skipped.  A large number of skips will be due
to that.  On non-Darwin platforms, a larger number will be skipped because
they are OS X-specific, like Objective-C/Objective-C++.

That test session directory will show you all the skipped ones.  They start
with "SkippedTest-".


>
> Third question – I see things like this:
>
> self.build(dictionary=self.getBuildFlags())
>
> (from
> packages/Python/lldbsuite/test/functionalities/thread/step_out/TestThreadStepOut.py
> )
>
> How do I see what the build flags are? How does it know which file to
> build?
>
>
>

The test session directory will have a separate log for each test method
that is