Re: [lldb-dev] Compiler types and renamings

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

> On Sep 17, 2015, at 3:08 AM, Bruce Mitchener  
> wrote:
> 
> Howdy!
> 
> I was looking at some of the CompilerType changes and had some questions 
> related to the recent cleanups and renamings.
> 
>   • clang_type_t is a typedef for void* and is used for the opaque qual 
> type code among other things. However, the m_type on CompilerType is just a 
> void*.  Should we rename clang_type_t to compiler_type_t or just do away with 
> it and use void* instead?

It might be a good idea to use something like "compiler_opaque_type_t" or just 
"opaque_t", which is a typedef to "void *". Then we can use this to 
CompilerDecl, CompilerDeclContext and CompilerType.

>   • SymbolFileDWARF has 2 typedefs, DIEToClangType and ClangTypeToDIE 
> which are used for 2 maps, m_forward_decl_die_to_clang_type and 
> m_forward_decl_clang_type_to_die. Should these be renamed to use Compiler 
> instead of Clang?

They could be, but I really need to move these DIEToClangType and 
ClangTypeToDIE over into DWARFASTParserClang. The problem it is isn't saving 
the entire CompilerType it is just saving the clang_type_t and some other type 
system, like Go's TypeSystem, could actually make a CompilerType and use its 
type system and this "void *"... So this map is really just for Clang types. 
The reason it wasn't moved was we only have one DWARFASTParserClang when we 
have DWARF in .o files on MacOSX (we have a "a.out" executable and it points to 
N SymbolFileDWARF instances (one for each .o file where the .o files contain 
DWARF, but there is no DWARF in the main executable) so I didn't want to move 
this map over into DWARFASTParserClang since this would change things. So I 
vote to not rename it for now and let users know this is for clang types only...

>   • Any use of an instance of CompilerType in general code (code not in a 
> file with Clang in the name) can probably be renamed from clang_type to 
> compiler_type, right? This would include the clang_type member on Type.

Yes! please do make the change to fix this.

> I'd like to do any of the above, just want to make sure that it won't clash 
> with pending changes like this and that people actually want this to happen.

So please do the first and last and skip the DIEToClangType/ClangTypeToDIE 
cleanup.

Greg

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

Re: [lldb-dev] Compiler types and renamings

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

> On Sep 17, 2015, at 10:14 AM, Ryan Brown  wrote:
> 
> 
> 
> On Thu, Sep 17, 2015 at 10:06 AM Greg Clayton via lldb-dev 
>  wrote:
> 
> > On Sep 17, 2015, at 3:08 AM, Bruce Mitchener  
> > wrote:
> >
> > Howdy!
> >
> > I was looking at some of the CompilerType changes and had some questions 
> > related to the recent cleanups and renamings.
> >
> >   • clang_type_t is a typedef for void* and is used for the opaque qual 
> > type code among other things. However, the m_type on CompilerType is just a 
> > void*.  Should we rename clang_type_t to compiler_type_t or just do away 
> > with it and use void* instead?
> 
> It might be a good idea to use something like "compiler_opaque_type_t" or 
> just "opaque_t", which is a typedef to "void *". Then we can use this to 
> CompilerDecl, CompilerDeclContext and CompilerType.
> 
> >   • SymbolFileDWARF has 2 typedefs, DIEToClangType and ClangTypeToDIE 
> > which are used for 2 maps, m_forward_decl_die_to_clang_type and 
> > m_forward_decl_clang_type_to_die. Should these be renamed to use Compiler 
> > instead of Clang?
> 
> They could be, but I really need to move these DIEToClangType and 
> ClangTypeToDIE over into DWARFASTParserClang. The problem it is isn't saving 
> the entire CompilerType it is just saving the clang_type_t and some other 
> type system, like Go's TypeSystem, could actually make a CompilerType and use 
> its type system and this "void *"... So this map is really just for Clang 
> types. The reason it wasn't moved was we only have one DWARFASTParserClang 
> when we have DWARF in .o files on MacOSX (we have a "a.out" executable and it 
> points to N SymbolFileDWARF instances (one for each .o file where the .o 
> files contain DWARF, but there is no DWARF in the main executable) so I 
> didn't want to move this map over into DWARFASTParserClang since this would 
> change things. So I vote to not rename it for now and let users know this is 
> for clang types only...
> 
> Actually the DWARFASTParserGo is using this too.
> Is that a problem? It seems like each die should only be associated with one 
> compile unit and hence one type system.
>  

Yes that is a problem if there is ever mixed Go and C/C++/ObjC in one binary. I 
would switch DWARFASTParserGo() to have its own cache and use it.

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

Re: [lldb-dev] Testing through api vs. commands

2015-09-17 Thread Zachary Turner via lldb-dev 
On Thu, Sep 17, 2015 at 10:08 AM  wrote:

> On Tue, Sep 15, 2015 at 11:36:00PM +, Zachary Turner wrote:
> > a) they should be explicitly marked as interface tests.
>
> What's the decorator for this?
>
There's not one currently.


>
> > d) Results of these interface tests should also not be *verified* by the
> > use of self.expect, but itself through the API.  (Relying on the text to
> be
> > formatted a specific way is obviously problematic, as opposed to just
> > verifying the actual state of the debugger)
>
> How do you rely "on the text to be formatted a specific way"?
>

Quick example: One of the most common patterns in the test are to do some
things, print a backtrace, and run a regex against the output of the
backtrace.   I've found at least 3 different examples of how this causes
things to fail on Windows:

1) When we demangle a function, we print the full signature.  like
foo.exe`void func(int)`.  On linux/mac, it would print foo`func.  So when
the regex is built as ` this will fail on windows, because
our demangled names look different.  The proper way to do this is to get an
SBFrame, get the instruction pointer for it, get an SBSymbol for the
instruction pointer, then get the short name of the symbol and compare it
against 'func' or whatever your function name is.

2) Another example is that there's some tests that verify argument passing
on the command line to the inferior.  Again, it does this by printing a
backtrace, and grepping for "argc=3" anywhere in the backtrace.  This is an
incorrect check for any number of reasons.  On Windows it's incorrect in
that it *succeeds* when it should fail, because argc is actually pointing
to junk memory, and it's value is 3290823098 or something that happens to
start with a 3.  It could also be incorrect.

3) A third example is that when we encounter an exception on Windows
(access violation, etc) the debugger will break.  A backtrace will show
stop reason = exception, as it should.  But we would like to print the
exception code as well, because this is important on Windows.  This differs
from the situation on other platforms, where you might print the name of a
signal, for example.  So you have to carefully construct a regex to make
sure it doesn't mess up platforms which you don't even work on, which is
problematic.

This problem will probably become worse as time goes on, because people who
are accustomed to debugging on Windows (and Linux, and MacOSX, etc) have
certain expectations of how things should look, and to present the best
user experience we would like to match those expectations wherever it is
reasonable to do so.  But since many tests are basically tests of the
formatted command output, it makes it almost impossible to veer from the
current format without breaking tests.

So ultimately, core functionality testing should be independent of command
testing.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

2015-09-17 Thread Greg Clayton via lldb-dev 
Here is the output of attaching to a process with ProcessGDBRemote:

(lldb) log enable lldb state
(lldb) attach 12406
Process::SetPublicState (state = attaching, restarted = 0)
Process::SetPrivateState (stopped)
Process::SetPrivateState (stopped) stop_id = 1
Process::SetPublicState (state = stopped, restarted = 0)
Process 12406 stopped
* thread #1: tid = 0x6f2673, 0x7fff99688682 libsystem_kernel.dylib read + 
10, stop reason = signal SIGSTOP, queue = com.apple.main-thread
frame #0: 0x7fff99688682 libsystem_kernel.dylib read + 10
libsystem_kernel.dylib`read:
->  0x7fff99688682 <+10>: jae0x7fff9968868c; <+20>
0x7fff99688684 <+12>: movq   %rax, %rdi
0x7fff99688687 <+15>: jmp0x7fff99682c78; cerror
0x7fff9968868c <+20>: retq   


So we see the public state was set to eStateAttaching and then it was set to 
eStateStopped. Try this out and let me know what you are seeing.

Greg


> On Sep 16, 2015, at 1:41 PM, Philippe Lavoie via lldb-dev 
>  wrote:
> 
> It is the AttachToProcessWithID that hangs and never returns, so I cannot use 
> my listener yet.
> 
> -Philippe
> 
> From: jing...@apple.com [jing...@apple.com]
> Sent: Wednesday, September 16, 2015 3:34 PM
> To: Philippe Lavoie
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
> 
> Did you try waiting for an event on the listener you've passed to 
> AttachToProcess?  The last event after everything is done should be the 
> notification to the public listener (i.e. your test_listener) that the 
> process you attached to has stopped, and nobody is fetching that.
> 
> Jim
> 
>> On Sep 16, 2015, at 11:59 AM, Philippe Lavoie via lldb-dev 
>>  wrote:
>> 
>> 
>> I am trying to attach to a stopped process on our dsp target using the 
>> SBTarget interface but the call hangs.
>> What I understand is that it is waiting for events on the "lldb.process" 
>> broadcaster using the "lldb.Target.Attach.attach.hijack" listener.
>> 
>> Enabling the logs, I see that the process is attached successfully and that 
>> the stop event is generated. It just seems that the event is not seen by the 
>> listener.
>> 
>> 1442428969.32100 004B9590 Listener::WaitForEventsInternal (timeout = { 
>>  }) for lldb.Target.Attach.attach.hijack
>> 1442428969.32100 004BC7F4 Broadcaster("opus.remote")::BroadcastEvent 
>> (event_sp = {00A72050 Event: broadcaster = 004BC7F4 (opus.remote), type = 
>> 0x0001, data = }, unique =0) hijack = 
>> 1442428969.34100 0049AC50 Broadcaster("lldb.target")::BroadcastEvent 
>> (event_sp = {00A70C78 Event: broadcaster = 0049AC50 (lldb.target), type = 
>> 0x0002 (modules-loaded), data = {}}, unique =0) hijack = 
>> 1442428969.34100 004BC7F4 Broadcaster("opus.remote")::BroadcastEvent 
>> (event_sp = {00A723C8 Event: broadcaster = 004BC7F4 (opus.remote), type = 
>> 0x0001, data = }, unique =0) hijack = 
>> 1442428969.45000 004BC394 
>> Broadcaster("lldb.process.internal_state_broadcaster")::BroadcastEvent 
>> (event_sp = {00A723C8 Event: broadcaster = 004BC394 
>> (lldb.process.internal_state_broadcaster), type = 0x0001, data = { 
>> process = 004BC308 (pid = 1), state = stopped}}, unique =0) hijack = 
>> 1442428969.45200 004BC42C 
>> Listener('lldb.process.internal_state_listener')::AddEvent (event_sp = 
>> {00A723C8})
>> 1442428969.45300 031CF700 Listener::WaitForEventsInternal (timeout = { 
>>  }) for ProcessOpusRemote::AsyncThread
>> 1442428969.45300 004BC42C 'lldb.process.internal_state_listener' 
>> Listener::FindNextEventInternal(broadcaster=, 
>> broadcaster_names=[0], event_type_mask=0x, remove=1) event 
>> 00A723C8
>> 1442428969.45900 0309F8D4 Listener::StartListeningForEvents (broadcaster 
>> = 004BC5F4, mask = 0x0020) acquired_mask = 0x0020 for 
>> Communication::SyncronizeWithReadThread
>> 1442428969.47000 Process::ShouldBroadcastEvent (00A723C8) => new state: 
>> stopped, last broadcast state: stopped - YES
>> 1442428969.47100 004BC318 Broadcaster("lldb.process")::BroadcastEvent 
>> (event_sp = {00A723C8 Event: broadcaster = 004BC318 (lldb.process), type = 
>> 0x0001(state-changed), data = { process = 004BC308 (pid = 1), state = 
>> stopped}}, unique =0) hijack = 
>> 1442428969.47300 00402598 Listener('lldb.Debugger')::AddEvent (event_sp 
>> = {00A723C8})
>> 1442428969.47400 004BC42C Listener::WaitForEventsInternal (timeout = { 
>>  }) for lldb.process.internal_state_listener
>> 
>> Here's the code I use to attach.
>> 
>> SBDebugger::Initialize();
>> 
>> SBDebugger debugger = lldb::SBDebugger::Create(false);
>> debugger.SetAsync(true);
>> 
>> const char* categories [] = { "process", "events", 0 };
>> if (!debugger.EnableLog("lldb", categories))
>> return -1;
>> 
>> pid_t pid = 1;
>> 
>> SBTarget target =

Re: [lldb-dev] Testing through api vs. commands

2015-09-17 Thread via lldb-dev 
On Tue, Sep 15, 2015 at 04:46:41PM -0700, Jim Ingham wrote:
> > In any case, there's a lot I never could figure out how to do in the SB
> > API that I could only do via commands.  For example, how do you test
> > that a trailing space at the end of the expr --language option's argument
> > is trimmed in the SB API?
> 
> I'm not quite sure I understand what you mean by this example?  It sounds 
> like you are asking how to test peculiarities of the
> Command Line language name option parser through the SB API.  Not sure that 
> makes sense.

See test test_settings_with_trailing_whitespace in 
test/settings/TestSettings.py.
A test I added here looks like:
# language
self.runCmd ("settings set target.language c89")  # Set to known 
value
self.runCmd ("settings set target.language pascal ")# Set to new 
value with trailing whitespace
self.expect ("settings show target.language", 
SETTING_MSG("target.language"),
startstr = "target.language (language) = pascal")
self.runCmd("settings clear target.language", check=False)

How would you write this test using the Python API?

> Note, you might have to do some work to marshall information in a way that 
> looks like what some of the complex commands produce.  But even some of the 
> complex printers like the frame & thread Status are available through the SB 
> API's and anything else useful like that should also be exposed at some 
> point.  

I don't think anyone is against using the Python API, but it needs to be easier
to learn and use before folks will adopt it over self.expect.  self.runCmd and
self.expect are straight forward and it's easy to quickly write tests using it.
If you make it too hard to write tests, you'll deter folks from writing tests 
for
the features they add.

> In theory, somebody could go back & re-implement the lldb command line on top 
> of the SB API's

That would be a cool project to give to some poor college students working on a
branch :)

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

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

2015-09-17 Thread Philippe Lavoie via lldb-dev 

Ah! The issue was in my custom Platform's Attach. It is based on PlatformGDB, 
but it seems I bulldozed through a little too fast.

I was missing a call to Process::HijackProcessEvents before calling 
Process::Attach

auto listener = 
attach_info.GetHijackListener();
if (listener != nullptr)

process_sp->HijackProcessEvents(listener.get());

Thanks,
-Philippe


From: Greg Clayton [gclay...@apple.com]
Sent: Thursday, September 17, 2015 1:12 PM
To: Philippe Lavoie
Cc: Jim Ingham; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

This sounds like you don't have a private state thread running. The private 
state thread watches for private state changes in Process and promotes them 
into public state changes as needed. Can you check if 
Process::PrivateStateThread() is running? This should be triggered by a call to 
StartPrivateStateThread() in "Error Process::Attach(ProcessAttachInfo &)".

Greg


> On Sep 17, 2015, at 10:02 AM, Philippe Lavoie  
> wrote:
>
> I am missing the final SetPublicState call.
>
> 1442509021.49000 Process::SetPrivateState (connected)
> 1442509021.49200 Process::SetPublicState (state = attaching, restarted = 
> 0)
> 1442509021.62700 Process::SetPrivateState (stopped)
> 1442509021.62800 Process::SetPrivateState (stopped) stop_id = 1
>
> 
> From: Greg Clayton [gclay...@apple.com]
> Sent: Thursday, September 17, 2015 12:55 PM
> To: Philippe Lavoie
> Cc: Jim Ingham; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
>
> Here is the output of attaching to a process with ProcessGDBRemote:
>
> (lldb) log enable lldb state
> (lldb) attach 12406
> Process::SetPublicState (state = attaching, restarted = 0)
> Process::SetPrivateState (stopped)
> Process::SetPrivateState (stopped) stop_id = 1
> Process::SetPublicState (state = stopped, restarted = 0)
> Process 12406 stopped
> * thread #1: tid = 0x6f2673, 0x7fff99688682 libsystem_kernel.dylib read + 
> 10, stop reason = signal SIGSTOP, queue = com.apple.main-thread
>frame #0: 0x7fff99688682 libsystem_kernel.dylib read + 10
> libsystem_kernel.dylib`read:
> ->  0x7fff99688682 <+10>: jae0x7fff9968868c; <+20>
>0x7fff99688684 <+12>: movq   %rax, %rdi
>0x7fff99688687 <+15>: jmp0x7fff99682c78; cerror
>0x7fff9968868c <+20>: retq
>
>
> So we see the public state was set to eStateAttaching and then it was set to 
> eStateStopped. Try this out and let me know what you are seeing.
>
> Greg
>
>
>> On Sep 16, 2015, at 1:41 PM, Philippe Lavoie via lldb-dev 
>>  wrote:
>>
>> It is the AttachToProcessWithID that hangs and never returns, so I cannot 
>> use my listener yet.
>>
>> -Philippe
>> 
>> From: jing...@apple.com [jing...@apple.com]
>> Sent: Wednesday, September 16, 2015 3:34 PM
>> To: Philippe Lavoie
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
>>
>> Did you try waiting for an event on the listener you've passed to 
>> AttachToProcess?  The last event after everything is done should be the 
>> notification to the public listener (i.e. your test_listener) that the 
>> process you attached to has stopped, and nobody is fetching that.
>>
>> Jim
>>
>>> On Sep 16, 2015, at 11:59 AM, Philippe Lavoie via lldb-dev 
>>>  wrote:
>>>
>>>
>>> I am trying to attach to a stopped process on our dsp target using the 
>>> SBTarget interface but the call hangs.
>>> What I understand is that it is waiting for events on the "lldb.process" 
>>> broadcaster using the "lldb.Target.Attach.attach.hijack" listener.
>>>
>>> Enabling the logs, I see that the process is attached successfully and that 
>>> the stop event is generated. It just seems that the event is not seen by 
>>> the listener.
>>>
>>> 1442428969.32100 004B9590 Listener::WaitForEventsInternal (timeout = { 
>>>  }) for lldb.Target.Attach.attach.hijack
>>> 1442428969.32100 004BC7F4 Broadcaster("opus.remote")::BroadcastEvent 
>>> (event_sp = {00A72050 Event: broadcaster = 004BC7F4 (opus.remote), type = 
>>> 0x0001, data = }, unique =0) hijack = 
>>> 1442428969.34100 0049AC50 Broadcaster("lldb.target")::BroadcastEvent 
>>> (event_sp = {00A70C78 Event: broadcaster = 0049AC50 (lldb.target), type = 
>>> 0x0002 (modules-loaded), data = {}}, unique =0) hijack = 
>>> 1442428969.34100 004BC7F4 Broadcaster("opus.remote")::BroadcastEvent 
>>> (event_sp = {00A723C8 Event: broadcaster = 004BC7F4 (opus.remote), type = 
>>> 0x0001, data = }, unique =0) hijack = 
>>> 1442428969.45000 004BC394 
>>>

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

