Re: [lldb-dev] Review of API and remote packets
One of the downsides of using the gdb protocol is that these packets are stateful meaning the thread id option is not there and the word btrace stands for branch trace which basically suggests execution tracing. On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath wrote: > I think we should reuse packets from the gdb protocol whereever it > makes sense. So, if they fit your needs (and a quick glance seems to > confirm that), then I think you should use them. > > On 11 April 2016 at 15:28, Ravitheja Addepally > wrote: > > Hello, > >Regarding the packet definitions for tracing, how about reusing > the > > existing btrace packets ? > > > > > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read > > > > On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton wrote: > >> > >> We also need to think about all other types of tracing. It might make > more > >> sense to keep these calls on SBProcess and have the calls simply be: > >> > >> > >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions &trace_options, > >> lldb::SBError &error); > >> > >> And you would need to specify which threads in the SBTraceOptions object > >> itself?: > >> > >> SBTraceOptions trace_options; > >> > >> And then do some like: > >> > >> trace_options.SetTraceAllThreads(); > >> > >> And maybe tracing all threads is the default. Or one can limit this to > one > >> thread: > >> > >> trace_options.SetThreadID (tid); > >> > >> Then you start tracing using the "trace_options" which has the notion of > >> which threads to trace. > >> > >> lldb::SBError error; > >> lldb::SBTrace trace = process.StartTrace(trace_options, error); > >> > >> It really depends on how all different forms of trace are enabled for > >> different kinds of tracing. It takes kernel support to trace only > specific > >> threads, but someone might be debugging a bare board that only has the > >> option tracing all threads on each core. When making an API we can't > assume > >> we can limit this to any threads and even to any process. > >> > >> Greg > >> > >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath wrote: > >> > > >> > I second Greg's suggestions, and I have some thoughts of my own: > >> > > >> > - with the proposed API, it is not possible to get a trace for newly > >> > created threads - the process needs to be stopped first, so you can > >> > enable trace collection. There certainly are cases where this could be > >> > problematic, e.g. if you get a crash early during thread creation and > >> > you want to figure out how you got there. For this to work, we might > >> > need an API like > >> > SBProcess::TraceNewThreads(...) > >> > or > >> > SBProcess::TraceAllThreads(...) > >> > with the assumption that "all" also includes newly created threads in > >> > the future. > >> > > >> > I'm not saying this needs to be done in the first implementation, but > >> > I think that we should at least design the API in a way that will not > >> > make adding this unnecessarily hard in the future (e.g. the idea of > >> > returning an SBTrace object might be problematic, since you don't know > >> > if/how many threads will be created). > >> > > >> > > >> > > >> > Also, thinking about new APIs, should we have a way to mark an API as > >> > incubating/experimental? Maybe it would be good to mark these new APIs > >> > as experimental for a while, so we have an option of changing them in > >> > the future, if it turns out we have made the wrong decision. I was > >> > thinking of either a naming convention > >> > (SBThread::StartTraceExperimental) or some annotation/comment on the > >> > methods. When we are confident this design is good, we can remove the > >> > promote the api into the "stable" set. > >> > > >> > pl > >> > > >> > > >> > > >> > > >> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev > >> > wrote: > >> >> > >> >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev > >> >>> wrote: > >> >>> > >> >>> Hello all, > >> >>> I am currently working on enabling Intel (R) Processor > >> >>> Trace collection for lldb. I have done some previous discussions in > this > >> >>> mailing list on this topic but just to summarize , the path we > chose was to > >> >>> implement raw trace collection in lldb and the trace will be > decoded outside > >> >>> LLDB. I wanted to expose this feature through the SB API's and for > trace > >> >>> data transfer I wish to develop new communication packets. Now I > want to get > >> >>> the new API's and packet specifications reviewed by the dev list. > Please > >> >>> find the specification below -> > >> >>> > >> >>> lldb::SBError SBProcess::StartTrace(lldb::tid_t threadId, const > >> >>> SBTraceConfig &config) > >> >>>Start tracing for thread - threadId with trace configuration > >> >>> config. > >> >>>SBTraceConfig would contain the following fields- > >> >>>-> TraceType - ProcessorTrace, SoftwareTrace , any trace > >> >>> technology etc > >> >>>-> size of tra
Re: [lldb-dev] Review of API and remote packets
LLDB already has the QThreadSuffixSupported extension, which adds the ";thread:" suffix to a bunch of packets. We could say that if the client requests this extension, we will support it on these packets as well. Otherwise we fall back to the "Hg" thingy. I haven't looked at how hard it would be to implement that... pl On 12 April 2016 at 09:01, Ravitheja Addepally wrote: > One of the downsides of using the gdb protocol is that these packets are > stateful meaning the thread id option is not there and the word btrace > stands for branch trace which basically suggests execution tracing. > > On Mon, Apr 11, 2016 at 4:50 PM, Pavel Labath wrote: >> >> I think we should reuse packets from the gdb protocol whereever it >> makes sense. So, if they fit your needs (and a quick glance seems to >> confirm that), then I think you should use them. >> >> On 11 April 2016 at 15:28, Ravitheja Addepally >> wrote: >> > Hello, >> >Regarding the packet definitions for tracing, how about reusing >> > the >> > existing btrace packets ? >> > >> > >> > https://sourceware.org/gdb/onlinedocs/gdb/General-Query-Packets.html#qXfer%20btrace%20read >> > >> > On Fri, Apr 1, 2016 at 7:13 PM, Greg Clayton wrote: >> >> >> >> We also need to think about all other types of tracing. It might make >> >> more >> >> sense to keep these calls on SBProcess and have the calls simply be: >> >> >> >> >> >> lldb::SBTrace lldb::SBProcess::StartTrace(SBTraceOptions >> >> &trace_options, >> >> lldb::SBError &error); >> >> >> >> And you would need to specify which threads in the SBTraceOptions >> >> object >> >> itself?: >> >> >> >> SBTraceOptions trace_options; >> >> >> >> And then do some like: >> >> >> >> trace_options.SetTraceAllThreads(); >> >> >> >> And maybe tracing all threads is the default. Or one can limit this to >> >> one >> >> thread: >> >> >> >> trace_options.SetThreadID (tid); >> >> >> >> Then you start tracing using the "trace_options" which has the notion >> >> of >> >> which threads to trace. >> >> >> >> lldb::SBError error; >> >> lldb::SBTrace trace = process.StartTrace(trace_options, error); >> >> >> >> It really depends on how all different forms of trace are enabled for >> >> different kinds of tracing. It takes kernel support to trace only >> >> specific >> >> threads, but someone might be debugging a bare board that only has the >> >> option tracing all threads on each core. When making an API we can't >> >> assume >> >> we can limit this to any threads and even to any process. >> >> >> >> Greg >> >> >> >> > On Apr 1, 2016, at 2:00 AM, Pavel Labath wrote: >> >> > >> >> > I second Greg's suggestions, and I have some thoughts of my own: >> >> > >> >> > - with the proposed API, it is not possible to get a trace for newly >> >> > created threads - the process needs to be stopped first, so you can >> >> > enable trace collection. There certainly are cases where this could >> >> > be >> >> > problematic, e.g. if you get a crash early during thread creation and >> >> > you want to figure out how you got there. For this to work, we might >> >> > need an API like >> >> > SBProcess::TraceNewThreads(...) >> >> > or >> >> > SBProcess::TraceAllThreads(...) >> >> > with the assumption that "all" also includes newly created threads in >> >> > the future. >> >> > >> >> > I'm not saying this needs to be done in the first implementation, but >> >> > I think that we should at least design the API in a way that will not >> >> > make adding this unnecessarily hard in the future (e.g. the idea of >> >> > returning an SBTrace object might be problematic, since you don't >> >> > know >> >> > if/how many threads will be created). >> >> > >> >> > >> >> > >> >> > Also, thinking about new APIs, should we have a way to mark an API as >> >> > incubating/experimental? Maybe it would be good to mark these new >> >> > APIs >> >> > as experimental for a while, so we have an option of changing them in >> >> > the future, if it turns out we have made the wrong decision. I was >> >> > thinking of either a naming convention >> >> > (SBThread::StartTraceExperimental) or some annotation/comment on the >> >> > methods. When we are confident this design is good, we can remove the >> >> > promote the api into the "stable" set. >> >> > >> >> > pl >> >> > >> >> > >> >> > >> >> > >> >> > On 31 March 2016 at 18:59, Greg Clayton via lldb-dev >> >> > wrote: >> >> >> >> >> >>> On Mar 31, 2016, at 5:10 AM, Ravitheja Addepally via lldb-dev >> >> >>> wrote: >> >> >>> >> >> >>> Hello all, >> >> >>> I am currently working on enabling Intel (R) Processor >> >> >>> Trace collection for lldb. I have done some previous discussions in >> >> >>> this >> >> >>> mailing list on this topic but just to summarize , the path we >> >> >>> chose was to >> >> >>> implement raw trace collection in lldb and the trace will be >> >> >>> decoded outside >> >> >>> LLDB. I wanted to expose this feature through the SB API's and for >> >> >>> trace >> >> >>> data transfer I wis
[lldb-dev] [Bug 27326] New: Provide a way to exit lldb with a non-zero exit status
https://llvm.org/bugs/show_bug.cgi?id=27326 Bug ID: 27326 Summary: Provide a way to exit lldb with a non-zero exit status Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: john.fireba...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Please provide a way to exit scripted lldb interactions with a non-zero exit status. This is necessary for, e.g. running a debugged program in an automated test environment, and printing diagnostics and then exiting with a non-zero exit status if a crash occurs. This could take several forms: * An equivalent of GDB's "-return-child-result" option. * An argument form of "quit", e.g. "quit 1". (GDB also supports this.) For instance, I would like the following command to work as expected: lldb --batch -o 'run' -k 'thread backtrace all' -k 'quit 1' -- 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
