[lldb-dev] [RFC] OS Awareness in LLDB
Hi lldb-dev, I'm a senior student at Saint Petersburg State University. The one of my possible diploma themes is "OS Awareness in LLDB". Generally, the OS awareness extends a debugger to provide a representation of the OS threads - or tasks - and other relevant data structures, typically semaphores, mutexes, or queues. I want to ask the community if OS awareness is interesting for LLDB users and developers? The main goal is to create some base on top of LLDB that can be extended to support awareness for different operating systems. Also, if you have a good article or other useful information about OS awareness, please share it with me. Thanks in advance! -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] OS Awareness in LLDB
Hi Leonard, I think it will be kernel-mode debugging since debugging an application in user mode is not an OS awareness imo. Of course, some of kernel's modules might run in user-mode, but it will be ok I think. Thanks for your reference, I'll take a look at it. Also, I found out that ARM supports OS awareness in their DS-5 debugger. They have a mechanism for adding new operating systems. All you need to do is to describe OS' model (thread's or task's structure for example). I think that is how it might be done in LLDB. On Wed, Oct 31, 2018 at 9:26 PM Leonard Mosescu wrote: > Hi Alexander, are you interested in user-mode, kernel-mode debugging or > both? > > Fore reference, the current state of the art regarding OS-awareness > debugging is debugging tools for windows > <https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/index> > (windbg > & co.). This is not surprising since the tools were developed alongside > Windows. Obviously they are specific to Windows, but it's good example of > how the OS-awareness might look like. > > > On Mon, Oct 29, 2018 at 11:37 AM, Alexander Polyakov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi lldb-dev, >> >> I'm a senior student at Saint Petersburg State University. The one of my >> possible diploma themes is "OS Awareness in LLDB". Generally, the OS >> awareness extends a debugger to provide a representation of the OS threads >> - or tasks - and other relevant data structures, typically semaphores, >> mutexes, or queues. >> >> I want to ask the community if OS awareness is interesting for LLDB users >> and developers? The main goal is to create some base on top of LLDB that >> can be extended to support awareness for different operating systems. >> >> Also, if you have a good article or other useful information about OS >> awareness, please share it with me. >> >> Thanks in advance! >> >> -- >> Alexander >> >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> > -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] OS Awareness in LLDB
Looks like I don't completely understand what is the difference between user-mode and kernel-mode from the debugger's point of view. Could you please explain me this? On Wed, Oct 31, 2018 at 10:22 PM Zachary Turner wrote: > I don’t totally agree with this. I think there are a lot of useful os > awareness tasks in user mode. For example, you’re debugging a deadlock and > want to understand the state of other mutexes, who owns them, etc. or you > want to examine open file descriptors. In the case of a heap corruption you > may wish to study the internal structures of your process’s heap, or even > lower level, the os virtual memory page table structures. > > There’s quite a lot you can still do in user mode, but definitely there is > more in kernel mode. As Leonard said, try put WinDbg as a lot of this stuff > already exists so it’s a good reference > On Wed, Oct 31, 2018 at 12:08 PM Alexander Polyakov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >> Hi Leonard, >> >> I think it will be kernel-mode debugging since debugging an application >> in user mode is not an OS awareness imo. Of course, some of kernel's >> modules might run in user-mode, but it will be ok I think. >> >> Thanks for your reference, I'll take a look at it. >> >> Also, I found out that ARM supports OS awareness in their DS-5 debugger. >> They have a mechanism for adding new operating systems. All you need to do >> is to describe OS' model (thread's or task's structure for example). I >> think that is how it might be done in LLDB. >> >> On Wed, Oct 31, 2018 at 9:26 PM Leonard Mosescu >> wrote: >> >>> Hi Alexander, are you interested in user-mode, kernel-mode debugging or >>> both? >>> >>> Fore reference, the current state of the art regarding OS-awareness >>> debugging is debugging tools for windows >>> <https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/index> >>> (windbg >>> & co.). This is not surprising since the tools were developed alongside >>> Windows. Obviously they are specific to Windows, but it's good example of >>> how the OS-awareness might look like. >>> >>> >>> On Mon, Oct 29, 2018 at 11:37 AM, Alexander Polyakov via lldb-dev < >>> lldb-dev@lists.llvm.org> wrote: >>> >>>> Hi lldb-dev, >>>> >>>> I'm a senior student at Saint Petersburg State University. The one of >>>> my possible diploma themes is "OS Awareness in LLDB". Generally, the OS >>>> awareness extends a debugger to provide a representation of the OS threads >>>> - or tasks - and other relevant data structures, typically semaphores, >>>> mutexes, or queues. >>>> >>>> I want to ask the community if OS awareness is interesting for LLDB >>>> users and developers? The main goal is to create some base on top of LLDB >>>> that can be extended to support awareness for different operating systems. >>>> >>>> Also, if you have a good article or other useful information about OS >>>> awareness, please share it with me. >>>> >>>> Thanks in advance! >>>> >>>> -- >>>> Alexander >>>> >>>> ___ >>>> lldb-dev mailing list >>>> lldb-dev@lists.llvm.org >>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >>>> >>>> >>> >> >> -- >> Alexander >> ___ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> > -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] OS Awareness in LLDB
So, if I understand you write, I can look at OS plugin and add a support of mutexes or memory pages for example? чт, 1 нояб. 2018 г. в 1:05, Jim Ingham : > lldb has one feature - the "Operating System Plugin" that is specifically > designed for debugging threads in kernel contexts. The OS plugin allows a > kernel to present it's notion of threads into lldb_private::Threads. The > xnu kernel macros have an implementation of this, as do some other embedded > OS'es. lldb actually gets used pretty extensively for debugging xnu - the > Darwin kernel. > > Kuba is adding the notion of "Frame recognizers" which can give > significance to particular functions when they appear on the stack (for > instance displaying the first argument of read, etc. as a file handle even > if you have no debug information for it.) That's another way that you > could express your understanding of the OS you are running on for debugger > users. Greg wrote a data formatter for the Darwin implementation of > pthread_mutex that shows the thread that has the lock and some other > information like that. So data formatters are also a way lldb can express > knowledge of the host OS. > > Jim > > > On Oct 31, 2018, at 12:52 PM, Leonard Mosescu via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Conceptually it's different levels of abstraction: a user-mode debugger > handles processes, threads as first class concepts. In kernel-mode (or > kernel land), these are just data structures that the code (the kernel) is > managing. From a more pragmatic perspective, the difference is in where the > debugging hooks are implemented and what interfaces are exposed (for > example a kernel mode debugger can normally "poke" around any piece of > memory and it has to be aware of things like VA mappings, while a user-mode > debugger is only allowed to control a limited slice of the system - ex. > control a sub-process through something like ptrace) > > > > Unless you're specifically looking at kernel debugging I'd stay away > from that. For one thing, LLDB is mostly used as an user-mode debugger so > the impact of any improvements would be bigger. > > > > Regarding the value of OS-awareness for user-mode debugging, I agree > with Zach - for example windbg provides both kernel mode and user mode > !locks commands. The only suggestion I'd add is to consider an expanded > view of the "OS" to include runtime components which may not be technically > part of what most people think of as the "OS": user-mode loaders and high > level things like std::mutex, etc. > > > > On Wed, Oct 31, 2018 at 12:29 PM, Alexander Polyakov < > polyakov@gmail.com> wrote: > > Looks like I don't completely understand what is the difference between > user-mode and kernel-mode from the debugger's point of view. Could you > please explain me this? > > > > On Wed, Oct 31, 2018 at 10:22 PM Zachary Turner > wrote: > > I don’t totally agree with this. I think there are a lot of useful os > awareness tasks in user mode. For example, you’re debugging a deadlock and > want to understand the state of other mutexes, who owns them, etc. or you > want to examine open file descriptors. In the case of a heap corruption you > may wish to study the internal structures of your process’s heap, or even > lower level, the os virtual memory page table structures. > > > > There’s quite a lot you can still do in user mode, but definitely there > is more in kernel mode. As Leonard said, try put WinDbg as a lot of this > stuff already exists so it’s a good reference > > On Wed, Oct 31, 2018 at 12:08 PM Alexander Polyakov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hi Leonard, > > > > I think it will be kernel-mode debugging since debugging an application > in user mode is not an OS awareness imo. Of course, some of kernel's > modules might run in user-mode, but it will be ok I think. > > > > Thanks for your reference, I'll take a look at it. > > > > Also, I found out that ARM supports OS awareness in their DS-5 debugger. > They have a mechanism for adding new operating systems. All you need to do > is to describe OS' model (thread's or task's structure for example). I > think that is how it might be done in LLDB. > > > > On Wed, Oct 31, 2018 at 9:26 PM Leonard Mosescu > wrote: > > Hi Alexander, are you interested in user-mode, kernel-mode debugging or > both? > > > > Fore reference, the current state of the art regarding OS-awareness > debugging is debugging tools for windows (windbg & co.). This is not > surpri
Re: [lldb-dev] [RFC] OS Awareness in LLDB
ally looking at kernel debugging I'd stay away > from that. For one thing, LLDB is mostly used as an user-mode debugger so > the impact of any improvements would be bigger. > >>> > >>> Regarding the value of OS-awareness for user-mode debugging, I agree > with Zach - for example windbg provides both kernel mode and user mode > !locks commands. The only suggestion I'd add is to consider an expanded > view of the "OS" to include runtime components which may not be technically > part of what most people think of as the "OS": user-mode loaders and high > level things like std::mutex, etc. > >>> > >>> On Wed, Oct 31, 2018 at 12:29 PM, Alexander Polyakov < > polyakov@gmail.com> wrote: > >>> Looks like I don't completely understand what is the difference > between user-mode and kernel-mode from the debugger's point of view. Could > you please explain me this? > >>> > >>> On Wed, Oct 31, 2018 at 10:22 PM Zachary Turner > wrote: > >>> I don’t totally agree with this. I think there are a lot of useful os > awareness tasks in user mode. For example, you’re debugging a deadlock and > want to understand the state of other mutexes, who owns them, etc. or you > want to examine open file descriptors. In the case of a heap corruption you > may wish to study the internal structures of your process’s heap, or even > lower level, the os virtual memory page table structures. > >>> > >>> There’s quite a lot you can still do in user mode, but definitely > there is more in kernel mode. As Leonard said, try put WinDbg as a lot of > this stuff already exists so it’s a good reference > >>> On Wed, Oct 31, 2018 at 12:08 PM Alexander Polyakov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >>> Hi Leonard, > >>> > >>> I think it will be kernel-mode debugging since debugging an > application in user mode is not an OS awareness imo. Of course, some of > kernel's modules might run in user-mode, but it will be ok I think. > >>> > >>> Thanks for your reference, I'll take a look at it. > >>> > >>> Also, I found out that ARM supports OS awareness in their DS-5 > debugger. They have a mechanism for adding new operating systems. All you > need to do is to describe OS' model (thread's or task's structure for > example). I think that is how it might be done in LLDB. > >>> > >>> On Wed, Oct 31, 2018 at 9:26 PM Leonard Mosescu > wrote: > >>> Hi Alexander, are you interested in user-mode, kernel-mode debugging > or both? > >>> > >>> Fore reference, the current state of the art regarding OS-awareness > debugging is debugging tools for windows (windbg & co.). This is not > surprising since the tools were developed alongside Windows. Obviously they > are specific to Windows, but it's good example of how the OS-awareness > might look like. > >>> > >>> > >>> On Mon, Oct 29, 2018 at 11:37 AM, Alexander Polyakov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > >>> Hi lldb-dev, > >>> > >>> I'm a senior student at Saint Petersburg State University. The one of > my possible diploma themes is "OS Awareness in LLDB". Generally, the OS > awareness extends a debugger to provide a representation of the OS threads > - or tasks - and other relevant data structures, typically semaphores, > mutexes, or queues. > >>> > >>> I want to ask the community if OS awareness is interesting for LLDB > users and developers? The main goal is to create some base on top of LLDB > that can be extended to support awareness for different operating systems. > >>> > >>> Also, if you have a good article or other useful information about OS > awareness, please share it with me. > >>> > >>> Thanks in advance! > >>> > >>> -- > >>> Alexander > >>> > >>> ___ > >>> lldb-dev mailing list > >>> lldb-dev@lists.llvm.org > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >>> > >>> > >>> > >>> > >>> -- > >>> Alexander > >>> ___ > >>> lldb-dev mailing list > >>> lldb-dev@lists.llvm.org > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >>> > >>> > >>> -- > >>> Alexander > >>> > >>> ___ > >>> lldb-dev mailing list > >>> lldb-dev@lists.llvm.org > >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > >> > >> -- > >> Alexander > > > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] OS Awareness in LLDB
ldb actually gets used pretty >> extensively for debugging xnu - the Darwin kernel. >> >> >> >> Kuba is adding the notion of "Frame recognizers" which can give >> significance to particular functions when they appear on the stack (for >> instance displaying the first argument of read, etc. as a file handle even >> if you have no debug information for it.) That's another way that you >> could express your understanding of the OS you are running on for debugger >> users. Greg wrote a data formatter for the Darwin implementation of >> pthread_mutex that shows the thread that has the lock and some other >> information like that. So data formatters are also a way lldb can express >> knowledge of the host OS. >> >> >> >> Jim >> >> >> >>> On Oct 31, 2018, at 12:52 PM, Leonard Mosescu via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> >> >>> Conceptually it's different levels of abstraction: a user-mode >> debugger handles processes, threads as first class concepts. In kernel-mode >> (or kernel land), these are just data structures that the code (the kernel) >> is managing. From a more pragmatic perspective, the difference is in where >> the debugging hooks are implemented and what interfaces are exposed (for >> example a kernel mode debugger can normally "poke" around any piece of >> memory and it has to be aware of things like VA mappings, while a user-mode >> debugger is only allowed to control a limited slice of the system - ex. >> control a sub-process through something like ptrace) >> >>> >> >>> Unless you're specifically looking at kernel debugging I'd stay away >> from that. For one thing, LLDB is mostly used as an user-mode debugger so >> the impact of any improvements would be bigger. >> >>> >> >>> Regarding the value of OS-awareness for user-mode debugging, I agree >> with Zach - for example windbg provides both kernel mode and user mode >> !locks commands. The only suggestion I'd add is to consider an expanded >> view of the "OS" to include runtime components which may not be technically >> part of what most people think of as the "OS": user-mode loaders and high >> level things like std::mutex, etc. >> >>> >> >>> On Wed, Oct 31, 2018 at 12:29 PM, Alexander Polyakov < >> polyakov@gmail.com> wrote: >> >>> Looks like I don't completely understand what is the difference >> between user-mode and kernel-mode from the debugger's point of view. Could >> you please explain me this? >> >>> >> >>> On Wed, Oct 31, 2018 at 10:22 PM Zachary Turner >> wrote: >> >>> I don’t totally agree with this. I think there are a lot of useful os >> awareness tasks in user mode. For example, you’re debugging a deadlock and >> want to understand the state of other mutexes, who owns them, etc. or you >> want to examine open file descriptors. In the case of a heap corruption you >> may wish to study the internal structures of your process’s heap, or even >> lower level, the os virtual memory page table structures. >> >>> >> >>> There’s quite a lot you can still do in user mode, but definitely >> there is more in kernel mode. As Leonard said, try put WinDbg as a lot of >> this stuff already exists so it’s a good reference >> >>> On Wed, Oct 31, 2018 at 12:08 PM Alexander Polyakov via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> >>> Hi Leonard, >> >>> >> >>> I think it will be kernel-mode debugging since debugging an >> application in user mode is not an OS awareness imo. Of course, some of >> kernel's modules might run in user-mode, but it will be ok I think. >> >>> >> >>> Thanks for your reference, I'll take a look at it. >> >>> >> >>> Also, I found out that ARM supports OS awareness in their DS-5 >> debugger. They have a mechanism for adding new operating systems. All you >> need to do is to describe OS' model (thread's or task's structure for >> example). I think that is how it might be done in LLDB. >> >>> >> >>> On Wed, Oct 31, 2018 at 9:26 PM Leonard Mosescu >> wrote: >> >>> Hi Alexander, are you interested in user-mode, kernel-mode debugging >> or both? >> >>> >> >>> Fore reference, the current state of the art regarding OS-awareness >>
[lldb-dev] [RFC] Adding FreeRTOS platform
Hi lldb-dev, As part of my Bachelor's thesis, I'm going to add a new platform to LLDB (FreeRTOS in my case) to perform a kernel debugging. Is there a documentation about adding a new platform? As far as I know, my case is similar to PlatformDarwinKernel, so I need to do the similar things: 1) add FreeRTOS platform; 2) add FreeRTOSKernel platform; Am I right that I'll get the threads/tasks support "out-of-the-box" since it's already implemented in OperatingSystem plugin? -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Adding FreeRTOS platform
I found out that there will not be “out-of-the-box” threads/tasks support since the lldb doesn’t know anything about thread’s structure. It seems that to have it works I need to implement the OperatingSystem plugin for the specific OS. Is it right? If yes, is it enough? сб, 15 дек. 2018 г. в 16:45, Alexander Polyakov : > Hi lldb-dev, > > As part of my Bachelor's thesis, I'm going to add a new platform to LLDB > (FreeRTOS in my case) to perform a kernel debugging. Is there a > documentation about adding a new platform? > > As far as I know, my case is similar to PlatformDarwinKernel, so I need to > do the similar things: > 1) add FreeRTOS platform; > 2) add FreeRTOSKernel platform; > > Am I right that I'll get the threads/tasks support "out-of-the-box" since > it's already implemented in OperatingSystem plugin? > > -- > Alexander > -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] OperatingSystem plugin
Hi lldb-dev, Could someone explain me why do we use python (OperatingSystemPython) to describe OS objects like threads? What are the advantages of such an approach in comparison to C++ used in Platform plugin for example? IMO, the OperatingSystem plugin could be more like the Platform one, it could have a separate directory for each OS with its own implementation inside. -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] OperatingSystem plugin
Thank you Jim, It's much clearer for me now. As you might remember, we discussed an opportunity of adding new OS objects to LLDB, e.g. mutexes. The conclusion of our discussion was that if we want to do this, we should add such objects to Platform plugin, but is there a difference between threads and mutexes for example, both are OS specific data structures. Wouldn't it be better to delegate mutexes to OperatingSystem plugin? It could deal with them the same way as it deals with threads. On Thu, Dec 20, 2018 at 1:51 AM Jim Ingham wrote: > You would use an operating system plugin in cases where the underlying > process interface doesn't tell the complete story for the OS threads. For > instance, a lot of kernel and bare board OS'es have a gdb-remote stub that > just describes the state of the threads currently running on the cores of > the machine. Any swapped out threads are unknown to it. So the Operating > system plugin reconstructs the swapped out threads by looking at OS > specific data structures. > > We didn't think that lldb should own the support for every variant of > every OS which might want to reconstruct threads from some data structures > in the OS. After all, this isn't dealing with fairly stable API's - like > the Platforms do. The OS plugins deal with internal data structures, which > tend to change fairly frequently. So trying to package them with lldb > doesn't seem supportable. > > By making the OS plugin something that comes from outside lldb, we allow > the kernel developers to provide this knowledge on demand. That is very > convenient. For instance, on macOS, the dSYM bundle for the mach kernel > contains the Operating System plugin for that kernel. When lldb is used > for kernel debugging, it finds the dSYM associated with the kernel it is > targeting and loads in the python support from the dSYM. That way it is > ensured to get the correct plugin for that kernel. It also means that lldb > can support kernel versions that didn't even exist when it was made. > > As for why this is done with Python and not the C++ SB API's, there's > nothing to stop it from also being in C++, you can actually write loadable > C++ plugins with the SB API's for data formatters, for instance. But > there's generally no significant performance advantage to doing that, and > its less convenient, so there just hasn't been much demand for it. > > Jim > > > > On Dec 19, 2018, at 12:44 PM, Alexander Polyakov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hi lldb-dev, > > > > Could someone explain me why do we use python (OperatingSystemPython) to > describe OS objects like threads? What are the advantages of such an > approach in comparison to C++ used in Platform plugin for example? IMO, the > OperatingSystem plugin could be more like the Platform one, it could have a > separate directory for each OS with its own implementation inside. > > > > -- > > Alexander > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] OperatingSystem plugin
Gentle ping. On Thu, Dec 20, 2018 at 6:00 PM Alexander Polyakov wrote: > Thank you Jim, > > It's much clearer for me now. > > As you might remember, we discussed an opportunity of adding new OS > objects to LLDB, e.g. mutexes. The conclusion of our discussion was that if > we want to do this, we should add such objects to Platform plugin, but is > there a difference between threads and mutexes for example, both are OS > specific data structures. Wouldn't it be better to delegate mutexes to > OperatingSystem plugin? It could deal with them the same way as it deals > with threads. > > On Thu, Dec 20, 2018 at 1:51 AM Jim Ingham wrote: > >> You would use an operating system plugin in cases where the underlying >> process interface doesn't tell the complete story for the OS threads. For >> instance, a lot of kernel and bare board OS'es have a gdb-remote stub that >> just describes the state of the threads currently running on the cores of >> the machine. Any swapped out threads are unknown to it. So the Operating >> system plugin reconstructs the swapped out threads by looking at OS >> specific data structures. >> >> We didn't think that lldb should own the support for every variant of >> every OS which might want to reconstruct threads from some data structures >> in the OS. After all, this isn't dealing with fairly stable API's - like >> the Platforms do. The OS plugins deal with internal data structures, which >> tend to change fairly frequently. So trying to package them with lldb >> doesn't seem supportable. >> >> By making the OS plugin something that comes from outside lldb, we allow >> the kernel developers to provide this knowledge on demand. That is very >> convenient. For instance, on macOS, the dSYM bundle for the mach kernel >> contains the Operating System plugin for that kernel. When lldb is used >> for kernel debugging, it finds the dSYM associated with the kernel it is >> targeting and loads in the python support from the dSYM. That way it is >> ensured to get the correct plugin for that kernel. It also means that lldb >> can support kernel versions that didn't even exist when it was made. >> >> As for why this is done with Python and not the C++ SB API's, there's >> nothing to stop it from also being in C++, you can actually write loadable >> C++ plugins with the SB API's for data formatters, for instance. But >> there's generally no significant performance advantage to doing that, and >> its less convenient, so there just hasn't been much demand for it. >> >> Jim >> >> >> > On Dec 19, 2018, at 12:44 PM, Alexander Polyakov via lldb-dev < >> lldb-dev@lists.llvm.org> wrote: >> > >> > Hi lldb-dev, >> > >> > Could someone explain me why do we use python (OperatingSystemPython) >> to describe OS objects like threads? What are the advantages of such an >> approach in comparison to C++ used in Platform plugin for example? IMO, the >> OperatingSystem plugin could be more like the Platform one, it could have a >> separate directory for each OS with its own implementation inside. >> > >> > -- >> > Alexander >> > ___ >> > lldb-dev mailing list >> > lldb-dev@lists.llvm.org >> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev >> >> > > -- > Alexander > -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] SB API is not working properly with OSPython plugin
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] SB API is not working properly with OSPython plugin
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
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
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
It seems that the process plugin uses the Process::SetPrivateState at the right time. If you look at the log, you will see that the process is already in the '*private* *stopped'* state when the OS plugin is invoked. (lldb) c lldb Process::Resume -- locking run lock lldb Process::PrivateResume() m_stop_id = 1, public state: stopped private state: stopped lldb Process::SetPrivateState (running) intern-state Process::ShouldBroadcastEvent (0x1abea90) => new state: running, last broadcast state: running - YES intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new state running (old state stopped) to public intern-state Process::PushProcessIOHandler pushing IO handler intern-state Process::HandlePrivateEvent updated m_iohandler_sync to 1 lldb Process thinks the process has resumed. intern-state timeout = , event_sp)... lldb waited from m_iohandler_sync to change from 0. New value is 1. dbg.evt-handler Process::SetPublicState (state = running, restarted = 0) Process 1 resuming lldb Process::SetPrivateState (stopped) lldb Process::SetPrivateState (stopped) stop_id = 2 error: error: process must be stopped. intern-state Process::ShouldBroadcastEvent (0x7f3e9c007450) => new state: stopped, last broadcast state: stopped - YES intern-state Process::HandlePrivateEvent (pid = 1) broadcasting new state stopped (old state running) to public intern-state timeout = , event_sp)... dbg.evt-handler Process::SetPublicState (state = stopped, restarted = 0) dbg.evt-handler Process::SetPublicState (stopped) -- unlocking run lock On Fri, Feb 15, 2019 at 1:38 AM Jim Ingham wrote: > 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 >>> wr
[lldb-dev] SBValue::GetName returns wrong result?
Hi lldb-dev,
I have a SBValue created via
SBTarget.CreateValueFromExpression('some_name', expr).
If the expression looks like '(some_type *) addr', then GetName returns
'some_name' as expected, but when I do Dereference this value, GetName
returns '*some_name'.
So, is it a conventional behavior of the GetName method applied to
dereferenced SBValue?
--
Alexander
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] SBValue::GetName returns wrong result?
I can't say that it's a problem, I just want to know what is the actual
reason of such a behavior to find good workaround.
I have a SBValue with a pointer to some object, e.g. "(uint32_t *) sp",
when I do dereference it, I get another SBValue - "(uint32_t) *sp". The
only way to deal with it that I see is to check the first symbol of name
and erase it if it's equal to *.
I'm facing with that situation when creating an object from a pointer via
SBTarget::CreateValueFromExpression.
On Mon, Apr 1, 2019 at 9:35 PM Jim Ingham wrote:
> Dereference returns another SBValue distinct from the initial one, so it
> needs to make up a name for it. I think it would be confusing for it to
> return the same name, and putting a * at the beginning of the initial
> SBValue seems as good a choice as any.
>
> Is this causing you some concrete problem?
>
> Jim
>
>
> > On Mar 30, 2019, at 11:18 AM, Alexander Polyakov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi lldb-dev,
> >
> > I have a SBValue created via
> SBTarget.CreateValueFromExpression('some_name', expr).
> > If the expression looks like '(some_type *) addr', then GetName returns
> 'some_name' as expected, but when I do Dereference this value, GetName
> returns '*some_name'.
> >
> > So, is it a conventional behavior of the GetName method applied to
> dereferenced SBValue?
> >
> > --
> > 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] SBValue::GetName returns wrong result?
I have an address of memory where the value of some register is. I do
following:
addr = 0x1234 (just for example)
rbx = target.CreateValueFromExpression('(uint32_t *) ' + str(addr), 'rbx')
rbx = rbx.Dereference()
Then I want to create a map:
rbx.GetName() => rbx.GetValue()
In this case rbx.GetName() will return "*rbx".
Maybe it'd be better to use SBTarget::CreateValueFromAddress() instead of
CreateValueFromExpression. The Value created this way will be dereferenced
initially, so its name will not contain *, I guess.
On Tue, Apr 2, 2019 at 1:23 AM Jim Ingham wrote:
> What are you using the name for? If the name of an SBValue is the name of
> a variable, then it makes sense (at least in C languages) for the name of
> the dereference Value to be "*VARNAME". After all that's what it is. If
> the name is some other random string, I'm not sure anything would be better
> or worse, except it would be confusing to dereference an SBValue and get
> back another value with the same name, so we have to choose something else.
>
> Jim
>
> > On Apr 1, 2019, at 3:16 PM, Alexander Polyakov
> wrote:
> >
> > I can't say that it's a problem, I just want to know what is the actual
> reason of such a behavior to find good workaround.
> >
> > I have a SBValue with a pointer to some object, e.g. "(uint32_t *) sp",
> when I do dereference it, I get another SBValue - "(uint32_t) *sp". The
> only way to deal with it that I see is to check the first symbol of name
> and erase it if it's equal to *.
> >
> > I'm facing with that situation when creating an object from a pointer
> via SBTarget::CreateValueFromExpression.
> >
> >
> >
> > On Mon, Apr 1, 2019 at 9:35 PM Jim Ingham wrote:
> > Dereference returns another SBValue distinct from the initial one, so it
> needs to make up a name for it. I think it would be confusing for it to
> return the same name, and putting a * at the beginning of the initial
> SBValue seems as good a choice as any.
> >
> > Is this causing you some concrete problem?
> >
> > Jim
> >
> >
> > > On Mar 30, 2019, at 11:18 AM, Alexander Polyakov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > >
> > > Hi lldb-dev,
> > >
> > > I have a SBValue created via
> SBTarget.CreateValueFromExpression('some_name', expr).
> > > If the expression looks like '(some_type *) addr', then GetName
> returns 'some_name' as expected, but when I do Dereference this value,
> GetName returns '*some_name'.
> > >
> > > So, is it a conventional behavior of the GetName method applied to
> dereferenced SBValue?
> > >
> > > --
> > > 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] SBValue::GetName returns wrong result?
Yes, seems that it is what I needed.
Thank you for the tip!
вт, 2 апр. 2019 г. в 1:45, Jim Ingham :
> Independent of the naming issue, if you have an address and want to view
> its pointee as a given type, CreateValueFromAddress is much more efficient
> than CreateValueFromExpression. After all, CreateValueFromAddress just
> reads some memory and presents it as the given type, rather than having to
> parse and evaluate an expression just to figure out the type and address,
> and then go read the memory and present it as the given type..
>
> As a side note, if you only wanted the dereferenced values, and needed to
> use the expression, you could also just make the expression be:
>
> *((uint32_t *) ADDR)
>
> The resultant SBValue would have the name you wanted. But again, for
> "typed addresses" CreateValueFromAddress is a more robust & efficient API.
>
> Jim
>
>
> > On Apr 1, 2019, at 3:36 PM, Alexander Polyakov
> wrote:
> >
> > I have an address of memory where the value of some register is. I do
> following:
> >
> > addr = 0x1234 (just for example)
> > rbx = target.CreateValueFromExpression('(uint32_t *) ' + str(addr),
> 'rbx')
> > rbx = rbx.Dereference()
> >
> > Then I want to create a map:
> > rbx.GetName() => rbx.GetValue()
> >
> > In this case rbx.GetName() will return "*rbx".
> >
> > Maybe it'd be better to use SBTarget::CreateValueFromAddress() instead
> of CreateValueFromExpression. The Value created this way will be
> dereferenced initially, so its name will not contain *, I guess.
> >
> > On Tue, Apr 2, 2019 at 1:23 AM Jim Ingham wrote:
> > What are you using the name for? If the name of an SBValue is the name
> of a variable, then it makes sense (at least in C languages) for the name
> of the dereference Value to be "*VARNAME". After all that's what it is.
> If the name is some other random string, I'm not sure anything would be
> better or worse, except it would be confusing to dereference an SBValue and
> get back another value with the same name, so we have to choose something
> else.
> >
> > Jim
> >
> > > On Apr 1, 2019, at 3:16 PM, Alexander Polyakov
> wrote:
> > >
> > > I can't say that it's a problem, I just want to know what is the
> actual reason of such a behavior to find good workaround.
> > >
> > > I have a SBValue with a pointer to some object, e.g. "(uint32_t *)
> sp", when I do dereference it, I get another SBValue - "(uint32_t) *sp".
> The only way to deal with it that I see is to check the first symbol of
> name and erase it if it's equal to *.
> > >
> > > I'm facing with that situation when creating an object from a pointer
> via SBTarget::CreateValueFromExpression.
> > >
> > >
> > >
> > > On Mon, Apr 1, 2019 at 9:35 PM Jim Ingham wrote:
> > > Dereference returns another SBValue distinct from the initial one, so
> it needs to make up a name for it. I think it would be confusing for it to
> return the same name, and putting a * at the beginning of the initial
> SBValue seems as good a choice as any.
> > >
> > > Is this causing you some concrete problem?
> > >
> > > Jim
> > >
> > >
> > > > On Mar 30, 2019, at 11:18 AM, Alexander Polyakov via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> > > >
> > > > Hi lldb-dev,
> > > >
> > > > I have a SBValue created via
> SBTarget.CreateValueFromExpression('some_name', expr).
> > > > If the expression looks like '(some_type *) addr', then GetName
> returns 'some_name' as expected, but when I do Dereference this value,
> GetName returns '*some_name'.
> > > >
> > > > So, is it a conventional behavior of the GetName method applied to
> dereferenced SBValue?
> > > >
> > > > --
> > > > 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
[lldb-dev] [RFC] OS awareness in LLDB
Hi lldb-dev, Currently I'm working on an OS plug-in for multiple operating systems and architectures, during my work, I noted a few moments I want to discuss with the community. 1) Adding RegisterContext to SB API: if you want your OS plug-in to support multiple architectures you need to implement things like *get_register_info, get_register_data...* for each architecture. In my mind, we could do that using RegisterContext, for example: *get_register_info* could just call RegisterContext::GetRegisterContextAtIndex(idx), the number of registers could be obtained from RegisterContext::GetRegisterCount(); *get_register_data *could return SBRegisterContext instead of just bytes, then the process of fetching the register values might look as: for each register SBRegisterContext::WriteRegister(reg_info, reg_value). Please correct me if I'm missing something. 2) New lldb-mi command: -info-os the gdb-mi documentation defines this command and there is a problem with it. To fully implement it, we should be able to get CPU ID a thread is running on, but lldb does not have an abstraction for CPU ID at all, so it becomes unreal at least for now. I'm going to partly implement this command for Zephyr (e.g. return some value to indicate that the CPU ID is undefined) and I want to know if the community is interested in implementing that command inside lldb-mi (at least in part). -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] OS awareness in LLDB
Gentle ping. On Wed, Apr 3, 2019 at 8:05 PM Alexander Polyakov wrote: > Hi lldb-dev, > > Currently I'm working on an OS plug-in for multiple operating systems and > architectures, during my work, I noted a few moments I want to discuss with > the community. > > 1) Adding RegisterContext to SB API: > if you want your OS plug-in to support multiple architectures you need > to implement > things like *get_register_info, get_register_data...* for each > architecture. > In my mind, we could do that using RegisterContext, for example: > *get_register_info* could just call > RegisterContext::GetRegisterContextAtIndex(idx), the number > of registers could be obtained from > RegisterContext::GetRegisterCount(); > *get_register_data *could return SBRegisterContext instead of just > bytes, then the process of > fetching the register values might look as: for each register > SBRegisterContext::WriteRegister(reg_info, reg_value). > Please correct me if I'm missing something. > > 2) New lldb-mi command: -info-os > the gdb-mi documentation defines this command and there is a problem > with it. To fully > implement it, we should be able to get CPU ID a thread is running on, > but lldb > does not have an abstraction for CPU ID at all, so it becomes unreal > at least for now. > I'm going to partly implement this command for Zephyr (e.g. return > some value to indicate > that the CPU ID is undefined) and I want to know if the community is > interested in implementing > that command inside lldb-mi (at least in part). > > -- > Alexander > -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [RFC] Having common Python OS Plug-in
Hi lldb-dev, The last few months, I was implementing a LLDB OS Python plug-in. It seems that there are functionality that is duplicated across many OS plug-ins. I think we can change that by, for example, upstreaming to LLDB an OS python plug-in which can be used by all clients and may contain a lot of utility functions and useful mechanisms like logging, type summaries and so on. What is your opinion on this? -- Alexander ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [RFC] Having common Python OS Plug-in
It seems that I need a Apple ID to create an account, can you please share the code? I want common OS plug-in to be similar to Apple's lldbmacros (link <https://github.com/apple/darwin-xnu/tree/master/tools/lldbmacros>), but it should be with support of multiple architectures and operating systems, logging and so on. I've created such a plug-in for Zephyr OS, maybe I'll be able to also share the code to show how common plug-in might look like. On Wed, Apr 17, 2019 at 10:40 PM Jim Ingham wrote: > If you want to undertake such a thing, that would be great. The other > fairly complex OS plugin that exists in the wild is the one that ships with > the Darwin Kernel Debug Kit. You can get this from > http://developer.apple.com/download/more - you need a free ADC account to > get this, though if that's a problem I can also get you a copy of the > Python code for the OS plugin. If you're going to make some common > utilities you might have a look at what that one does if you haven't > already. > > Jim > > > > On Apr 17, 2019, at 11:37 AM, Alexander Polyakov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > Hi lldb-dev, > > > > The last few months, I was implementing a LLDB OS Python plug-in. It > seems that there are functionality that is duplicated across many OS > plug-ins. I think we can change that by, for example, upstreaming to LLDB > an OS python plug-in which can be used by all clients and may contain a lot > of utility functions and useful mechanisms like logging, type summaries and > so on. > > > > What is your opinion on this? > > > > -- > > 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] [RFC] OS awareness in LLDB
> > Are you asking for the ability to create external native plug-ins instead > of the python OS plug-in interface? The main idea is to have one common native/Python OS plug-in that can be extended with new architectures and operating systems. What is missing from the python OS plug-in interface here? A register > context represents all of the registers so I don't follow what you mean > with what is stated above about asking for a register context by index. So > you want multiple architectures to show up in the same process? If so this > will require many changes to LLDB as each thread currently is assumed to > have the same architecture as the process. The *RegisterContext *already provides register info, so having it in a public API makes it possible to get rid of duplicating register info definitions (example <https://github.com/apple/darwin-xnu/blob/a449c6a3b8014d9406c2ddbdc81795da24aa7443/tools/lldbmacros/core/operating_system.py#L19> ) *.* If we do make native plug-in we could do things very similar to the python > OS plug-in: > - Define the registers for threads, possibly adding the ability to specify > more than one register context to allow different threads to have different > registers. This register context would define which registers are > available, how they are grouped, etc. > - For each thread, figure out which register context it will use from one > of the register layouts that was specified in above step > - allow read/write access to registers At the beginning of my work I was thinking about implementing that on public API level, thus making it usable in Python OS plug-in, but now I see that it requires huge changes to LLDB, so I am not sure about the expediency of this. On Sat, Jul 13, 2019 at 1:01 AM Greg Clayton wrote: > > > On Apr 3, 2019, at 10:05 AM, Alexander Polyakov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > Hi lldb-dev, > > Currently I'm working on an OS plug-in for multiple operating systems and > architectures, during my work, I noted a few moments I want to discuss with > the community. > > 1) Adding RegisterContext to SB API: > > > Are you asking for the ability to create external native plug-ins instead > of the python OS plug-in interface? > > > if you want your OS plug-in to support multiple architectures you need > to implement > things like *get_register_info, get_register_data...* for each > architecture. > In my mind, we could do that using RegisterContext, for example: > *get_register_info* could just call > RegisterContext::GetRegisterContextAtIndex(idx), the number > of registers could be obtained from > RegisterContext::GetRegisterCount(); > > > What is missing from the python OS plug-in interface here? A register > context represents all of the registers so I don't follow what you mean > with what is stated above about asking for a register context by index. So > you want multiple architectures to show up in the same process? If so this > will require many changes to LLDB as each thread currently is assumed to > have the same architecture as the process. > > *get_register_data *could return SBRegisterContext instead of just > bytes, then the process of > fetching the register values might look as: for each register > SBRegisterContext::WriteRegister(reg_info, reg_value). > Please correct me if I'm missing something. > > > I know the python OS plug-in doesn't have the ability to write a register > right now. Again, a RegisterContext is a group of all of the register for a > thread, so I am not sure SBRegisterContext is the right naming here. > > If we do make native plug-in we could do things very similar to the python > OS plug-in: > - Define the registers for threads, possibly adding the ability to specify > more than one register context to allow different threads to have different > registers. This register context would define which registers are > available, how they are grouped, etc. > - For each thread, figure out which register context it will use from one > of the register layouts that was specified in above step > - allow read/write access to registers > > The python OS plug-in has the ability to define a single different > register context for threads, and the ability read registers. The > architecture is assumed to be the same. > > > 2) New lldb-mi command: -info-os > the gdb-mi documentation defines this command and there is a problem > with it. To fully > implement it, we should be able to get CPU ID a thread is running on, > but lldb > does not have an abstraction for CPU ID at all, so it becomes unreal > at least for now. > I'm going to partly implement this command for Zeph