2015-09-17 Thread Philippe Lavoie via lldb-dev 
I am missing the final SetPublicState call.

1442509021.49000 Process::SetPrivateState (connected)
1442509021.49200 Process::SetPublicState (state = attaching, restarted = 0)
1442509021.62700 Process::SetPrivateState (stopped)
1442509021.62800 Process::SetPrivateState (stopped) stop_id = 1


From: Greg Clayton [gclay...@apple.com]
Sent: Thursday, September 17, 2015 12:55 PM
To: Philippe Lavoie
Cc: Jim Ingham; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

Here is the output of attaching to a process with ProcessGDBRemote:

(lldb) log enable lldb state
(lldb) attach 12406
Process::SetPublicState (state = attaching, restarted = 0)
Process::SetPrivateState (stopped)
Process::SetPrivateState (stopped) stop_id = 1
Process::SetPublicState (state = stopped, restarted = 0)
Process 12406 stopped
* thread #1: tid = 0x6f2673, 0x7fff99688682 libsystem_kernel.dylib read + 
10, stop reason = signal SIGSTOP, queue = com.apple.main-thread
frame #0: 0x7fff99688682 libsystem_kernel.dylib read + 10
libsystem_kernel.dylib`read:
->  0x7fff99688682 <+10>: jae0x7fff9968868c; <+20>
0x7fff99688684 <+12>: movq   %rax, %rdi
0x7fff99688687 <+15>: jmp0x7fff99682c78; cerror
0x7fff9968868c <+20>: retq


So we see the public state was set to eStateAttaching and then it was set to 
eStateStopped. Try this out and let me know what you are seeing.

Greg


> On Sep 16, 2015, at 1:41 PM, Philippe Lavoie via lldb-dev 
>  wrote:
>
> It is the AttachToProcessWithID that hangs and never returns, so I cannot use 
> my listener yet.
>
> -Philippe
> 
> From: jing...@apple.com [jing...@apple.com]
> Sent: Wednesday, September 16, 2015 3:34 PM
> To: Philippe Lavoie
> Cc: lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
>
> Did you try waiting for an event on the listener you've passed to 
> AttachToProcess?  The last event after everything is done should be the 
> notification to the public listener (i.e. your test_listener) that the 
> process you attached to has stopped, and nobody is fetching that.
>
> Jim
>
>> On Sep 16, 2015, at 11:59 AM, Philippe Lavoie via lldb-dev 
>>  wrote:
>>
>>
>> I am trying to attach to a stopped process on our dsp target using the 
>> SBTarget interface but the call hangs.
>> What I understand is that it is waiting for events on the "lldb.process" 
>> broadcaster using the "lldb.Target.Attach.attach.hijack" listener.
>>
>> Enabling the logs, I see that the process is attached successfully and that 
>> the stop event is generated. It just seems that the event is not seen by the 
>> listener.
>>
>> 1442428969.32100 004B9590 Listener::WaitForEventsInternal (timeout = { 
>>  }) for lldb.Target.Attach.attach.hijack
>> 1442428969.32100 004BC7F4 Broadcaster("opus.remote")::BroadcastEvent 
>> (event_sp = {00A72050 Event: broadcaster = 004BC7F4 (opus.remote), type = 
>> 0x0001, data = }, unique =0) hijack = 
>> 1442428969.34100 0049AC50 Broadcaster("lldb.target")::BroadcastEvent 
>> (event_sp = {00A70C78 Event: broadcaster = 0049AC50 (lldb.target), type = 
>> 0x0002 (modules-loaded), data = {}}, unique =0) hijack = 
>> 1442428969.34100 004BC7F4 Broadcaster("opus.remote")::BroadcastEvent 
>> (event_sp = {00A723C8 Event: broadcaster = 004BC7F4 (opus.remote), type = 
>> 0x0001, data = }, unique =0) hijack = 
>> 1442428969.45000 004BC394 
>> Broadcaster("lldb.process.internal_state_broadcaster")::BroadcastEvent 
>> (event_sp = {00A723C8 Event: broadcaster = 004BC394 
>> (lldb.process.internal_state_broadcaster), type = 0x0001, data = { 
>> process = 004BC308 (pid = 1), state = stopped}}, unique =0) hijack = 
>> 1442428969.45200 004BC42C 
>> Listener('lldb.process.internal_state_listener')::AddEvent (event_sp = 
>> {00A723C8})
>> 1442428969.45300 031CF700 Listener::WaitForEventsInternal (timeout = { 
>>  }) for ProcessOpusRemote::AsyncThread
>> 1442428969.45300 004BC42C 'lldb.process.internal_state_listener' 
>> Listener::FindNextEventInternal(broadcaster=, 
>> broadcaster_names=[0], event_type_mask=0x, remove=1) event 
>> 00A723C8
>> 1442428969.45900 0309F8D4 Listener::StartListeningForEvents (broadcaster 
>> = 004BC5F4, mask = 0x0020) acquired_mask = 0x0020 for 
>> Communication::SyncronizeWithReadThread
>> 1442428969.47000 Process::ShouldBroadcastEvent (00A723C8) => new state: 
>> stopped, last broadcast state: stopped - YES
>> 1442428969.47100 004BC318 Broadcaster("lldb.process")::BroadcastEvent 
>> (event_sp = {00A723C8 Event: broadcaster = 004BC318 (lldb.process), type = 
>> 0x0001(state-changed), data = { process = 004BC308 (pid = 1), state = 
>> stopped}}, unique =0) hijack = 
>> 1442428969.47300

Re: [lldb-dev] Compiler types and renamings

2015-09-17 Thread Ryan Brown via lldb-dev 
On Thu, Sep 17, 2015 at 10:06 AM Greg Clayton via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

>
> > On Sep 17, 2015, at 3:08 AM, Bruce Mitchener 
> wrote:
> >
> > Howdy!
> >
> > I was looking at some of the CompilerType changes and had some questions
> related to the recent cleanups and renamings.
> >
> >   • clang_type_t is a typedef for void* and is used for the opaque
> qual type code among other things. However, the m_type on CompilerType is
> just a void*.  Should we rename clang_type_t to compiler_type_t or just do
> away with it and use void* instead?
>
> It might be a good idea to use something like "compiler_opaque_type_t" or
> just "opaque_t", which is a typedef to "void *". Then we can use this to
> CompilerDecl, CompilerDeclContext and CompilerType.
>
> >   • SymbolFileDWARF has 2 typedefs, DIEToClangType and
> ClangTypeToDIE which are used for 2 maps, m_forward_decl_die_to_clang_type
> and m_forward_decl_clang_type_to_die. Should these be renamed to use
> Compiler instead of Clang?
>
> They could be, but I really need to move these DIEToClangType and
> ClangTypeToDIE over into DWARFASTParserClang. The problem it is isn't
> saving the entire CompilerType it is just saving the clang_type_t and some
> other type system, like Go's TypeSystem, could actually make a CompilerType
> and use its type system and this "void *"... So this map is really just for
> Clang types. The reason it wasn't moved was we only have one
> DWARFASTParserClang when we have DWARF in .o files on MacOSX (we have a
> "a.out" executable and it points to N SymbolFileDWARF instances (one for
> each .o file where the .o files contain DWARF, but there is no DWARF in the
> main executable) so I didn't want to move this map over into
> DWARFASTParserClang since this would change things. So I vote to not rename
> it for now and let users know this is for clang types only...
>

Actually the DWARFASTParserGo is using this too.
Is that a problem? It seems like each die should only be associated with
one compile unit and hence one type system.


>
> >   • Any use of an instance of CompilerType in general code (code not
> in a file with Clang in the name) can probably be renamed from clang_type
> to compiler_type, right? This would include the clang_type member on Type.
>
> Yes! please do make the change to fix this.
>
> > I'd like to do any of the above, just want to make sure that it won't
> clash with pending changes like this and that people actually want this to
> happen.
>
> So please do the first and last and skip the DIEToClangType/ClangTypeToDIE
> cleanup.
>
> Greg
>
> ___
> 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] Testing through api vs. commands

2015-09-17 Thread via lldb-dev 
On Thu, Sep 17, 2015 at 05:20:14PM +, Zachary Turner wrote:
> > > a) they should be explicitly marked as interface tests.
> > What's the decorator for this?
> 
> There's not one currently.

Will there be?

> > > d) Results of these interface tests should also not be *verified* by the
> > > use of self.expect, but itself through the API.  (Relying on the text to
> > be
> > > formatted a specific way is obviously problematic, as opposed to just
> > > verifying the actual state of the debugger)
> >
> > How do you rely "on the text to be formatted a specific way"?
> 
> Quick example: One of the most common patterns in the test are to do some
> things, print a backtrace, and run a regex against the output of the
> backtrace.   I've found at least 3 different examples of how this causes
> things to fail on Windows:

Oh, I misunderstood your point.  You're saying the existing tests rely
"on the text to be formatted a specific way".  Right.

I was asking how you *could* make sure the output was formatted a
specific way using the Python API.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

2015-09-17 Thread Greg Clayton via lldb-dev 
This sounds like you don't have a private state thread running. The private 
state thread watches for private state changes in Process and promotes them 
into public state changes as needed. Can you check if 
Process::PrivateStateThread() is running? This should be triggered by a call to 
StartPrivateStateThread() in "Error Process::Attach(ProcessAttachInfo &)".

Greg


> On Sep 17, 2015, at 10:02 AM, Philippe Lavoie  
> wrote:
> 
> I am missing the final SetPublicState call.
> 
> 1442509021.49000 Process::SetPrivateState (connected)
> 1442509021.49200 Process::SetPublicState (state = attaching, restarted = 
> 0)
> 1442509021.62700 Process::SetPrivateState (stopped)
> 1442509021.62800 Process::SetPrivateState (stopped) stop_id = 1
> 
> 
> From: Greg Clayton [gclay...@apple.com]
> Sent: Thursday, September 17, 2015 12:55 PM
> To: Philippe Lavoie
> Cc: Jim Ingham; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
> 
> Here is the output of attaching to a process with ProcessGDBRemote:
> 
> (lldb) log enable lldb state
> (lldb) attach 12406
> Process::SetPublicState (state = attaching, restarted = 0)
> Process::SetPrivateState (stopped)
> Process::SetPrivateState (stopped) stop_id = 1
> Process::SetPublicState (state = stopped, restarted = 0)
> Process 12406 stopped
> * thread #1: tid = 0x6f2673, 0x7fff99688682 libsystem_kernel.dylib read + 
> 10, stop reason = signal SIGSTOP, queue = com.apple.main-thread
>frame #0: 0x7fff99688682 libsystem_kernel.dylib read + 10
> libsystem_kernel.dylib`read:
> ->  0x7fff99688682 <+10>: jae0x7fff9968868c; <+20>
>0x7fff99688684 <+12>: movq   %rax, %rdi
>0x7fff99688687 <+15>: jmp0x7fff99682c78; cerror
>0x7fff9968868c <+20>: retq
> 
> 
> So we see the public state was set to eStateAttaching and then it was set to 
> eStateStopped. Try this out and let me know what you are seeing.
> 
> Greg
> 
> 
>> On Sep 16, 2015, at 1:41 PM, Philippe Lavoie via lldb-dev 
>>  wrote:
>> 
>> It is the AttachToProcessWithID that hangs and never returns, so I cannot 
>> use my listener yet.
>> 
>> -Philippe
>> 
>> From: jing...@apple.com [jing...@apple.com]
>> Sent: Wednesday, September 16, 2015 3:34 PM
>> To: Philippe Lavoie
>> Cc: lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
>> 
>> Did you try waiting for an event on the listener you've passed to 
>> AttachToProcess?  The last event after everything is done should be the 
>> notification to the public listener (i.e. your test_listener) that the 
>> process you attached to has stopped, and nobody is fetching that.
>> 
>> Jim
>> 
>>> On Sep 16, 2015, at 11:59 AM, Philippe Lavoie via lldb-dev 
>>>  wrote:
>>> 
>>> 
>>> I am trying to attach to a stopped process on our dsp target using the 
>>> SBTarget interface but the call hangs.
>>> What I understand is that it is waiting for events on the "lldb.process" 
>>> broadcaster using the "lldb.Target.Attach.attach.hijack" listener.
>>> 
>>> Enabling the logs, I see that the process is attached successfully and that 
>>> the stop event is generated. It just seems that the event is not seen by 
>>> the listener.
>>> 
>>> 1442428969.32100 004B9590 Listener::WaitForEventsInternal (timeout = { 
>>>  }) for lldb.Target.Attach.attach.hijack
>>> 1442428969.32100 004BC7F4 Broadcaster("opus.remote")::BroadcastEvent 
>>> (event_sp = {00A72050 Event: broadcaster = 004BC7F4 (opus.remote), type = 
>>> 0x0001, data = }, unique =0) hijack = 
>>> 1442428969.34100 0049AC50 Broadcaster("lldb.target")::BroadcastEvent 
>>> (event_sp = {00A70C78 Event: broadcaster = 0049AC50 (lldb.target), type = 
>>> 0x0002 (modules-loaded), data = {}}, unique =0) hijack = 
>>> 1442428969.34100 004BC7F4 Broadcaster("opus.remote")::BroadcastEvent 
>>> (event_sp = {00A723C8 Event: broadcaster = 004BC7F4 (opus.remote), type = 
>>> 0x0001, data = }, unique =0) hijack = 
>>> 1442428969.45000 004BC394 
>>> Broadcaster("lldb.process.internal_state_broadcaster")::BroadcastEvent 
>>> (event_sp = {00A723C8 Event: broadcaster = 004BC394 
>>> (lldb.process.internal_state_broadcaster), type = 0x0001, data = { 
>>> process = 004BC308 (pid = 1), state = stopped}}, unique =0) hijack = 
>>> 
>>> 1442428969.45200 004BC42C 
>>> Listener('lldb.process.internal_state_listener')::AddEvent (event_sp = 
>>> {00A723C8})
>>> 1442428969.45300 031CF700 Listener::WaitForEventsInternal (timeout = { 
>>>  }) for ProcessOpusRemote::AsyncThread
>>> 1442428969.45300 004BC42C 'lldb.process.internal_state_listener' 
>>> Listener::FindNextEventInternal(broadcaster=, 
>>> broadcaster_names=[0], event_type_mask=0x, remove=1) event 
>>> 00A723C8
>>>

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

