Yeah that does sound like a reasonable way to go about it. I'll have Tong mull that over a bit and come back with any questions.
Thanks for your thoughts, Jim! -Todd On Tue, Aug 12, 2014 at 11:32 AM, <[email protected]> wrote: > And of course, you could have two "java" languages, like "pure-java" and > "mixed-java" which would either provide annotated C frames, or pure Java > frames. > > Jim > > > On Aug 12, 2014, at 11:26 AM, [email protected] wrote: > > > > So we don't currently have any Java support in the expression parser, > but if we did, there would be a Java Language runtime that would assist > this, and also know how to do things like "step from one Java invocation to > another" rather than having to plow through all the intervening interpreter > code, etc... Given that the is an intrinsic part of new language support > in lldb, it would be pretty natural for the LanguageRuntimes to also be > able to provide "alternate backtraces". Then the backtrace command would > take an "-l" option for setting the language runtime that provides the > backtraces (all the C based languages would use the native unwinder.) > Finally, you could have a setting to set the default backtrace language, > so for your Java only developers, they would just set this setting in their > .lldbinit file, and then "bt" would show then what the Java language > runtime showed. > > > > Does this sound reasonable? > > > > Jim > > > > > >> On Aug 11, 2014, at 6:29 PM, Todd Fiala <[email protected]> wrote: > >> > >> Just to expand a bit on what Tong mentioned: > >> > >> When we're running some of our Android Java code in interpreted mode > (as opposed to AOT compiled), we can get multiple interpreter > implementation frames (native frames) that correspond to a single > user-visible Java frame. We'd like to enable hiding/collapsing those > implementation details of the interpreter into the single user-visible Java > frame that they're representing. For the most part, the folks that will > want to really see the interpreter implementation details are the ART > developers. Most of the rest of us just want to see the Java frame. > >> > >> We'd be happy to put that behavior on a flag when debugging Android > mixed Java/C/C++ code. > >> > >> Tong's comment about putting it on the 'bt' command is meant to cover: > >> • having this functionality translate to API calls that get frames. > >> • have it be the default way back traces are displayed without > requiring users to use some other "back trace-like" command. (Clearly we > could implement this as another command that does the interpretation, but I > suspect this would then require clients of the API to know this and call > something different than the standard backtrace calls to get it). > >> A while back, Greg and I chatted about this on lldb-dev and I think we > were looking to consider a stack annotation path to handle this, where the > change needed for our purposes would be putting the annotations in-line > (rather than displayed at the bottom IIRC). I think the diff now is that > we see we have multiple "source" stack frames (the interpreter > implementation detail frames) that map to one user-visible frame. This > almost suggests a possible frame-mapping layer where there's an underlying > frame model, and a presentation of it that we show to users/API. But that > can also be getting over-complicated. > >> > >> Any thoughts on this would be great since it's deep in your area. > Thanks, Jason! > >> > >> -Todd > >> > >> > >> On Mon, Aug 11, 2014 at 4:26 PM, Tong Shen <[email protected]> > wrote: > >> Hi Jason, > >> > >> For mixed native/Java code (or native/Python code, > native/SomeFancyProgrammingLanguage code), sometimes we want a "prettier" > stack trace for users. > >> > >> For example, we may want to: > >> - skip Java->native wrapper functions, or trampolines that means > nothing to users; > >> - merge several frames together, because in Java world it's just one > stack frame; > >> - do some language runtime related function calls to get certain > runtime data; > >> - put an elephant into refrigerator. > >> > >> What do you think is the best way to do this? > >> If possible, we want to do all these in 'bt' command, so it's more > intuitive for users. Or we can extend the stack annotations to do this. > >> But if they all seem too messy to you, we certainly can keep it out of > your way and maybe write a new command for it. > >> > >> Thanks in advance! > >> > >> -- > >> Best Regards, Tong Shen > >> > >> > >> > >> -- > >> Todd Fiala | Software Engineer | [email protected] | > 650-943-3180 > >> > >> _______________________________________________ > >> lldb-dev mailing list > >> [email protected] > >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev > > > > -- Todd Fiala | Software Engineer | [email protected] | 650-943-3180
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
