Re: [lldb-dev] Review of API and remote packets
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 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(SBTraceOptions &trace_options); > >> >> lldb::SBError SBProcess::StopTrace(lldb::tid_t threadId) >> Stop tracing for thread - threadId. Tracing should be enabled already >> for thread, else error is returned. > > This should be: > > lldb::SBError SBThread::StopTrace(); > > One question: can there only be one kind of trace going on at the same time? > If we ever desire to support more than one at a time, we might need the above > two calls to be: > > > lldb::user_id_t SBThread::StartTrace(SBTraceOptions &trace_options, > lldb::SBError &error); > lldb::SBError SBThread::StopTrace(lldb::user_id_t trace_id); > > The StartTrace could return a unique trace token that would need to be > supplied back to any other trace calls like the ones below. > >> size_t SBProcess::DumpTraceData(lldb::tid_t threadId, void *buf, size_t >> size, SBError &sberror) >> Dump the raw trace data for threadId in buffer described by pointer buf >> and size. Tracing should be enabled already for thread else error >> is sent in sberror. The actual size of filled buffer is returned by API. >> >> size_t SBProcess::DumpTraceMetaData(lldb::tid_t threadId, void *buf, size_t >> size, SBError &sberror) >> Dump the raw trace meta data for threadId in buffer described by pointer >> buf and size. Tracing should be enabled already for thread >> else error is sent in sberror. The actual size of filled buffer is >> returned by API. > > These would be on lldb::SBThread and remove the lldb::tid_t parameter, > possibly adding "lldb::user_id_t trace_id" as the first parameter. > > The other way to do this is to create a lldb::SBTrace
Re: [lldb-dev] SBProcess::Detach kills target
> It might be also possible to run an expression that will route
> stdin/stdout/stderr to /dev/null before detaching if we know that we have a
> master/slave pty hooked up the the inferior's in/out/err. We could run an
> expression like:
(At least on linux) you would also need something like:
ioctl(open("/dev/tty", O_RDWR), TIOCNOTTY)
without it, the process will remain tied to the pty and will get a
HUP. Then redirection of file descriptors becomes optional: The
program will not get a SIGHUP, although it will get a SIGPIPE if it
tries to write some output to the slave end of the pty.
On 31 March 2016 at 22:44, Eugene Birukov wrote:
> OK, I got the picture, thanks a lot!
>
> > What is it that you are trying to do anyway?
>
> Well, target termination during detach is unexpected, so my customers might
> get confused.
In case of a console debugger, I don't think anybody would even try
detaching from a launched program. For a graphical debugger, yes, it
will be confusing. In case you don't need access to inferior stdio
running with "process launch --no-stdio" might be an option. Right
now, it redirects io to /dev/null, but it still sets up a controlling
pty, which means you get the SIGHUP. However, I don't think a pty is
needed in this case and it sounds like it could be a good idea to
avoid creating it. Patches welcome.
pl
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] [Bug 27179] New: test infra: Green Dragon OS X builder is sometimes accessing an unguarded missing dictionary key, xUnit formatter
https://llvm.org/bugs/show_bug.cgi?id=27179 Bug ID: 27179 Summary: test infra: Green Dragon OS X builder is sometimes accessing an unguarded missing dictionary key, xUnit formatter Product: lldb Version: unspecified Hardware: Macintosh OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified This started showing up on the Green Dragon builder. It looks like it happens when a timeout or exceptional exit occurs and cannot be charged to a test method (which happens when no test method was running when said issue occurs). It looks like there is logic in the wrap-up that is not accounting for the case that a method/class name is unavailable, and crashes the test suite when doing the summarization of results. This looks like it may be limited to the Xunit case. -- 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] [Bug 27179] test infra: Green Dragon OS X builder is sometimes accessing an unguarded missing dictionary key, xUnit formatter
https://llvm.org/bugs/show_bug.cgi?id=27179 Todd Fiala changed: What|Removed |Added Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com -- 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] [Bug 27180] test infra: OS X Green Dragon - switch to run tests with just-built clang
https://llvm.org/bugs/show_bug.cgi?id=27180 Todd Fiala changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com OS|All |MacOS X -- 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] [Bug 27180] New: test infra: OS X Green Dragon - switch to run tests with just-built clang
https://llvm.org/bugs/show_bug.cgi?id=27180 Bug ID: 27180 Summary: test infra: OS X Green Dragon - switch to run tests with just-built clang Product: lldb Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified Currently we run tests with the prevailing clang on the system. If we're just running tests against one clang on LLVM.org LLDB svn trunk, we want that to be the latest built clang. We will later come back and add a matrix of important clang versions for OS X and run the tests against each, much like the Google Linux buildbot. -- 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] [Bug 27181] New: Xcode gtests: ensure they run, not just build, on Xcode target
https://llvm.org/bugs/show_bug.cgi?id=27181 Bug ID: 27181 Summary: Xcode gtests: ensure they run, not just build, on Xcode target Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified On OS X Xcode builds, the gtest target should be able to be run when using the Test action. Currently this isn't so, and the Green Dragon OS X bot only builds but does not run the gtest. Do the following: 1. Make the Test action on the gtest target actually run the LLDB tests. 2. Fix/suppress the known failing gtest (one of the recent ones). 3. Fix the Green Dragon OS X build rules to run the test action on the gtest target. -- 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] [Bug 27181] Xcode gtests: ensure they run, not just build, on Xcode target
https://llvm.org/bugs/show_bug.cgi?id=27181 Todd Fiala changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|lldb-dev@lists.llvm.org |todd.fi...@gmail.com -- 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] ReadCStringFromMemory deprecated? (API)
Hey, I noticed that SBProcess::ReadCStringFromMemory uses the deprecated Process::ReadCStringFromMemory function. The note says that it was deprecated in favor of ReadStringFromMemory. Is it possible to add that function to the SBProcess api ? ___ 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
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 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(SBTraceOptions &trace_options); >> >>> >>> lldb::SBError SBProcess::StopTrace(lldb::tid_t threadId) >>>Stop tracing for thread - threadId. Tracing should be enabled already >>> for thread, else error is returned. >> >> This should be: >> >> lldb::SBError SBThread::StopTrace(); >> >> One question: can there only be one kind of trace going on at the same time? >> If we ever desire
[lldb-dev] [Bug 27182] New: TestCallWithTimeout.py failing on OS X
https://llvm.org/bugs/show_bug.cgi?id=27182 Bug ID: 27182 Summary: TestCallWithTimeout.py failing on OS X Product: lldb Version: unspecified Hardware: PC OS: MacOS X Status: NEW Severity: normal Priority: P Component: All Bugs Assignee: lldb-dev@lists.llvm.org Reporter: todd.fi...@gmail.com CC: llvm-b...@lists.llvm.org Classification: Unclassified This test started failing recently on the Green Dragon OS X builder. Marking XFAIL while it is being investigated. -- 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
