Re: [lldb-dev] Inquiry for performance monitors
Ok, that is one option, but one of the aim for this activity is to make the
data available for use by the IDE's like Android Studio or XCode or any
other that may want to display this information in its environment so
keeping that in consideration would the complete python based approach be
useful ? or would providing LLDB api's to extract raw perf data from the
target be useful ?
On Thu, Jan 21, 2016 at 10:00 PM, Greg Clayton wrote:
> One thing to think about is you can actually just run an expression in the
> program that is being debugged without needing to change anything in the
> GDB remote server. So this can all be done via python commands and would
> require no changes to anything. So you can run an expression to enable the
> buffer. Since LLDB supports multiple line expression that can define their
> own local variables and local types. So the expression could be something
> like:
>
> int perf_fd = (int)perf_event_open(...);
> struct PerfData
> {
> void *data;
> size_t size;
> };
> PerfData result = read_perf_data(perf_fd);
> result
>
>
> The result is then a structure that you can access from your python
> command (it will be a SBValue) and then you can read memory in order to get
> the perf data.
>
> You can also split things up into multiple calls where you can run
> perf_event_open() on its own and return the file descriptor:
>
> (int)perf_event_open(...)
>
> This expression will return the file descriptor
>
> Then you could allocate memory via the SBProcess:
>
> (void *)malloc(1024);
>
> The result of this expression will be the buffer that you use...
>
> Then you can read 1024 bytes at a time into this newly created buffer.
>
> So a solution that is completely done in python would be very attractive.
>
> Greg
>
>
> > On Jan 21, 2016, at 7:04 AM, Ravitheja Addepally <
> ravithejaw...@gmail.com> wrote:
> >
> > Hello,
> > Regarding the questions in this thread please find the answers ->
> >
> > How are you going to present this information to the user? (I know
> > debugserver can report some performance data... Have you looked into
> > how that works? Do you plan to reuse some parts of that
> > infrastructure?) and How will you get the information from the server to
> the client?
> >
> > Currently I plan to show a list of instructions that have been executed
> so far, I saw the
> > implementation suggested by pavel, the already present infrastructure is
> a little bit lacking in terms of the needs of the
> > project, but I plan to follow a similar approach, i.e to extract the raw
> trace data by querying the server (which can use the
> > perf_event_open to get the raw trace data from the kernel) and transport
> it through gdb packets ( qXfer packets
> >
> https://sourceware.org/gdb/onlinedocs/gdb/Branch-Trace-Format.html#Branch-Trace-Format).
> At the client side the raw trace data
> > could be passed on to python based command that could decode the data.
> This also eliminates the dependency of libipt since LLDB
> > would not decode the data itself.
> >
> > There is also the question of this third party library. Do we take a
> hard dependency on libipt (probably a non-starter), or only use it if it's
> available (much better)?
> >
> > With the above mentioned way LLDB would not need the library, who ever
> wants to use the python command would have to install it separately but
> LLDB wont need it
> >
> > With the performance counters, the interface would still be
> perf_event_open, so if there was a perf_wrapper in LLDB server then it
> could be reused to configure and use the
> > software performance counters as well, you would just need to pass
> different attributes in the perf_event_open system call, plus I think the
> perf_wrapper could be reused to
> > get CoreSight information as well (see https://lwn.net/Articles/664236/
> )
> >
> >
> > On Wed, Oct 21, 2015 at 8:57 PM, Greg Clayton
> wrote:
> > one main benefit to doing this externally is allow this to be done
> remotely over any debugger connection. If you can run expressions to
> enable/disable/setup the memory buffer/access the buffer contents, then you
> don't need to add code into the debugger to actually do this.
> >
> > Greg
> >
> > > On Oct 21, 2015, at 11:54 AM, Greg Clayton wrote:
> > >
> > > IMHO the best way to provide this information is to implement reverse
> debugging packets in a GDB server (lldb-server). If you enable this feature
> via some packet to lldb-server, and that enables the gathering of data that
> keeps the last N instructions run by all threads in some buffer that gets
> overwritten. The lldb-server enables it and gives a buffer to the
> perf_event_interface(). Then clients can ask the lldb-server to step back
> in any thread. Only when the data is requested do we actually use the data
> to implement the reverse stepping.
> > >
> > > Another way to do this would be to use a python based command that can
> be added to any target that supports this. The plug-in could install a set
> of L
Re: [lldb-dev] Understanding debugger launch events sequence
On 29 January 2016 at 18:43, Jeffrey Tan wrote: > Thanks Jim. Is this true for other platforms? Our IDE is going to support > Mac and Linux and may extend to Windows some time later. AFAIK, windows spawns a separate thread to do the actual debugging, but this is hidden from you, and you can carry on debugging normally. On Linux/OSX we even spawn a separate process. In short, there should be no noticeable user-facing differences between the platforms. If you find any, then we'd like to know about them. pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux
On 30 January 2016 at 00:13, William Dillon wrote: > In a very real sense, no information is lost here. That is exactly the reason why it looks very hackish. :) It looks to me like you are trying to work around some other bug, probably in the code that consumes the triple. Could you point me to the code that consumes that triple? Couldn't that be fixed to look at triple.getSubArch() instead of it's string representation? > Would it make you more comfortable is this patch was rewritten within > HostInfoLinux::ComputeHostArchitectureSupport alongside the massaging of the > vendor name for linux? If this is Linux-specific, then HostInfoLinux is definitely a better place for it. However, I would like to understand this a bit deeper first... pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to get SBTarget before AttachToProcessWithID?
Hi, it's a bit un-intuitive, but you should be able to create a target with a null pointer for the executable, and use that to attach (see CommandObjectProcessAttach::DoExecute). BTW, if you find the existing API documentation too vague, we'd be happy to accept any improvements. cheers, pl On 30 January 2016 at 05:42, Jeffrey Tan via lldb-dev wrote: > Hi, > > Normally if you want to attach to a process you only have the pid/name of > the process. How do you get SBTarget? Am I supposed to call > SBDebugger.CreateTargetWithFileAndArch() against a dummy executable? Why do > we require a dummy SBTarget before attaching? This seems to be a wrong > design to me... Thanks. > > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Inquiry for performance monitors
It feels to me that the python based approach could run into a dead
end fairly quickly: a) you can only access the data when the target is
stopped; b) the self-tracing means that the evaluation of these
expressions would introduce noise in the data; c) overhead of all the
extra packets(?).
So, I would be in favor of a lldb-server based approach. I'm not
telling you that you shouldn't do that, but I don't think that's an
approach I would take...
pl
On 1 February 2016 at 08:58, Ravitheja Addepally
wrote:
> Ok, that is one option, but one of the aim for this activity is to make the
> data available for use by the IDE's like Android Studio or XCode or any
> other that may want to display this information in its environment so
> keeping that in consideration would the complete python based approach be
> useful ? or would providing LLDB api's to extract raw perf data from the
> target be useful ?
>
> On Thu, Jan 21, 2016 at 10:00 PM, Greg Clayton wrote:
>>
>> One thing to think about is you can actually just run an expression in the
>> program that is being debugged without needing to change anything in the GDB
>> remote server. So this can all be done via python commands and would require
>> no changes to anything. So you can run an expression to enable the buffer.
>> Since LLDB supports multiple line expression that can define their own local
>> variables and local types. So the expression could be something like:
>>
>> int perf_fd = (int)perf_event_open(...);
>> struct PerfData
>> {
>> void *data;
>> size_t size;
>> };
>> PerfData result = read_perf_data(perf_fd);
>> result
>>
>>
>> The result is then a structure that you can access from your python
>> command (it will be a SBValue) and then you can read memory in order to get
>> the perf data.
>>
>> You can also split things up into multiple calls where you can run
>> perf_event_open() on its own and return the file descriptor:
>>
>> (int)perf_event_open(...)
>>
>> This expression will return the file descriptor
>>
>> Then you could allocate memory via the SBProcess:
>>
>> (void *)malloc(1024);
>>
>> The result of this expression will be the buffer that you use...
>>
>> Then you can read 1024 bytes at a time into this newly created buffer.
>>
>> So a solution that is completely done in python would be very attractive.
>>
>> Greg
>>
>>
>> > On Jan 21, 2016, at 7:04 AM, Ravitheja Addepally
>> > wrote:
>> >
>> > Hello,
>> > Regarding the questions in this thread please find the answers ->
>> >
>> > How are you going to present this information to the user? (I know
>> > debugserver can report some performance data... Have you looked into
>> > how that works? Do you plan to reuse some parts of that
>> > infrastructure?) and How will you get the information from the server to
>> > the client?
>> >
>> > Currently I plan to show a list of instructions that have been executed
>> > so far, I saw the
>> > implementation suggested by pavel, the already present infrastructure is
>> > a little bit lacking in terms of the needs of the
>> > project, but I plan to follow a similar approach, i.e to extract the raw
>> > trace data by querying the server (which can use the
>> > perf_event_open to get the raw trace data from the kernel) and transport
>> > it through gdb packets ( qXfer packets
>> >
>> > https://sourceware.org/gdb/onlinedocs/gdb/Branch-Trace-Format.html#Branch-Trace-Format).
>> > At the client side the raw trace data
>> > could be passed on to python based command that could decode the data.
>> > This also eliminates the dependency of libipt since LLDB
>> > would not decode the data itself.
>> >
>> > There is also the question of this third party library. Do we take a
>> > hard dependency on libipt (probably a non-starter), or only use it if it's
>> > available (much better)?
>> >
>> > With the above mentioned way LLDB would not need the library, who ever
>> > wants to use the python command would have to install it separately but
>> > LLDB
>> > wont need it
>> >
>> > With the performance counters, the interface would still be
>> > perf_event_open, so if there was a perf_wrapper in LLDB server then it
>> > could
>> > be reused to configure and use the
>> > software performance counters as well, you would just need to pass
>> > different attributes in the perf_event_open system call, plus I think the
>> > perf_wrapper could be reused to
>> > get CoreSight information as well (see https://lwn.net/Articles/664236/
>> > )
>> >
>> >
>> > On Wed, Oct 21, 2015 at 8:57 PM, Greg Clayton
>> > wrote:
>> > one main benefit to doing this externally is allow this to be done
>> > remotely over any debugger connection. If you can run expressions to
>> > enable/disable/setup the memory buffer/access the buffer contents, then you
>> > don't need to add code into the debugger to actually do this.
>> >
>> > Greg
>> >
>> > > On Oct 21, 2015, at 11:54 AM, Greg Clayton wrote:
>> > >
>> > > IMHO the best way to provide this information is to implement reverse
Re: [lldb-dev] Inquiry for performance monitors
And what about the ease of integration into a an IDE, I don't really know
if the python based approach would be usable or not in this context ?
On Mon, Feb 1, 2016 at 11:17 AM, Pavel Labath wrote:
> It feels to me that the python based approach could run into a dead
> end fairly quickly: a) you can only access the data when the target is
> stopped; b) the self-tracing means that the evaluation of these
> expressions would introduce noise in the data; c) overhead of all the
> extra packets(?).
>
> So, I would be in favor of a lldb-server based approach. I'm not
> telling you that you shouldn't do that, but I don't think that's an
> approach I would take...
>
> pl
>
>
> On 1 February 2016 at 08:58, Ravitheja Addepally
> wrote:
> > Ok, that is one option, but one of the aim for this activity is to make
> the
> > data available for use by the IDE's like Android Studio or XCode or any
> > other that may want to display this information in its environment so
> > keeping that in consideration would the complete python based approach be
> > useful ? or would providing LLDB api's to extract raw perf data from the
> > target be useful ?
> >
> > On Thu, Jan 21, 2016 at 10:00 PM, Greg Clayton
> wrote:
> >>
> >> One thing to think about is you can actually just run an expression in
> the
> >> program that is being debugged without needing to change anything in
> the GDB
> >> remote server. So this can all be done via python commands and would
> require
> >> no changes to anything. So you can run an expression to enable the
> buffer.
> >> Since LLDB supports multiple line expression that can define their own
> local
> >> variables and local types. So the expression could be something like:
> >>
> >> int perf_fd = (int)perf_event_open(...);
> >> struct PerfData
> >> {
> >> void *data;
> >> size_t size;
> >> };
> >> PerfData result = read_perf_data(perf_fd);
> >> result
> >>
> >>
> >> The result is then a structure that you can access from your python
> >> command (it will be a SBValue) and then you can read memory in order to
> get
> >> the perf data.
> >>
> >> You can also split things up into multiple calls where you can run
> >> perf_event_open() on its own and return the file descriptor:
> >>
> >> (int)perf_event_open(...)
> >>
> >> This expression will return the file descriptor
> >>
> >> Then you could allocate memory via the SBProcess:
> >>
> >> (void *)malloc(1024);
> >>
> >> The result of this expression will be the buffer that you use...
> >>
> >> Then you can read 1024 bytes at a time into this newly created buffer.
> >>
> >> So a solution that is completely done in python would be very
> attractive.
> >>
> >> Greg
> >>
> >>
> >> > On Jan 21, 2016, at 7:04 AM, Ravitheja Addepally
> >> > wrote:
> >> >
> >> > Hello,
> >> > Regarding the questions in this thread please find the answers
> ->
> >> >
> >> > How are you going to present this information to the user? (I know
> >> > debugserver can report some performance data... Have you looked into
> >> > how that works? Do you plan to reuse some parts of that
> >> > infrastructure?) and How will you get the information from the server
> to
> >> > the client?
> >> >
> >> > Currently I plan to show a list of instructions that have been
> executed
> >> > so far, I saw the
> >> > implementation suggested by pavel, the already present infrastructure
> is
> >> > a little bit lacking in terms of the needs of the
> >> > project, but I plan to follow a similar approach, i.e to extract the
> raw
> >> > trace data by querying the server (which can use the
> >> > perf_event_open to get the raw trace data from the kernel) and
> transport
> >> > it through gdb packets ( qXfer packets
> >> >
> >> >
> https://sourceware.org/gdb/onlinedocs/gdb/Branch-Trace-Format.html#Branch-Trace-Format
> ).
> >> > At the client side the raw trace data
> >> > could be passed on to python based command that could decode the data.
> >> > This also eliminates the dependency of libipt since LLDB
> >> > would not decode the data itself.
> >> >
> >> > There is also the question of this third party library. Do we take a
> >> > hard dependency on libipt (probably a non-starter), or only use it if
> it's
> >> > available (much better)?
> >> >
> >> > With the above mentioned way LLDB would not need the library, who ever
> >> > wants to use the python command would have to install it separately
> but LLDB
> >> > wont need it
> >> >
> >> > With the performance counters, the interface would still be
> >> > perf_event_open, so if there was a perf_wrapper in LLDB server then
> it could
> >> > be reused to configure and use the
> >> > software performance counters as well, you would just need to pass
> >> > different attributes in the perf_event_open system call, plus I think
> the
> >> > perf_wrapper could be reused to
> >> > get CoreSight information as well (see
> https://lwn.net/Articles/664236/
> >> > )
> >> >
> >> >
> >> > On Wed, Oct 21, 2015 at 8:57 PM, Greg Clayton
> >> > wrote:
> >
Re: [lldb-dev] Inquiry for performance monitors
Speaking for Android Studio, I think that we *could* use a
python-based implementation (hard to say exactly without knowing the
details of the implementation), but I believe a different
implementation could be *easier* to integrate. Plus, if the solution
integrates more closely with lldb, we could surface some of the data
in the command-line client as well.
pl
On 1 February 2016 at 10:30, Ravitheja Addepally
wrote:
> And what about the ease of integration into a an IDE, I don't really know if
> the python based approach would be usable or not in this context ?
>
> On Mon, Feb 1, 2016 at 11:17 AM, Pavel Labath wrote:
>>
>> It feels to me that the python based approach could run into a dead
>> end fairly quickly: a) you can only access the data when the target is
>> stopped; b) the self-tracing means that the evaluation of these
>> expressions would introduce noise in the data; c) overhead of all the
>> extra packets(?).
>>
>> So, I would be in favor of a lldb-server based approach. I'm not
>> telling you that you shouldn't do that, but I don't think that's an
>> approach I would take...
>>
>> pl
>>
>>
>> On 1 February 2016 at 08:58, Ravitheja Addepally
>> wrote:
>> > Ok, that is one option, but one of the aim for this activity is to make
>> > the
>> > data available for use by the IDE's like Android Studio or XCode or any
>> > other that may want to display this information in its environment so
>> > keeping that in consideration would the complete python based approach
>> > be
>> > useful ? or would providing LLDB api's to extract raw perf data from the
>> > target be useful ?
>> >
>> > On Thu, Jan 21, 2016 at 10:00 PM, Greg Clayton
>> > wrote:
>> >>
>> >> One thing to think about is you can actually just run an expression in
>> >> the
>> >> program that is being debugged without needing to change anything in
>> >> the GDB
>> >> remote server. So this can all be done via python commands and would
>> >> require
>> >> no changes to anything. So you can run an expression to enable the
>> >> buffer.
>> >> Since LLDB supports multiple line expression that can define their own
>> >> local
>> >> variables and local types. So the expression could be something like:
>> >>
>> >> int perf_fd = (int)perf_event_open(...);
>> >> struct PerfData
>> >> {
>> >> void *data;
>> >> size_t size;
>> >> };
>> >> PerfData result = read_perf_data(perf_fd);
>> >> result
>> >>
>> >>
>> >> The result is then a structure that you can access from your python
>> >> command (it will be a SBValue) and then you can read memory in order to
>> >> get
>> >> the perf data.
>> >>
>> >> You can also split things up into multiple calls where you can run
>> >> perf_event_open() on its own and return the file descriptor:
>> >>
>> >> (int)perf_event_open(...)
>> >>
>> >> This expression will return the file descriptor
>> >>
>> >> Then you could allocate memory via the SBProcess:
>> >>
>> >> (void *)malloc(1024);
>> >>
>> >> The result of this expression will be the buffer that you use...
>> >>
>> >> Then you can read 1024 bytes at a time into this newly created buffer.
>> >>
>> >> So a solution that is completely done in python would be very
>> >> attractive.
>> >>
>> >> Greg
>> >>
>> >>
>> >> > On Jan 21, 2016, at 7:04 AM, Ravitheja Addepally
>> >> > wrote:
>> >> >
>> >> > Hello,
>> >> > Regarding the questions in this thread please find the answers
>> >> > ->
>> >> >
>> >> > How are you going to present this information to the user? (I know
>> >> > debugserver can report some performance data... Have you looked into
>> >> > how that works? Do you plan to reuse some parts of that
>> >> > infrastructure?) and How will you get the information from the server
>> >> > to
>> >> > the client?
>> >> >
>> >> > Currently I plan to show a list of instructions that have been
>> >> > executed
>> >> > so far, I saw the
>> >> > implementation suggested by pavel, the already present infrastructure
>> >> > is
>> >> > a little bit lacking in terms of the needs of the
>> >> > project, but I plan to follow a similar approach, i.e to extract the
>> >> > raw
>> >> > trace data by querying the server (which can use the
>> >> > perf_event_open to get the raw trace data from the kernel) and
>> >> > transport
>> >> > it through gdb packets ( qXfer packets
>> >> >
>> >> >
>> >> > https://sourceware.org/gdb/onlinedocs/gdb/Branch-Trace-Format.html#Branch-Trace-Format).
>> >> > At the client side the raw trace data
>> >> > could be passed on to python based command that could decode the
>> >> > data.
>> >> > This also eliminates the dependency of libipt since LLDB
>> >> > would not decode the data itself.
>> >> >
>> >> > There is also the question of this third party library. Do we take a
>> >> > hard dependency on libipt (probably a non-starter), or only use it if
>> >> > it's
>> >> > available (much better)?
>> >> >
>> >> > With the above mentioned way LLDB would not need the library, who
>> >> > ever
>> >> > wants to use the python command would have
Re: [lldb-dev] Inquiry for performance monitors
If you want to go with the path to implement it outside LLDB then I would
suggest to implement it with an out of tree plugin written in C++. You can
use the SB API the same way as you can from python and additionally it have
a few advantages:
* You have a C/C++ API what makes it easy to integrate the functionality
into an IDE (they just have to link to your shared library)
* You can generate a Python API if you need one with SWIG the same way we
do it for the SB API
* You don't have to worry about making the code both Python 2.7 and Python
3.5 compatible
You can see a very simple example for implementing an out of tree C++
plugin in /examples/plugins/commands
On Mon, Feb 1, 2016 at 10:53 AM Pavel Labath via lldb-dev <
lldb-dev@lists.llvm.org> wrote:
> Speaking for Android Studio, I think that we *could* use a
> python-based implementation (hard to say exactly without knowing the
> details of the implementation), but I believe a different
> implementation could be *easier* to integrate. Plus, if the solution
> integrates more closely with lldb, we could surface some of the data
> in the command-line client as well.
>
> pl
>
> On 1 February 2016 at 10:30, Ravitheja Addepally
> wrote:
> > And what about the ease of integration into a an IDE, I don't really
> know if
> > the python based approach would be usable or not in this context ?
> >
> > On Mon, Feb 1, 2016 at 11:17 AM, Pavel Labath wrote:
> >>
> >> It feels to me that the python based approach could run into a dead
> >> end fairly quickly: a) you can only access the data when the target is
> >> stopped; b) the self-tracing means that the evaluation of these
> >> expressions would introduce noise in the data; c) overhead of all the
> >> extra packets(?).
> >>
> >> So, I would be in favor of a lldb-server based approach. I'm not
> >> telling you that you shouldn't do that, but I don't think that's an
> >> approach I would take...
> >>
> >> pl
> >>
> >>
> >> On 1 February 2016 at 08:58, Ravitheja Addepally
> >> wrote:
> >> > Ok, that is one option, but one of the aim for this activity is to
> make
> >> > the
> >> > data available for use by the IDE's like Android Studio or XCode or
> any
> >> > other that may want to display this information in its environment so
> >> > keeping that in consideration would the complete python based approach
> >> > be
> >> > useful ? or would providing LLDB api's to extract raw perf data from
> the
> >> > target be useful ?
> >> >
> >> > On Thu, Jan 21, 2016 at 10:00 PM, Greg Clayton
> >> > wrote:
> >> >>
> >> >> One thing to think about is you can actually just run an expression
> in
> >> >> the
> >> >> program that is being debugged without needing to change anything in
> >> >> the GDB
> >> >> remote server. So this can all be done via python commands and would
> >> >> require
> >> >> no changes to anything. So you can run an expression to enable the
> >> >> buffer.
> >> >> Since LLDB supports multiple line expression that can define their
> own
> >> >> local
> >> >> variables and local types. So the expression could be something like:
> >> >>
> >> >> int perf_fd = (int)perf_event_open(...);
> >> >> struct PerfData
> >> >> {
> >> >> void *data;
> >> >> size_t size;
> >> >> };
> >> >> PerfData result = read_perf_data(perf_fd);
> >> >> result
> >> >>
> >> >>
> >> >> The result is then a structure that you can access from your python
> >> >> command (it will be a SBValue) and then you can read memory in order
> to
> >> >> get
> >> >> the perf data.
> >> >>
> >> >> You can also split things up into multiple calls where you can run
> >> >> perf_event_open() on its own and return the file descriptor:
> >> >>
> >> >> (int)perf_event_open(...)
> >> >>
> >> >> This expression will return the file descriptor
> >> >>
> >> >> Then you could allocate memory via the SBProcess:
> >> >>
> >> >> (void *)malloc(1024);
> >> >>
> >> >> The result of this expression will be the buffer that you use...
> >> >>
> >> >> Then you can read 1024 bytes at a time into this newly created
> buffer.
> >> >>
> >> >> So a solution that is completely done in python would be very
> >> >> attractive.
> >> >>
> >> >> Greg
> >> >>
> >> >>
> >> >> > On Jan 21, 2016, at 7:04 AM, Ravitheja Addepally
> >> >> > wrote:
> >> >> >
> >> >> > Hello,
> >> >> > Regarding the questions in this thread please find the
> answers
> >> >> > ->
> >> >> >
> >> >> > How are you going to present this information to the user? (I know
> >> >> > debugserver can report some performance data... Have you looked
> into
> >> >> > how that works? Do you plan to reuse some parts of that
> >> >> > infrastructure?) and How will you get the information from the
> server
> >> >> > to
> >> >> > the client?
> >> >> >
> >> >> > Currently I plan to show a list of instructions that have been
> >> >> > executed
> >> >> > so far, I saw the
> >> >> > implementation suggested by pavel, the already present
> infrastructure
> >> >> > is
> >> >> > a little bit lacking in terms of the n
Re: [lldb-dev] Understanding debugger launch events sequence
Great, thanks for the confirmation. Sent from my iPhone > On Feb 1, 2016, at 1:32 AM, Pavel Labath wrote: > >> On 29 January 2016 at 18:43, Jeffrey Tan wrote: >> Thanks Jim. Is this true for other platforms? Our IDE is going to support >> Mac and Linux and may extend to Windows some time later. > > AFAIK, windows spawns a separate thread to do the actual debugging, > but this is hidden from you, and you can carry on debugging normally. > On Linux/OSX we even spawn a separate process. > > In short, there should be no noticeable user-facing differences > between the platforms. If you find any, then we'd like to know about > them. > > pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to get SBTarget before AttachToProcessWithID?
Often when attaching, you know the executable you are planning to attach to.
So the "normal" workflow is to create a target, then attach to the process with
that target's executable. This is particularly useful for remote debugging,
since having a local copy of the binary will mean less data lldb has to ship
over the remote connection. It also means you can prep the target with
breakpoints & settings prior to attach.
The case where you don't know the binary before you attach is a degenerate case
of this, and so the sensible thing is to create an empty target, and use that
to attach. Then attaching will fill in this empty target.
That makes more sense to me than having the debugger - which is the only thing
above the target - support "Attach to anonymous app" but the target do "attach
to known app".
BTW, the most straightforward way to create an empty target is to call
SBDebugger.CreateTarget(""). I added a note to this effect in the SBDebugger
help preamble.
Jim
> On Feb 1, 2016, at 2:02 AM, Pavel Labath via lldb-dev
> wrote:
>
> Hi,
>
> it's a bit un-intuitive, but you should be able to create a target
> with a null pointer for the executable, and use that to attach (see
> CommandObjectProcessAttach::DoExecute).
>
> BTW, if you find the existing API documentation too vague, we'd be
> happy to accept any improvements.
>
> cheers,
> pl
>
>
> On 30 January 2016 at 05:42, Jeffrey Tan via lldb-dev
> wrote:
>> Hi,
>>
>> Normally if you want to attach to a process you only have the pid/name of
>> the process. How do you get SBTarget? Am I supposed to call
>> SBDebugger.CreateTargetWithFileAndArch() against a dummy executable? Why do
>> we require a dummy SBTarget before attaching? This seems to be a wrong
>> design to me... Thanks.
>>
>>
>>
>> ___
>> lldb-dev mailing list
>> lldb-dev@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
> ___
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 26421] New: CommandObjectRegister should set status eReturnStatusSuccessFinishResult
https://llvm.org/bugs/show_bug.cgi?id=26421 Bug ID: 26421 Summary: CommandObjectRegister should set status eReturnStatusSuccessFinishResult Product: lldb Version: 3.8 Hardware: All OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: git...@newplanetsoftware.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Created attachment 15791 --> https://llvm.org/bugs/attachment.cgi?id=15791&action=edit Suggested patch CommandObjectRegister::DoExecute() never sets the result status to eReturnStatusSuccessFinishResult. It should set this if DumpRegister() returns true. -- You are receiving this mail because: You are the assignee for the bug. ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [EuroLLVM] Early bird registration deadline: Feb 3rd
Just a quick reminder: the early bird registration deadline for the EuroLLVM 2016 is Feb 3rd. Registration at: https://intranet.pacifico-meetings.com/GesCoForm/?cfg=887 More info about EuroLLVM 2016 at: http://llvm.org/devmtg/2016-03/ Kind regards, -- Arnaud ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to get SBTarget before AttachToProcessWithID?
Thanks guys, will give empty target a try.
On Mon, Feb 1, 2016 at 12:10 PM, Jim Ingham wrote:
> Often when attaching, you know the executable you are planning to attach
> to. So the "normal" workflow is to create a target, then attach to the
> process with that target's executable. This is particularly useful for
> remote debugging, since having a local copy of the binary will mean less
> data lldb has to ship over the remote connection. It also means you can
> prep the target with breakpoints & settings prior to attach.
>
> The case where you don't know the binary before you attach is a degenerate
> case of this, and so the sensible thing is to create an empty target, and
> use that to attach. Then attaching will fill in this empty target.
>
> That makes more sense to me than having the debugger - which is the only
> thing above the target - support "Attach to anonymous app" but the target
> do "attach to known app".
>
> BTW, the most straightforward way to create an empty target is to call
> SBDebugger.CreateTarget(""). I added a note to this effect in the
> SBDebugger help preamble.
>
> Jim
>
> > On Feb 1, 2016, at 2:02 AM, Pavel Labath via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
> >
> > Hi,
> >
> > it's a bit un-intuitive, but you should be able to create a target
> > with a null pointer for the executable, and use that to attach (see
> > CommandObjectProcessAttach::DoExecute).
> >
> > BTW, if you find the existing API documentation too vague, we'd be
> > happy to accept any improvements.
> >
> > cheers,
> > pl
> >
> >
> > On 30 January 2016 at 05:42, Jeffrey Tan via lldb-dev
> > wrote:
> >> Hi,
> >>
> >> Normally if you want to attach to a process you only have the pid/name
> of
> >> the process. How do you get SBTarget? Am I supposed to call
> >> SBDebugger.CreateTargetWithFileAndArch() against a dummy executable?
> Why do
> >> we require a dummy SBTarget before attaching? This seems to be a wrong
> >> design to me... Thanks.
> >>
> >>
> >>
> >> ___
> >> lldb-dev mailing list
> >> lldb-dev@lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >>
> > ___
> > lldb-dev mailing list
> > lldb-dev@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] February LLVM bay-area social is this Thursday!
(actually spelling lldb-dev correctly, sorry for the typo) We'll be at Tied House as usual, starting on Thursday the 4th at 7pm! If you can, help us plan and RSVP here: http://meetu.ps/2RN2C5 See everyone there! -Chandler ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
