Ted, I think this is fixed by r264096 Can you try and make sure it works for you?
> On Mar 21, 2016, at 2:51 PM, Enrico Granata via lldb-dev > <lldb-dev@lists.llvm.org> wrote: > > >> On Mar 21, 2016, at 2:27 PM, via lldb-dev <lldb-dev@lists.llvm.org >> <mailto:lldb-dev@lists.llvm.org>> wrote: >> >> Bug ID 27020 <https://llvm.org/bugs/show_bug.cgi?id=27020> >> Summary "command alias r run" causes an assert >> Product lldb >> Version unspecified >> Hardware PC >> OS Windows NT >> Status NEW >> Severity normal >> Priority P >> Component All Bugs >> Assignee lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> Reporter ted.woodw...@codeaurora.org <mailto:ted.woodw...@codeaurora.org> >> CC llvm-b...@lists.llvm.org <mailto:llvm-b...@lists.llvm.org> >> Classification Unclassified >> >> This happens on Linux and Windows; probably all platforms. >> >> >bin/lldb /bin/ls >> (lldb) target create "/bin/ls" >> Current executable set to '/bin/ls' (x86_64). >> (lldb) command alias r run >> warning: Overwriting existing definition for 'r'. >> (lldb) r >> CommandAlias::Execute is not to be called >> UNREACHABLE executed at >> /local/scratch/ted/tip/llvm/tools/lldb/source/Interpreter/CommandAlias.cpp:181! >> Abort (core dumped) >> >> You are receiving this mail because: >> You are the assignee for the bug. >> _______________________________________________ >> lldb-dev mailing list >> lldb-dev@lists.llvm.org <mailto:lldb-dev@lists.llvm.org> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > Ted, > unfortunately I am more than a little busy at the moment - and it would > probably be a day or two before I can actually take a meaningful look at this > > On the other hand, I suspect I know what the issue you’re running into is > > Due to existing complexity in the interpreter, a CommandAlias isn’t directly > executable. So, we have CommandInterpreter::BuildAliasResult() which is the > function that is responsible for taking an alias apart and passing the pieces > to the command interpreter for actual execution. > In your case, what is happening is that you have an alias to an alias, so the > underlying command is actually an alias > > What one would need to try and do is write a recursive function that, given > an alias, potentially nested, spits out the final OptionArgVectorSP and > non-alias CommandObject > It is something I can work on, but as I said, it’s going to be a few days > before I can get to it. So, if you want to try your hand at a patch to this > effect, I would be most happy to take a look at it > > Apologies for the breakage and thanks for reporting this > > - Enrico > > _______________________________________________ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev Thanks, - Enrico 📩 egranata@.com ☎️ 27683
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
