<div dir="ltr">Sorry for digging such an old thread :)<div><br></div><div>I've been working on project that needs accurate C++ ABI details and Clang's AST library has worked beautifully so far, but getting at some details (which types need to be passed/returned indirectly for instance) has proved a bit troublesome since they are buried deep within the CodeGen project internal headers. Anyway I remembered this thread and wondered if anyone was still looking into it.<br>
</div><div><br></div><div>Would it be acceptable to make some of the classes in CodeGen public? This would be a very useful first step, but even so one needs to jump through many hoops to get at the data (setting up an LLVM Context and Module). From my brief analysis, the most useful types for external consumers seem to be ABIArgInfo, TargetCodeGenInfo and friends.</div>
<div><br></div><div>I guess another direction would be to separate those classes in an LLVM/CodeGen-independent project (clangABI).</div><div><br></div><div>Does any of this sound reasonable? Anyone have some ideas on what approach to take here?</div>
<div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 16, 2012 at 8:11 PM, Dave Abrahams <span dir="ltr"><<a href="mailto:dave@boostpro.com" target="_blank">dave@boostpro.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
[ redirected at cfe-dev ]<br>
<br>
on Tue Oct 16 2012, John McCall <rjmccall-AT-apple.com> wrote:<br>
<br>
> On Oct 16, 2012, at 11:45 AM, Dave Abrahams wrote:<br>
>> I'm working on a project to separate from Clang all the logic necessary<br>
>> to generate C/C++/ObjC-ABI-compatible code so that other front-ends,<br>
>> both C family (e.g. Dragonegg, and in BoostPro's case, EDG) and other<br>
>> languages/code generators, can interoperate with C family code.<br>
><br>
> So, specifically, this would be some sort of API where you give it a C<br>
> function type and it tells you how to pass those arguments in LLVM IR?<br>
<br>
Oh, way more than that. It has to deal with exception-handling, object<br>
layout, vtable layout, yada yada... and probably a few<br>
ObjectiveC-specific things I don't know about (not being versed in<br>
ObjC).<br>
<br>
> Seems commendable, but there's a lot of hidden complexity here.<br>
<br>
Don't I know it! As I mentioned, I've been digging around in the code<br>
extensively and it's clearly a nontrivial undertaking.<br>
<br>
> Is there anything more to it than that? Are you also going to try to<br>
> abstract, say, the sizes and alignments of fundamental types?<br>
<br>
yes<br>
<br>
> Struct layout? Anything else?<br>
<br>
yes and yes. Lots else.<br>
<br>
>> Eventually I want to put this work in a separate project that sits<br>
>> between Clang and LLVM, but for now, at Chandler's suggestion, I plan to<br>
>> make it a sub-library of Clang (I'll set up the CMakeLists.txt so the<br>
>> CABI library can't see the rest of clang).<br>
><br>
> Sounds reasonable.<br>
><br>
>> Suggestions, feedback, interaction welcomed. Not my highest priority,<br>
>> but if anyone has a better name than CABI it would relieve one nagging<br>
>> source of discomfort ;-)<br>
><br>
> If it's just about the C ABI, that seems like a fine name for it.<br>
<br>
No, it's C/C++/ObjC ABI.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dave Abrahams<br>
BoostPro Computing Software Development Training<br>
<a href="http://www.boostpro.com" target="_blank">http://www.boostpro.com</a> Clang/LLVM/EDG Compilers C++ Boost<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br>João Matos
</div></div>