2015-09-17 Thread Greg Clayton via lldb-dev 
Yep, that'll do it!

Are you up and running now?

> On Sep 17, 2015, at 11:05 AM, Philippe Lavoie  
> wrote:
> 
> 
> Ah! The issue was in my custom Platform's Attach. It is based on PlatformGDB, 
> but it seems I bulldozed through a little too fast.
> 
> I was missing a call to Process::HijackProcessEvents before calling 
> Process::Attach
> 
>   auto listener = 
> attach_info.GetHijackListener();
>   if (listener != nullptr)
>   
> process_sp->HijackProcessEvents(listener.get());
> 
> Thanks,
> -Philippe
> 
> 
> From: Greg Clayton [gclay...@apple.com]
> Sent: Thursday, September 17, 2015 1:12 PM
> To: Philippe Lavoie
> Cc: Jim Ingham; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
> 
> This sounds like you don't have a private state thread running. The private 
> state thread watches for private state changes in Process and promotes them 
> into public state changes as needed. Can you check if 
> Process::PrivateStateThread() is running? This should be triggered by a call 
> to StartPrivateStateThread() in "Error Process::Attach(ProcessAttachInfo &)".
> 
> Greg
> 
> 
>> On Sep 17, 2015, at 10:02 AM, Philippe Lavoie  
>> wrote:
>> 
>> I am missing the final SetPublicState call.
>> 
>> 1442509021.49000 Process::SetPrivateState (connected)
>> 1442509021.49200 Process::SetPublicState (state = attaching, restarted = 
>> 0)
>> 1442509021.62700 Process::SetPrivateState (stopped)
>> 1442509021.62800 Process::SetPrivateState (stopped) stop_id = 1
>> 
>> 
>> From: Greg Clayton [gclay...@apple.com]
>> Sent: Thursday, September 17, 2015 12:55 PM
>> To: Philippe Lavoie
>> Cc: Jim Ingham; lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
>> 
>> Here is the output of attaching to a process with ProcessGDBRemote:
>> 
>> (lldb) log enable lldb state
>> (lldb) attach 12406
>> Process::SetPublicState (state = attaching, restarted = 0)
>> Process::SetPrivateState (stopped)
>> Process::SetPrivateState (stopped) stop_id = 1
>> Process::SetPublicState (state = stopped, restarted = 0)
>> Process 12406 stopped
>> * thread #1: tid = 0x6f2673, 0x7fff99688682 libsystem_kernel.dylib read 
>> + 10, stop reason = signal SIGSTOP, queue = com.apple.main-thread
>>   frame #0: 0x7fff99688682 libsystem_kernel.dylib read + 10
>> libsystem_kernel.dylib`read:
>> ->  0x7fff99688682 <+10>: jae0x7fff9968868c; <+20>
>>   0x7fff99688684 <+12>: movq   %rax, %rdi
>>   0x7fff99688687 <+15>: jmp0x7fff99682c78; cerror
>>   0x7fff9968868c <+20>: retq
>> 
>> 
>> So we see the public state was set to eStateAttaching and then it was set to 
>> eStateStopped. Try this out and let me know what you are seeing.
>> 
>> Greg
>> 
>> 
>>> On Sep 16, 2015, at 1:41 PM, Philippe Lavoie via lldb-dev 
>>>  wrote:
>>> 
>>> It is the AttachToProcessWithID that hangs and never returns, so I cannot 
>>> use my listener yet.
>>> 
>>> -Philippe
>>> 
>>> From: jing...@apple.com [jing...@apple.com]
>>> Sent: Wednesday, September 16, 2015 3:34 PM
>>> To: Philippe Lavoie
>>> Cc: lldb-dev@lists.llvm.org
>>> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
>>> 
>>> Did you try waiting for an event on the listener you've passed to 
>>> AttachToProcess?  The last event after everything is done should be the 
>>> notification to the public listener (i.e. your test_listener) that the 
>>> process you attached to has stopped, and nobody is fetching that.
>>> 
>>> Jim
>>> 
 On Sep 16, 2015, at 11:59 AM, Philippe Lavoie via lldb-dev 
  wrote:
 
 
 I am trying to attach to a stopped process on our dsp target using the 
 SBTarget interface but the call hangs.
 What I understand is that it is waiting for events on the "lldb.process" 
 broadcaster using the "lldb.Target.Attach.attach.hijack" listener.
 
 Enabling the logs, I see that the process is attached successfully and 
 that the stop event is generated. It just seems that the event is not seen 
 by the listener.
 
 1442428969.32100 004B9590 Listener::WaitForEventsInternal (timeout = { 
  }) for lldb.Target.Attach.attach.hijack
 1442428969.32100 004BC7F4 Broadcaster("opus.remote")::BroadcastEvent 
 (event_sp = {00A72050 Event: broadcaster = 004BC7F4 (opus.remote), type = 
 0x0001, data = }, unique =0) hijack = 
 1442428969.34100 0049AC50 Broadcaster("lldb.target")::BroadcastEvent 
 (event_sp = {00A70C78 Event: broadcaster = 0049AC50 (lldb.target), type = 
 0x0002 (modules-loaded), data = {}}, unique =0) hijack =

Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

2015-09-17 Thread Philippe Lavoie via lldb-dev 
Yes, it is working now. I can set breakpoints, step, wait for events, etc.

Thanks for your help!

-Philippe

From: Greg Clayton [gclay...@apple.com]
Sent: Thursday, September 17, 2015 3:42 PM
To: Philippe Lavoie
Cc: Jim Ingham; lldb-dev@lists.llvm.org
Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs

Yep, that'll do it!

Are you up and running now?

> On Sep 17, 2015, at 11:05 AM, Philippe Lavoie  
> wrote:
>
>
> Ah! The issue was in my custom Platform's Attach. It is based on PlatformGDB, 
> but it seems I bulldozed through a little too fast.
>
> I was missing a call to Process::HijackProcessEvents before calling 
> Process::Attach
>
>   auto listener = 
> attach_info.GetHijackListener();
>   if (listener != nullptr)
>   
> process_sp->HijackProcessEvents(listener.get());
>
> Thanks,
> -Philippe
>
> 
> From: Greg Clayton [gclay...@apple.com]
> Sent: Thursday, September 17, 2015 1:12 PM
> To: Philippe Lavoie
> Cc: Jim Ingham; lldb-dev@lists.llvm.org
> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
>
> This sounds like you don't have a private state thread running. The private 
> state thread watches for private state changes in Process and promotes them 
> into public state changes as needed. Can you check if 
> Process::PrivateStateThread() is running? This should be triggered by a call 
> to StartPrivateStateThread() in "Error Process::Attach(ProcessAttachInfo &)".
>
> Greg
>
>
>> On Sep 17, 2015, at 10:02 AM, Philippe Lavoie  
>> wrote:
>>
>> I am missing the final SetPublicState call.
>>
>> 1442509021.49000 Process::SetPrivateState (connected)
>> 1442509021.49200 Process::SetPublicState (state = attaching, restarted = 
>> 0)
>> 1442509021.62700 Process::SetPrivateState (stopped)
>> 1442509021.62800 Process::SetPrivateState (stopped) stop_id = 1
>>
>> 
>> From: Greg Clayton [gclay...@apple.com]
>> Sent: Thursday, September 17, 2015 12:55 PM
>> To: Philippe Lavoie
>> Cc: Jim Ingham; lldb-dev@lists.llvm.org
>> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
>>
>> Here is the output of attaching to a process with ProcessGDBRemote:
>>
>> (lldb) log enable lldb state
>> (lldb) attach 12406
>> Process::SetPublicState (state = attaching, restarted = 0)
>> Process::SetPrivateState (stopped)
>> Process::SetPrivateState (stopped) stop_id = 1
>> Process::SetPublicState (state = stopped, restarted = 0)
>> Process 12406 stopped
>> * thread #1: tid = 0x6f2673, 0x7fff99688682 libsystem_kernel.dylib read 
>> + 10, stop reason = signal SIGSTOP, queue = com.apple.main-thread
>>   frame #0: 0x7fff99688682 libsystem_kernel.dylib read + 10
>> libsystem_kernel.dylib`read:
>> ->  0x7fff99688682 <+10>: jae0x7fff9968868c; <+20>
>>   0x7fff99688684 <+12>: movq   %rax, %rdi
>>   0x7fff99688687 <+15>: jmp0x7fff99682c78; cerror
>>   0x7fff9968868c <+20>: retq
>>
>>
>> So we see the public state was set to eStateAttaching and then it was set to 
>> eStateStopped. Try this out and let me know what you are seeing.
>>
>> Greg
>>
>>
>>> On Sep 16, 2015, at 1:41 PM, Philippe Lavoie via lldb-dev 
>>>  wrote:
>>>
>>> It is the AttachToProcessWithID that hangs and never returns, so I cannot 
>>> use my listener yet.
>>>
>>> -Philippe
>>> 
>>> From: jing...@apple.com [jing...@apple.com]
>>> Sent: Wednesday, September 16, 2015 3:34 PM
>>> To: Philippe Lavoie
>>> Cc: lldb-dev@lists.llvm.org
>>> Subject: Re: [lldb-dev] SBTarget::AttachToProcessWithID hangs
>>>
>>> Did you try waiting for an event on the listener you've passed to 
>>> AttachToProcess?  The last event after everything is done should be the 
>>> notification to the public listener (i.e. your test_listener) that the 
>>> process you attached to has stopped, and nobody is fetching that.
>>>
>>> Jim
>>>
 On Sep 16, 2015, at 11:59 AM, Philippe Lavoie via lldb-dev 
  wrote:


 I am trying to attach to a stopped process on our dsp target using the 
 SBTarget interface but the call hangs.
 What I understand is that it is waiting for events on the "lldb.process" 
 broadcaster using the "lldb.Target.Attach.attach.hijack" listener.

 Enabling the logs, I see that the process is attached successfully and 
 that the stop event is generated. It just seems that the event is not seen 
 by the listener.

 1442428969.32100 004B9590 Listener::WaitForEventsInternal (timeout = { 
  }) for lldb.Target.Attach.attach.hijack
 1442428969.32100 004BC7F4 Broadcaster("opus.remote")::BroadcastEvent 
 (event_sp = {00A72050 Event:

Re: [lldb-dev] test results look typical?

2015-09-17 Thread via lldb-dev 
On Mon, Aug 24, 2015 at 05:37:43PM -0700, via lldb-dev wrote:
> On Mon, Aug 24, 2015 at 03:37:52PM -0700, Todd Fiala via lldb-dev wrote:
> > On Linux on non-virtualized hardware, I currently see the failures below on
> > Ubuntu 14.04.2 using a setup like this:
> > [...]
> > 
> > ninja check-lldb output:
> > 
> > Ran 394 test suites (15 failed) (3.807107%)
> > Ran 474 test cases (17 failed) (3.586498%)
> 
> I don't think you can't trust the reporting of dosep.py's "Ran N test
> cases", as it fails to count about 500 test cases.  

I finally got around to opening a bug for this - see
https://llvm.org/bugs/show_bug.cgi?id=24869
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] [Bug 24869] New: dotest.py reports the wrong number of test cases in mutiprocess mode.

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

Bug ID: 24869
   Summary: dotest.py reports the wrong number of test cases in
mutiprocess mode.
   Product: lldb
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P
 Component: All Bugs
  Assignee: lldb-dev@lists.llvm.org
  Reporter: dawn+bugzi...@burble.org
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

This appears to result from dotest.py failing to count the test cases from
entire test files, as described in a run on a narrowed example below (following
the problem description).

** problem description and steps **

Run "dotest.py -v --output-on-success" and count the total test cases via
adding
up all the Ns in the lines:
Ran N tests in .*
and you get the correct total, 1388 on OSX.
Compare that to the final count of 838 from:
Ran N test cases .*
and you see a difference of 550 tests.

Commands used to run the tests and collect the results are as follows:
cd llvm/tools/lldb/test
./dotest.py -v --output-on-success 2>&1 | tee $INSTALLDIR/lldb_test_out.log
export lldb_failures=`grep -E "^RESULT:" lldb_test_out.log | grep failures
| awk '{count+=$5} END {print count}'` || true
export lldb_errors=`grep -E "^RESULT:" lldb_test_out.log | grep errors |
awk '{count+=$7} END {print count}'` || true
export lldb_total=`grep -E "^Ran [0-9]+ tests? in" lldb_test_out.log | awk
'{count+=$2} END {print count}'`
export lldb_total_cases=`grep -E "^Ran [0-9]+ test cases" lldb_test_out.log
| awk '{count+=$2} END {print count}'`

On OSX, I get:
lldb_failures=4
lldb_errors=0
lldb_total=1388
lldb_total_cases=838


** narrowed example **

When run on the following narrowed subset of tests, you can see that dotest.py
is not counting any test cases from an entire test file.

Test on just 4 types test suites:
rm -rf api arm_emulation attic benchmarks driver
rm -rf example expression_command functionalities help lang
rm -rf linux logging macosx python_api tools
rm -rf settings source-manager terminal warnings
rm -f types/TestIntegerTypes.py

You should have only the following tests left:
types/AbstractBase.py
types/HideTestFailures.py
types/TestFloatTypes.py
types/TestFloatTypesExpr.py
types/TestIntegerTypesExpr.py
types/TestRecursiveTypes.py

When dotest.py is run with the --no-multiprocess option, it correctly counts
46, but counts only 16 otherwise, as can been seen in the relevant test output:

./dotest.py -v --output-on-success --no-multiprocess:
Ran 46 tests in 76.124s

./dotest.py -v --output-on-success:
Testing: 4 test suites, 4 threads
Ran 6 tests in 7.090s
[TestFloatTypes.py PASSED]
Ran 6 tests in 11.230s
[TestFloatTypesExpr.py PASSED]
Ran 30 tests in 55.200s
[TestIntegerTypesExpr.py PASSED]
Ran 4 tests in 3.608s
[TestRecursiveTypes.py PASSED]
Ran 4 test suites (0 failed) (0.00%)
Ran 16 test cases (0 failed) (0.00%)

All 30 test cases from TestIntegerTypesExpr.py appear to have been omitted from
the total.

With run on only 3 test suites, both correctly count 16 test cases:

rm -f types/TestIntegerTypesExpr.py
./dotest.py -v --output-on-success --no-multiprocess:
Ran 16 tests in 21.426s
./dotest.py -v --output-on-success:
Testing: 3 test suites, 4 threads
Ran 6 tests in 7.245s
[TestFloatTypes.py PASSED]
Ran 6 tests in 11.474s
[TestFloatTypesExpr.py PASSED]
Ran 4 tests in 3.599s
[TestRecursiveTypes.py PASSED]
3 out of 3 test suites processed - TestRecursiveTypes.py
Ran 3 test suites (0 failed) (0.00%)
Ran 16 test cases (0 failed) (0.00%)

-- 
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] Testing through api vs. commands

2015-09-17 Thread Zachary Turner via lldb-dev 
On Thu, Sep 17, 2015 at 10:39 AM  wrote:

> On Thu, Sep 17, 2015 at 05:20:14PM +, Zachary Turner wrote:
> > > > a) they should be explicitly marked as interface tests.
> > > What's the decorator for this?
> >
> > There's not one currently.
>
> Will there be?
>
Whenever someone adds one :)  If you want to start doing this, it should be
fairly easy.  Even if the decorator doesn't do anything useful yet, you can
just put it in and start putting it on interface tests if you want to start
writing some.  I think earlier in the thread Jim agreed that it would be a
good idea to separate command and api tests at the file system level as
well.  So that's also something to think about if you plan to write some
tests like this.


>
> > > > d) Results of these interface tests should also not be *verified* by
> the
> > > > use of self.expect, but itself through the API.  (Relying on the
> text to
> > > be
> > > > formatted a specific way is obviously problematic, as opposed to just
> > > > verifying the actual state of the debugger)
> > >
> > > How do you rely "on the text to be formatted a specific way"?
> >
> > Quick example: One of the most common patterns in the test are to do some
> > things, print a backtrace, and run a regex against the output of the
> > backtrace.   I've found at least 3 different examples of how this causes
> > things to fail on Windows:
>
> Oh, I misunderstood your point.  You're saying the existing tests rely
> "on the text to be formatted a specific way".  Right.
>
> I was asking how you *could* make sure the output was formatted a
> specific way using the Python API.
>

I'm actually not that convinced it's super useful.  Other people might
disagree, but I'll let them chime in.  Personally I think it's much more
useful to verify that typing a command with certain options affects the
state of the debugger in the expected way.  Right now the way we verify
this is by looking at the formatted output.  But another way (albeit much
more work to get going) would be to have the command objects and the SB
classes both be backed by the same classes that implement the commands (I
admit I'm handwaving a little here)

This way your core functionality tests uses the python api and verifies the
state of the debugger using the SB API, and your command tests simply
process a command and get back some sort of configuration structure, and
all you have to do is verify that the configuration structure is filled out
correctly.  Since the core functionality tests already verified that the
functionality works if passed an appropriate configuration structure, you
don't need the command tests to actually do any work or manipulate the
debugger.

Anyway, this is just a high level idea that probably needs refinement.  I'm
mostly just brainstorming.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev