On Thu, Aug 27, 2015 at 09:48:10PM -0700, Duane Ellis wrote: > Today - you are talking about LLDB - which potentially has python under the > hood.
This can't be in python - the main LLDB code needs to support it. * LLVM supports it using a preprocessor define, which obviously won't work because it is compiled in. LLVM will have to be made to check flags at runtime. * LLDB can be fixed to support both via it's PathSyntax functionality, but the question is how to do this cleanly. I proposed adding an option. > My solution worked like this: > > When GDB failed to find the filename by ???the normal means??? - I made GDBTK > call a TCL/TK function > > If that function did not exist - the code just gave up - too bad you do not > get to find the file. > This was the default action if you (the user) did not provide a lookup > function. > > If that function existed - in my case, we wrote one or two functions for each > project > And, when you launched GDB we just did a ???source project_paths.tcl??? in > the .gdbinit script Yeah, that was the gdb way of supporting alternate functionality (to check if a function was defined and call it) - it worked pretty well. It doesn't really fit in well with LLDB design however. LLDB's way of supporting alternate functionalities is through plugins or options. In this case an option seems most reasonable. Thanks, -Dawn _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
