JDevlieghere accepted this revision. JDevlieghere added a comment. This revision is now accepted and ready to land.
Thanks Jim. This LGTM. ================ Comment at: lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTrampolineHandler.cpp:637-643 // Also we will use the version of the lookup code that doesn't rely on the // stret version of the function. - m_lookup_implementation_function_code = - g_lookup_implementation_no_stret_function_code; + m_lookup_implementation_function_code.append( + g_lookup_implementation_no_stret_function_code); } else { - m_lookup_implementation_function_code = - g_lookup_implementation_with_stret_function_code; + m_lookup_implementation_function_code.append( + g_lookup_implementation_with_stret_function_code); ---------------- jingham wrote: > JDevlieghere wrote: > > I don't understand why we need to have two versions of the code. IIUC, if > > there's a "stret return lookup function", then if we pass `is_stret == > > true` we'll use it. Otherwise we'll unconditionally use the straight > > lookup. Why do we need two variants of the code at all? Can't we pass false > > to `is_stret` and achieve the same result with the > > `g_lookup_implementation_with_stret_function_code` variant? > On the systems that don't use stret returns, > class_getMethodImplementation_stret doesn't exist. So we would either have > to have two versions of that part of the code, or passing function pointers > to the two functions (making them the same in the no _stret case) or do some > dlsym type ugliness. > > This solution is straightforward, and reducing complexity in these Utility > functions is a virtue. Having two copies of all the code was a bit bogus, > but this solution is straightforward and easy to debug. Thanks. I saw the `m_impl_stret_fn_addr` and figured we were passing in the function pointer ourselves. Makes sense. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D123421/new/ https://reviews.llvm.org/D123421 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits