Re: [lldb-dev] Review of API and remote packets
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 < > lldb-dev@lists.llvm.org> 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 trace buffer > >>>-> size of meta data buffer > >>>Returns error in case starting trace was unsuccessful, which could > occur by reasons such as > >>>picking non existent thread, target does not support TraceType > selected etc. > >> > >> If you are going to trace on a thread, we should be putting this API on > SBThread. Also we have other config type classes in our public API and we > have suffixed them with Options so SBTraceConfig should actually be > SBTraceOptions. Also don't bother using "const" on any public APIs since > the mean nothing and only cause issues. Why? All public classes usually > contain a std::unique_ptr or a std::shared_ptr to a private class that > exists only within LLDB itself. The "const" is just saying don't change my > shared pointer, which doesn't actually do anything. > >> > >> lldb::SBError SBThread::StartTrace(SBTraceOption
Re: [lldb-dev] Review of API and remote packets
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 trace buffer >> >>>-> size of meta data buffer >> >>>Returns error in case starting trace was unsuccessful, which could >> >>> occur by reasons such as >> >>>picking non existent thread, target does not support TraceType >> >>> selected etc. >> >> >> >> If you are going to trace on a thread, we should be putting this API on >> >> SBThread. Also we have other config type classes in our public API and we >> >> have suffixed them with Options so SBTraceConfig should actu
Re: [lldb-dev] [RFC] Contributing platform support for Linux on SystemZ
Hello Ulrich, It's exciting to see support for new platforms being added to LLDB. I've had a brief glance at the patch set and I was surprised at how few changes you had actually needed to make to lldb core to support this. The patches look good at a first glance, but they will need to be reviewed by respective code owners. Going forward, the best way to handle this would be to create a phabricator account and submit the patches there. This will make the review much easier. For reviewers, you can use the CODE_OWNERS.txt file (or just git history). If you don't know the right person, just pick Greg Clayton for general stuff and me or Tamas Berghammer for Linux-specific code, and we will route it further if needed. Also, please run clang-format on your patches before submission. Let me know if you need any help setting that up. > This should provide complete support for debugging the base SystemZ > platform. Not yet supported are optional features like transaction support > (zEC12) or SIMD vector support (z13). Note that there is no instruction > emulation, since our ABI requires that all code provides correct DWARF CFI > in .eh_frame to support unwinding. Is the CFI info correct at all PC locations, or only at call sites (synchronous vs. asynchronous exceptions). If it's the latter, you may still need to do some instruction emulation to "augment" the CFI info for it to be usable at non-call-sites. However, that's definitely not a blocker now... > Looking forward to working with you on getting SystemZ support upstream! I'd > also be happy to take on ongoing maintenance (setting up a build bot, fixing > issues as they come up, etc ...). Setting up a buildbot is definitely recommended and it will make further significantly easier. cheers, pl ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Do we have the equivalent of `layout asm`?
I don't believe we do. But we do have a very alpha "gui" mode which gets you into curses. It needs some work, but it is close and I am sure you could implement the layout if you take some time to implement it. Greg > On Apr 9, 2016, at 1:55 PM, Ramkumar Ramachandra via lldb-dev > wrote: > > Hi, > > gdb has a `layout asm` which is very useful while debugging assembly. > Do we have something like that in lldb? > > Thanks. > > Ram > ___ > 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] [RFC] Contributing platform support for Linux on SystemZ
Hello Pavel,
> It's exciting to see support for new platforms being added to LLDB.
> I've had a brief glance at the patch set and I was surprised at how
> few changes you had actually needed to make to lldb core to support
> this. The patches look good at a first glance, but they will need to
> be reviewed by respective code owners.
>
> Going forward, the best way to handle this would be to create a
> phabricator account and submit the patches there. This will make the
> review much easier. For reviewers, you can use the CODE_OWNERS.txt
> file (or just git history). If you don't know the right person, just
> pick Greg Clayton for general stuff and me or Tamas Berghammer for
> Linux-specific code, and we will route it further if needed.
OK, sure, I will do that. Thanks for the pointers!
> Also, please run clang-format on your patches before submission. Let
> me know if you need any help setting that up.
Well, in some cases existing / surrounding code already differs from
the format enforced by clang-format (e.g. space vs. no space before
the '(' of a function call). I've now used clang-format on all the
new files, and most other changes, except where the style would
directly contradict surrounding code.
> > This should provide complete support for debugging the base SystemZ
> > platform. Not yet supported are optional features like transaction
support
> > (zEC12) or SIMD vector support (z13). Note that there is no instruction
> > emulation, since our ABI requires that all code provides correct DWARF
CFI
> > in .eh_frame to support unwinding.
>
> Is the CFI info correct at all PC locations, or only at call sites
> (synchronous vs. asynchronous exceptions). If it's the latter, you may
> still need to do some instruction emulation to "augment" the CFI info
> for it to be usable at non-call-sites. However, that's definitely not
> a blocker now...
It should be correct at all PC locations (-fasynchronous-unwind-tables).
> > Looking forward to working with you on getting SystemZ support
upstream! I'd
> > also be happy to take on ongoing maintenance (setting up a build bot,
fixing
> > issues as they come up, etc ...).
>
> Setting up a buildbot is definitely recommended and it will make
> further significantly easier.
I'll look into setting this up once the code is in.
Thanks for your comments!
Bye,
Ulrich
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] Review of API and remote packets
I used to work on debug software at Freescale (NXP?), and we had a PPC core called e6500. It had 8 IACs (Instruction Address Comparators) that could be hooked up to the trace logic in various ways, but one really useful thing you could do was set up an IAC to turn on or off trace on a given address or address range. So we implemented tracepoints, which were like breakpoints but would turn on/off trace. I'd like to see that kind of support in a trace API. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -Original Message- From: lldb-dev [mailto:lldb-dev-boun...@lists.llvm.org] On Behalf Of Pavel Labath via lldb-dev Sent: Monday, April 11, 2016 9:51 AM To: Ravitheja Addepally Cc: LLDB Subject: Re: [lldb-dev] Review of API and remote packets 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#q > Xfer%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
