Re: [lldb-dev] SB API is not working properly with OSPython plugin

2019-02-14 Thread Jim Ingham via lldb-dev 
Your plugin should have set the private state to stopped when it figures out 
however it does that the process has stopped.  The API is 
Process::SetPrivateState.  Is that happening at the right time?

Jim


> On Feb 14, 2019, at 1:50 PM, Alexander Polyakov  
> wrote:
> 
> I found out that the plugin works well with an x86 application, so I think 
> that the problem is in my process plugin. Maybe you know a place where to 
> start looking for an issue?
> 
> On Thu, Feb 14, 2019 at 10:56 PM Jim Ingham  > wrote:
> The simplest thing possible to reproduce the failure.  So some OS_Plugin 
> implementation which tries to look up a global like this and fails, and some 
> program source I can run it under that provides said global.  That way I can 
> easily watch it fails as you describe when the plugin gets activated, and see 
> why it isn’t allowing this call on private stop.
> 
> Jim
> 
> 
>> On Feb 14, 2019, at 11:50 AM, Alexander Polyakov > > wrote:
>> 
>> Sure, could you describe in more detail which example may help you?
>> 
>> чт, 14 февр. 2019 г. в 22:36, Jim Ingham > >:
>> That’s a little complicated…  
>> 
>> lldb has two levels of stop state - private stops and public stops.  When 
>> the process gets notification from the underlying process plugin that the 
>> process stopped, it raises a private stop event.  That gets handled by the 
>> ShouldStop mechanism on the private state thread in lldb, and then if the 
>> stop is judged interesting to the user, it gets rebroadcast as a public stop.
>> 
>> For instance, when you issue a “step” command, lldb will stop and start the 
>> process multiple times as it walks through the source line.  But only the 
>> last of those stops are relevant to the user of LLDB, so all the other ones 
>> exist only as private stops.
>> 
>> The SB API’s for the most part should only consider a “publicly stopped” 
>> process accessible.  After all, you wouldn’t want some API to succeed 
>> sometimes if you happen to catch it in the middle of a private stop.
>> 
>> But the OperatingSystem plugin needs to get called right after a private 
>> stop, so it can provide threads for the ShouldStop mechanism.  We should 
>> really have some formal mechanism whereby things like the OS plugin can 
>> request elevated rights in the SB API’s, so that they can run at private 
>> stop time.  IIRC, we instead have a hack where SB API calls that run on the 
>> private state thread are blanket allowed to run at private stop.  The xnu 
>> Operating System plugin successfully gets global values to look up its 
>> threads.  So I’m not sure why that isn’t working for you.
>> 
>> Can you cook up a simple example showing the failure and I’ll have a look?
>> 
>> Jim
>> 
>> 
>>> On Feb 14, 2019, at 11:10 AM, Alexander Polyakov >> > wrote:
>>> 
>>> It is, the error is: error: error: process must be stopped.
>>> 
>>> I thought that the plugin (get_thread_info in my case) is invoked when the 
>>> process is already stopped, but it's not. Is it ok?
>>> 
>>> On Thu, Feb 14, 2019 at 9:53 PM Jim Ingham >> > wrote:
>>> All SBValues have an error in them (SBValue.GetError).  Does that say 
>>> anything interesting?
>>> 
>>> Jim
>>>   
>>> 
>>> 
>>> 
 On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev 
 mailto:lldb-dev@lists.llvm.org>> wrote:
 
 Hi lldb-dev,
 
 I work on a custom implementation of OperatingSystem plugin using Python 
 and SB API. I’m trying to fetch information about some variables from the 
 target into the plugin, to do that I’m using the following Python code:
 ready_tasks = self._target.FindGlobalVariables(‘pxReadyTasksLists’, 
 1).GetValueAtIndex(0)
  
 When I do `print(ready_tasks)` I get:
 No value
  
 At the same time, doing the same actions inside lldb embedded interpreter 
 follows to:
 ` 
 print(lldb.target.FindGlobalVariables('pxReadyTasksLists',1).GetValueAtIndex(0))`
  
 (List_t [5]) pxReadyTasksLists = {
   [0] = {
 uxNumberOfItems = 0
 pxIndex = 0x
 xListEnd = {
   xItemValue = 0
   pxNext = 0x
   pxPrevious = 0x
 }
   }
 …
  
 Does anybody know what may cause such a behavior?
 
 -- 
 Alexander
 ___
 lldb-dev mailing list
 lldb-dev@lists.llvm.org 
 https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
 
>>> 
>>> 
>>> 
>>> -- 
>>> Alexander
>> 
>> -- 
>> Alexander
> 
> 
> 
> -- 
> Alexander

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

Re: [lldb-dev] SB API is not working properly with OSPython plugin

2019-02-14 Thread Alexander Polyakov via lldb-dev 
I found out that the plugin works well with an x86 application, so I think
that the problem is in my process plugin. Maybe you know a place where to
start looking for an issue?

On Thu, Feb 14, 2019 at 10:56 PM Jim Ingham  wrote:

> The simplest thing possible to reproduce the failure.  So some OS_Plugin
> implementation which tries to look up a global like this and fails, and
> some program source I can run it under that provides said global.  That way
> I can easily watch it fails as you describe when the plugin gets activated,
> and see why it isn’t allowing this call on private stop.
>
> Jim
>
>
> On Feb 14, 2019, at 11:50 AM, Alexander Polyakov 
> wrote:
>
> Sure, could you describe in more detail which example may help you?
>
> чт, 14 февр. 2019 г. в 22:36, Jim Ingham :
>
>> That’s a little complicated…
>>
>> lldb has two levels of stop state - private stops and public stops.  When
>> the process gets notification from the underlying process plugin that the
>> process stopped, it raises a private stop event.  That gets handled by the
>> ShouldStop mechanism on the private state thread in lldb, and then if the
>> stop is judged interesting to the user, it gets rebroadcast as a public
>> stop.
>>
>> For instance, when you issue a “step” command, lldb will stop and start
>> the process multiple times as it walks through the source line.  But only
>> the last of those stops are relevant to the user of LLDB, so all the other
>> ones exist only as private stops.
>>
>> The SB API’s for the most part should only consider a “publicly stopped”
>> process accessible.  After all, you wouldn’t want some API to succeed
>> sometimes if you happen to catch it in the middle of a private stop.
>>
>> But the OperatingSystem plugin needs to get called right after a private
>> stop, so it can provide threads for the ShouldStop mechanism.  We should
>> really have some formal mechanism whereby things like the OS plugin can
>> request elevated rights in the SB API’s, so that they can run at private
>> stop time.  IIRC, we instead have a hack where SB API calls that run on the
>> private state thread are blanket allowed to run at private stop.  The xnu
>> Operating System plugin successfully gets global values to look up its
>> threads.  So I’m not sure why that isn’t working for you.
>>
>> Can you cook up a simple example showing the failure and I’ll have a look?
>>
>> Jim
>>
>>
>> On Feb 14, 2019, at 11:10 AM, Alexander Polyakov 
>> wrote:
>>
>> It is, the error is: *error: error: process must be stopped.*
>>
>> I thought that the plugin (get_thread_info in my case) is invoked when
>> the process is already stopped, but it's not. Is it ok?
>>
>> On Thu, Feb 14, 2019 at 9:53 PM Jim Ingham  wrote:
>>
>>> All SBValues have an error in them (SBValue.GetError).  Does that say
>>> anything interesting?
>>>
>>> Jim
>>>
>>>
>>>
>>>
>>> On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev <
>>> lldb-dev@lists.llvm.org> wrote:
>>>
>>> Hi lldb-dev,
>>>
>>> I work on a custom implementation of OperatingSystem plugin using Python
>>> and SB API. I’m trying to fetch information about some variables from the
>>> target into the plugin, to do that I’m using the following Python code:
>>> ready_tasks = self._target.FindGlobalVariables(‘pxReadyTasksLists’,
>>> 1).GetValueAtIndex(0)
>>>
>>>
>>> When I do `print(ready_tasks)` I get:
>>> No value
>>>
>>>
>>> At the same time, doing the same actions inside lldb embedded
>>> interpreter follows to:
>>> `
>>> print(lldb.target.FindGlobalVariables('pxReadyTasksLists',1).GetValueAtIndex(0))`
>>>
>>>
>>> (List_t [5]) pxReadyTasksLists = {
>>>   [0] = {
>>> uxNumberOfItems = 0
>>> pxIndex = 0x
>>> xListEnd = {
>>>   xItemValue = 0
>>>   pxNext = 0x
>>>   pxPrevious = 0x
>>> }
>>>   }
>>> …
>>>
>>>
>>> Does anybody know what may cause such a behavior?
>>>
>>> --
>>> Alexander
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>>
>>>
>>
>> --
>> Alexander
>>
>>
>> --
> Alexander
>
>
>

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

Re: [lldb-dev] SB API is not working properly with OSPython plugin

2019-02-14 Thread Jim Ingham via lldb-dev 
The simplest thing possible to reproduce the failure.  So some OS_Plugin 
implementation which tries to look up a global like this and fails, and some 
program source I can run it under that provides said global.  That way I can 
easily watch it fails as you describe when the plugin gets activated, and see 
why it isn’t allowing this call on private stop.

Jim


> On Feb 14, 2019, at 11:50 AM, Alexander Polyakov  
> wrote:
> 
> Sure, could you describe in more detail which example may help you?
> 
> чт, 14 февр. 2019 г. в 22:36, Jim Ingham  >:
> That’s a little complicated…  
> 
> lldb has two levels of stop state - private stops and public stops.  When the 
> process gets notification from the underlying process plugin that the process 
> stopped, it raises a private stop event.  That gets handled by the ShouldStop 
> mechanism on the private state thread in lldb, and then if the stop is judged 
> interesting to the user, it gets rebroadcast as a public stop.
> 
> For instance, when you issue a “step” command, lldb will stop and start the 
> process multiple times as it walks through the source line.  But only the 
> last of those stops are relevant to the user of LLDB, so all the other ones 
> exist only as private stops.
> 
> The SB API’s for the most part should only consider a “publicly stopped” 
> process accessible.  After all, you wouldn’t want some API to succeed 
> sometimes if you happen to catch it in the middle of a private stop.
> 
> But the OperatingSystem plugin needs to get called right after a private 
> stop, so it can provide threads for the ShouldStop mechanism.  We should 
> really have some formal mechanism whereby things like the OS plugin can 
> request elevated rights in the SB API’s, so that they can run at private stop 
> time.  IIRC, we instead have a hack where SB API calls that run on the 
> private state thread are blanket allowed to run at private stop.  The xnu 
> Operating System plugin successfully gets global values to look up its 
> threads.  So I’m not sure why that isn’t working for you.
> 
> Can you cook up a simple example showing the failure and I’ll have a look?
> 
> Jim
> 
> 
>> On Feb 14, 2019, at 11:10 AM, Alexander Polyakov > > wrote:
>> 
>> It is, the error is: error: error: process must be stopped.
>> 
>> I thought that the plugin (get_thread_info in my case) is invoked when the 
>> process is already stopped, but it's not. Is it ok?
>> 
>> On Thu, Feb 14, 2019 at 9:53 PM Jim Ingham > > wrote:
>> All SBValues have an error in them (SBValue.GetError).  Does that say 
>> anything interesting?
>> 
>> Jim
>>   
>> 
>> 
>> 
>>> On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev 
>>> mailto:lldb-dev@lists.llvm.org>> wrote:
>>> 
>>> Hi lldb-dev,
>>> 
>>> I work on a custom implementation of OperatingSystem plugin using Python 
>>> and SB API. I’m trying to fetch information about some variables from the 
>>> target into the plugin, to do that I’m using the following Python code:
>>> ready_tasks = self._target.FindGlobalVariables(‘pxReadyTasksLists’, 
>>> 1).GetValueAtIndex(0)
>>>  
>>> When I do `print(ready_tasks)` I get:
>>> No value
>>>  
>>> At the same time, doing the same actions inside lldb embedded interpreter 
>>> follows to:
>>> ` 
>>> print(lldb.target.FindGlobalVariables('pxReadyTasksLists',1).GetValueAtIndex(0))`
>>>  
>>> (List_t [5]) pxReadyTasksLists = {
>>>   [0] = {
>>> uxNumberOfItems = 0
>>> pxIndex = 0x
>>> xListEnd = {
>>>   xItemValue = 0
>>>   pxNext = 0x
>>>   pxPrevious = 0x
>>> }
>>>   }
>>> …
>>>  
>>> Does anybody know what may cause such a behavior?
>>> 
>>> -- 
>>> Alexander
>>> ___
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org 
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>>> 
>> 
>> 
>> 
>> -- 
>> Alexander
> 
> -- 
> Alexander

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

Re: [lldb-dev] SB API is not working properly with OSPython plugin

2019-02-14 Thread Alexander Polyakov via lldb-dev 
Sure, could you describe in more detail which example may help you?

чт, 14 февр. 2019 г. в 22:36, Jim Ingham :

> That’s a little complicated…
>
> lldb has two levels of stop state - private stops and public stops.  When
> the process gets notification from the underlying process plugin that the
> process stopped, it raises a private stop event.  That gets handled by the
> ShouldStop mechanism on the private state thread in lldb, and then if the
> stop is judged interesting to the user, it gets rebroadcast as a public
> stop.
>
> For instance, when you issue a “step” command, lldb will stop and start
> the process multiple times as it walks through the source line.  But only
> the last of those stops are relevant to the user of LLDB, so all the other
> ones exist only as private stops.
>
> The SB API’s for the most part should only consider a “publicly stopped”
> process accessible.  After all, you wouldn’t want some API to succeed
> sometimes if you happen to catch it in the middle of a private stop.
>
> But the OperatingSystem plugin needs to get called right after a private
> stop, so it can provide threads for the ShouldStop mechanism.  We should
> really have some formal mechanism whereby things like the OS plugin can
> request elevated rights in the SB API’s, so that they can run at private
> stop time.  IIRC, we instead have a hack where SB API calls that run on the
> private state thread are blanket allowed to run at private stop.  The xnu
> Operating System plugin successfully gets global values to look up its
> threads.  So I’m not sure why that isn’t working for you.
>
> Can you cook up a simple example showing the failure and I’ll have a look?
>
> Jim
>
>
> On Feb 14, 2019, at 11:10 AM, Alexander Polyakov 
> wrote:
>
> It is, the error is: *error: error: process must be stopped.*
>
> I thought that the plugin (get_thread_info in my case) is invoked when the
> process is already stopped, but it's not. Is it ok?
>
> On Thu, Feb 14, 2019 at 9:53 PM Jim Ingham  wrote:
>
>> All SBValues have an error in them (SBValue.GetError).  Does that say
>> anything interesting?
>>
>> Jim
>>
>>
>>
>>
>> On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>> Hi lldb-dev,
>>
>> I work on a custom implementation of OperatingSystem plugin using Python
>> and SB API. I’m trying to fetch information about some variables from the
>> target into the plugin, to do that I’m using the following Python code:
>> ready_tasks = self._target.FindGlobalVariables(‘pxReadyTasksLists’,
>> 1).GetValueAtIndex(0)
>>
>>
>> When I do `print(ready_tasks)` I get:
>> No value
>>
>>
>> At the same time, doing the same actions inside lldb embedded interpreter
>> follows to:
>> `
>> print(lldb.target.FindGlobalVariables('pxReadyTasksLists',1).GetValueAtIndex(0))`
>>
>>
>> (List_t [5]) pxReadyTasksLists = {
>>   [0] = {
>> uxNumberOfItems = 0
>> pxIndex = 0x
>> xListEnd = {
>>   xItemValue = 0
>>   pxNext = 0x
>>   pxPrevious = 0x
>> }
>>   }
>> …
>>
>>
>> Does anybody know what may cause such a behavior?
>>
>> --
>> Alexander
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
>
> --
> Alexander
>
>
> --
Alexander
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] SB API is not working properly with OSPython plugin

2019-02-14 Thread Jim Ingham via lldb-dev 
That’s a little complicated…  

lldb has two levels of stop state - private stops and public stops.  When the 
process gets notification from the underlying process plugin that the process 
stopped, it raises a private stop event.  That gets handled by the ShouldStop 
mechanism on the private state thread in lldb, and then if the stop is judged 
interesting to the user, it gets rebroadcast as a public stop.

For instance, when you issue a “step” command, lldb will stop and start the 
process multiple times as it walks through the source line.  But only the last 
of those stops are relevant to the user of LLDB, so all the other ones exist 
only as private stops.

The SB API’s for the most part should only consider a “publicly stopped” 
process accessible.  After all, you wouldn’t want some API to succeed sometimes 
if you happen to catch it in the middle of a private stop.

But the OperatingSystem plugin needs to get called right after a private stop, 
so it can provide threads for the ShouldStop mechanism.  We should really have 
some formal mechanism whereby things like the OS plugin can request elevated 
rights in the SB API’s, so that they can run at private stop time.  IIRC, we 
instead have a hack where SB API calls that run on the private state thread are 
blanket allowed to run at private stop.  The xnu Operating System plugin 
successfully gets global values to look up its threads.  So I’m not sure why 
that isn’t working for you.

Can you cook up a simple example showing the failure and I’ll have a look?

Jim


> On Feb 14, 2019, at 11:10 AM, Alexander Polyakov  
> wrote:
> 
> It is, the error is: error: error: process must be stopped.
> 
> I thought that the plugin (get_thread_info in my case) is invoked when the 
> process is already stopped, but it's not. Is it ok?
> 
> On Thu, Feb 14, 2019 at 9:53 PM Jim Ingham  > wrote:
> All SBValues have an error in them (SBValue.GetError).  Does that say 
> anything interesting?
> 
> Jim
>   
> 
> 
> 
>> On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev 
>> mailto:lldb-dev@lists.llvm.org>> wrote:
>> 
>> Hi lldb-dev,
>> 
>> I work on a custom implementation of OperatingSystem plugin using Python and 
>> SB API. I’m trying to fetch information about some variables from the target 
>> into the plugin, to do that I’m using the following Python code:
>> ready_tasks = self._target.FindGlobalVariables(‘pxReadyTasksLists’, 
>> 1).GetValueAtIndex(0)
>>  
>> When I do `print(ready_tasks)` I get:
>> No value
>>  
>> At the same time, doing the same actions inside lldb embedded interpreter 
>> follows to:
>> ` 
>> print(lldb.target.FindGlobalVariables('pxReadyTasksLists',1).GetValueAtIndex(0))`
>>  
>> (List_t [5]) pxReadyTasksLists = {
>>   [0] = {
>> uxNumberOfItems = 0
>> pxIndex = 0x
>> xListEnd = {
>>   xItemValue = 0
>>   pxNext = 0x
>>   pxPrevious = 0x
>> }
>>   }
>> …
>>  
>> Does anybody know what may cause such a behavior?
>> 
>> -- 
>> Alexander
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org 
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev 
>> 
> 
> 
> 
> -- 
> Alexander

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

[lldb-dev] how to set a watchpoint on an "unsigned short" parameter ?

2019-02-14 Thread Jason Vas Dias via lldb-dev 
Good day -

  I'd be most grateful if anyone could enlighten me as to how
  to set a watchpoint on an unsigned short parameter variable
  in lldb .

  I am trying to follow the instructions at :
https://lldb.llvm.org/lldb-gdb.html
  but they do not work to set watchpoints.

  There seems to be no other documentation for LLDB commands -
  or if anyone knows of any , please let me know.

  I have a function like :
void f ( unsigned short x )
{  }

  With the debugger stopped inside f, I have tried:

   (lldb)  p &x
   (uint16_t *) $3 = 0x0001001122c0
   (lldb) wa s v -s 2 -w write 0x0001001122c0
   error: no variable named '0x0001001122c0' found in this frame
   (lldb) wa s v -s 2 -w write x
   error: Watchpoint creation failed (addr=0x, size=0,
variable
   expression='x').
   error: cannot set a watchpoint with watch_size of 0
   (lldb) wa s e -s 2 -w write 0x0001001122c0
   error: expression evaluation of address to watch failed
   expression evaluated: -s 2 -w write 0x0001001122c0
   (lldb) wa s e -s 2 -w write *0x0001001122c0
   error: expression evaluation of address to watch failed
   expression evaluated: -s 2 -w write *0x0001001122c0
   (lldb) wa s e -s 2 -w write ((unsigned short*)0x0001001122c0)
   error: expression evaluation of address to watch failed
   expression evaluated: -s 2 -w write ((unsigned short*)0x0001001122c0)
   (lldb) wa s v -s 2 -w write &x
   error: 'x' doesn't have a valid address
   # ^- this error is really strange, particularly as I can do:
   (lldb) p &x
   (uint16_t *) $5 = 0x0001001122c0

  It seems to me lldb's implementation of watch points is fundamentally broken -
  there is no way I've been able to get it to work .

  Unfortunately, I have to use MacOSX, so gdb is not available.

  Please, can anyone suggest how to successfully set a watchpoint on
  a parameter (stack) located variable value with lldb ?
  It does not seem to be possible.

  My next step, if no answers to this mail, would be to analyse the LLDB
  source code to see if I can figure out how watchpoints are meant to
  be set, seeing as there is no reference documentation for LLDB commands,
  either installed as manual pages or online.  This to me makes LLDB unsuitable
  for production use, but unforunately I have to use it (I need to debug under
  MacOSX 10,14.3 ).

   The help output for is of no use either:
   (lldb) help watch set
   "Syntax: watchpoint set  []
The following subcommands are supported:
  expression -- Set a watchpoint on an address by supplying an
expression. Use the
  '-w' option to specify the type of watchpoint and the '-s'
option to specify the
  byte size to watch for.
"
The above statement is provably false:
 (lldb) wa s v -s 2 x
 error: Watchpoint creation failed (addr=0x, size=0,
   variable expression='x').
 error: cannot set a watchpoint with watch_size of 0
 # maybe the -s option goes after the 'set' ? no:
(lldb) wa s -s 2 v reader_id
invalid command 'watchpoint set -s'.

All attempts to
 "Use the '-w' option to specify the type of watchpoint and the
'-s' option to
  specify the byte size to watch for.
 "
fail,  so there must be alot missing from the help description.

The help for the variable syntax is also vague, and provably false :
 "variable   -- Set a watchpoint on a variable. Use the '-w'
option to specify the type
 of watchpoint and the '-s' option to specify the
byte size to watch for.
If no '-w' option is specified, it defaults to
write. If no '-s' option is
specified, it defaults to the variable's byte
size. Note that there are
limited hardware resources for watchpoints. If
watchpoint setting
fails, consider disable/delete existing ones to
free up resources.

  (lldb) wa s v x
  error: Watchpoint creation failed (addr=0x,
size=0, variable
expression='x').
  error: cannot set a watchpoint with watch_size of 0
  (lldb) wa s -s 2 v x
  invalid command 'watchpoint set -s'.
  (lldb) wa s v -s 2 x
  error: Watchpoint creation failed (addr=0x,
size=0, variable
expression='x').
  error: cannot set a watchpoint with watch_size of 0

   So lldb's watch command can neither get the size from a '-s' option, nor can
   it get the size from sizeof(variable) . How then is one meant to
set the size ?

   Obviously, lldb's watchpoint implementation needs much further work - has
   anyone been able to get it to do anything useful ? If so, please
let me know how,
   and what.

   If there is any reference documentation for lldb, besides the false
and misleading
   'https://lldb.llvm.org/lldb-gdb.html', which actually describes in detail and
   correctly the syntax of every lldb command, please let me know.

   Any idea

Re: [lldb-dev] SB API is not working properly with OSPython plugin

2019-02-14 Thread Alexander Polyakov via lldb-dev 
It is, the error is: *error: error: process must be stopped.*

I thought that the plugin (get_thread_info in my case) is invoked when the
process is already stopped, but it's not. Is it ok?

On Thu, Feb 14, 2019 at 9:53 PM Jim Ingham  wrote:

> All SBValues have an error in them (SBValue.GetError).  Does that say
> anything interesting?
>
> Jim
>
>
>
>
> On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
> Hi lldb-dev,
>
> I work on a custom implementation of OperatingSystem plugin using Python
> and SB API. I’m trying to fetch information about some variables from the
> target into the plugin, to do that I’m using the following Python code:
> ready_tasks = self._target.FindGlobalVariables(‘pxReadyTasksLists’,
> 1).GetValueAtIndex(0)
>
>
> When I do `print(ready_tasks)` I get:
> No value
>
>
> At the same time, doing the same actions inside lldb embedded interpreter
> follows to:
> `
> print(lldb.target.FindGlobalVariables('pxReadyTasksLists',1).GetValueAtIndex(0))`
>
>
> (List_t [5]) pxReadyTasksLists = {
>   [0] = {
> uxNumberOfItems = 0
> pxIndex = 0x
> xListEnd = {
>   xItemValue = 0
>   pxNext = 0x
>   pxPrevious = 0x
> }
>   }
> …
>
>
> Does anybody know what may cause such a behavior?
>
> --
> Alexander
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
>

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

Re: [lldb-dev] SB API is not working properly with OSPython plugin

2019-02-14 Thread Jim Ingham via lldb-dev 
All SBValues have an error in them (SBValue.GetError).  Does that say anything 
interesting?

Jim
  



> On Feb 14, 2019, at 10:08 AM, Alexander Polyakov via lldb-dev 
>  wrote:
> 
> Hi lldb-dev,
> 
> I work on a custom implementation of OperatingSystem plugin using Python and 
> SB API. I’m trying to fetch information about some variables from the target 
> into the plugin, to do that I’m using the following Python code:
> ready_tasks = self._target.FindGlobalVariables(‘pxReadyTasksLists’, 
> 1).GetValueAtIndex(0)
>  
> When I do `print(ready_tasks)` I get:
> No value
>  
> At the same time, doing the same actions inside lldb embedded interpreter 
> follows to:
> ` 
> print(lldb.target.FindGlobalVariables('pxReadyTasksLists',1).GetValueAtIndex(0))`
>  
> (List_t [5]) pxReadyTasksLists = {
>   [0] = {
> uxNumberOfItems = 0
> pxIndex = 0x
> xListEnd = {
>   xItemValue = 0
>   pxNext = 0x
>   pxPrevious = 0x
> }
>   }
> …
>  
> Does anybody know what may cause such a behavior?
> 
> -- 
> Alexander
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

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

[lldb-dev] SB API is not working properly with OSPython plugin

2019-02-14 Thread Alexander Polyakov via lldb-dev 
Hi lldb-dev,

I work on a custom implementation of OperatingSystem plugin using Python
and SB API. I’m trying to fetch information about some variables from the
target into the plugin, to do that I’m using the following Python code:

ready_tasks = self._target.FindGlobalVariables(‘pxReadyTasksLists’,
1).GetValueAtIndex(0)



When I do `print(ready_tasks)` I get:

No value



At the same time, doing the same actions inside lldb embedded interpreter
follows to:

`
print(lldb.target.FindGlobalVariables('pxReadyTasksLists',1).GetValueAtIndex(0))`



(List_t [5]) pxReadyTasksLists = {

  [0] = {

uxNumberOfItems = 0

pxIndex = 0x

xListEnd = {

  xItemValue = 0

  pxNext = 0x

  pxPrevious = 0x

}

  }

…



Does anybody know what may cause such a behavior?

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

Re: [lldb-dev] [Release-testers] [8.0.0 Release] rc2 has been tagged

2019-02-14 Thread Hans Wennborg via lldb-dev 
On Wed, Feb 13, 2019 at 9:39 PM Dimitry Andric 
wrote:>> On 7 Feb 2019, at 16:41, Hans Wennborg via Release-testers
 wrote:> > 8.0.0-rc2 has been tagged
from the release_80 branch at r353413.> >> > Please run the test
script, share your results, and upload binaries.>> Unfortunately I had
to disable compiler-rt for this test run, as most of the sanitizers
are totally broken.  They get into an endless recursive loop between
AsanTSDGet() and the __tls_get_addr() interceptor, and crash with
DEADLYSIGNAL due to stack overflow.  I haven't found the time to
further diagnose this.:-/ I don't remember hearing this before, so
sounds like it's a regression from rc1? Even if you don't have time to
investigate right now, can you please file a bug to make sure I don't
forget?

>
> Main test results on amd64-freebsd11:
>
>   Expected Passes: 53882
>   Expected Failures  : 220
>   Unsupported Tests  : 1081
>   Unresolved Tests   : 10
>   Unexpected Passes  : 3
>   Unexpected Failures: 60
>
> Main test results on i386-freebsd11:
>
>   Expected Passes: 53729
>   Expected Failures  : 236
>   Unsupported Tests  : 903
>   Unresolved Tests   : 10
>   Unexpected Passes  : 5
>   Unexpected Failures: 178
>
> The unresolved tests are due to a number of tests hanging in  state, 
> forcing me to kill their parent .py processes.
>
> Uploaded:
>
> SHA256 (clang+llvm-8.0.0-rc2-amd64-unknown-freebsd11.tar.xz) = 
> 81673933ecd33f22f45a3ffa4558f3a23e9dbb8c3a0255ec831c8dd6c97b0bae
> SHA256 (clang+llvm-8.0.0-rc2-i386-unknown-freebsd11.tar.xz) = 
> 663f340568a5c06470616008cdd7c5c118eb64d6acfc80009d5cc2b596fb6242

Added to the pre-release page.

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev