Does anyone have any further feedback on this patch, and if not does it look good to go in?
Thanks, Mark On Oct 8, 2013, at 8:42 PM, Mark Lacey <[email protected]> wrote: > Hi David, > > On Oct 8, 2013, at 6:33 PM, David Blaikie <[email protected]> wrote: > >> To any particular end? (is there a need for this - I could imagine it's just >> convenient to implement the way it is now) > > Yes - I have been planning on sending something to cfe-dev once I had more to > talk about. In the meantime I have been preparing and sending a few small > changes that seem like generally good changes on their own, and that also > help with a larger change I am investigating. > > I am looking at exposing ABI information for use in LLDB. One example of > where this would be useful would be for ‘thread step-out’ (aka finish). When > you do a step-out, it currently attempts to display the returned value, but > this is all hard-coded in LLDB for each platform, and has limits on at least > some of them in terms of what is supported. The idea is to expose enough > about how Clang types are mapped to LLVM types, and then how LLVM types are > mapped to actual locations (registers or memory) according to the ABI, to > make it simple for LLDB to support this kind of functionality more completely > with less effort and less chance of disagreement between the generated code > and where LLDB thinks things live. > > The current tight coupling between CodeGenModule, CodeGenTypes, and ABIInfo > has made it difficult to make progress experimenting with different ways of > exposing interfaces that could be used by LLDB to get from Clang types to > LLVM types (the last two really are mutually dependent at this point, and > there does not seem to be an easy way around that or substantial benefit in > trying to separate out their creation right now). > > Thanks, > > Mark > > >> >> >> On Tue, Oct 8, 2013 at 5:45 PM, Mark Lacey <[email protected]> wrote: >> Hi - >> >> Please review and let me know if you have any feedback. >> >> Thanks, >> >> Mark >> >> ---------------- >> >> >> Currently the only way to create a CodeGenTypes class is to pass it a >> CodeGenModule, which is primarily used to initialize the members of >> CodeGenTypes, but is also used in a couple of places to gain access to a >> few members of CodeGenModule (OpenCLRuntime, DebugInfo, >> and TargetCodeGenInfo). >> >> This change makes it possible to construct a CodeGenTypes class >> independently of a CodeGenModule. The constructor to CodeGenTypes is >> updated to explicitly have parameters for each of its members, and new >> pointer members are added for the information that was being referenced >> from CodeGenModule. >> --- >> lib/CodeGen/CGCall.cpp | 2 +- >> lib/CodeGen/CodeGenModule.cpp | 12 +++-- >> lib/CodeGen/CodeGenTypes.cpp | 24 ++++++---- >> lib/CodeGen/CodeGenTypes.h | 28 +++++++++-- >> lib/CodeGen/TargetInfo.cpp | 106 >> ++++++++++++++++++++++++------------------ >> 5 files changed, 111 insertions(+), 61 deletions(-) >> >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> >> > > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
