[cfe-dev] CABI project

[João Matos]

Sorry for digging such an old thread :)

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.

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.

I guess another direction would be to separate those classes in an
LLVM/CodeGen-independent project (clangABI).

Does any of this sound reasonable? Anyone have some ideas on what approach
to take here?


On Tue, Oct 16, 2012 at 8:11 PM, Dave Abrahams <dave at boostpro.com> wrote:

>
> [ redirected at cfe-dev ]
>
> on Tue Oct 16 2012, John McCall <rjmccall-AT-apple.com> wrote:
>
> > On Oct 16, 2012, at 11:45 AM, Dave Abrahams wrote:
> >> I'm working on a project to separate from Clang all the logic necessary
> >> to generate C/C++/ObjC-ABI-compatible code so that other front-ends,
> >> both C family (e.g. Dragonegg, and in BoostPro's case, EDG) and other
> >> languages/code generators, can interoperate with C family code.
> >
> > So, specifically, this would be some sort of API where you give it a C
> > function type and it tells you how to pass those arguments in LLVM IR?
>
> Oh, way more than that.  It has to deal with exception-handling, object
> layout, vtable layout, yada yada... and probably a few
> ObjectiveC-specific things I don't know about (not being versed in
> ObjC).
>
> > Seems commendable, but there's a lot of hidden complexity here.
>
> Don't I know it!  As I mentioned, I've been digging around in the code
> extensively and it's clearly a nontrivial undertaking.
>
> > Is there anything more to it than that?  Are you also going to try to
> > abstract, say, the sizes and alignments of fundamental types?
>
> yes
>
> > Struct layout?  Anything else?
>
> yes and yes.  Lots else.
>
> >> Eventually I want to put this work in a separate project that sits
> >> between Clang and LLVM, but for now, at Chandler's suggestion, I plan to
> >> make it a sub-library of Clang (I'll set up the CMakeLists.txt so the
> >> CABI library can't see the rest of clang).
> >
> > Sounds reasonable.
> >
> >> Suggestions, feedback, interaction welcomed.  Not my highest priority,
> >> but if anyone has a better name than CABI it would relieve one nagging
> >> source of discomfort ;-)
> >
> > If it's just about the C ABI, that seems like a fine name for it.
>
> No, it's C/C++/ObjC ABI.
>
> --
> Dave Abrahams
> BoostPro Computing                  Software Development        Training
> http://www.boostpro.com             Clang/LLVM/EDG Compilers  C++  Boost
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>



-- 
João Matos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130820/52b08814/attachment.html>