CABI project

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?
Seems commendable, but there's a lot of hidden complexity here.

Is there anything more to it than that? Are you also going to try to
abstract, say, the sizes and alignments of fundamental types?
Struct layout? Anything 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 :wink:

If it's just about the C ABI, that seems like a fine name for it.

John.

[ redirected at cfe-dev ]

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 :wink:

If it's just about the C ABI, that seems like a fine name for it.

No, it's C/C++/ObjC ABI.

Could you give more details about it?

I don’t fully understand the scope of this library or what parts of Clang it will wrap / replace.

Right now using the AST library you can already get the calling convention, virtual layout and name manglings of objects.

Will this also provide backend things, like low-level calling convention details for each platform?

How will exception handling details be provided?

Will this provide a simplified interface to get all the data using the other Clang libraries or will the rest of Clang actually depend on this library?

The idea sounds interesting and it’s nice to see you work on this.

Oh, uh, that's an enormous project. In what way, precisely, is this not
a proposal to reinvent all of IR-generation as another level of abstraction?

John.

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).

Oh, uh, that's an enormous project.

Quite so.

In what way, precisely, is this not a proposal to reinvent all of
IR-generation as another level of abstraction?

I'm not sure whether it amounts to that, but I suppose it could
eventually end up there, in the long-term. Initially I'm interested in
abstracting out enough to handle C, which I think mostly just amounts to
what you said above, i.e. argument passing, (and, I guess, varargs
interpretation).

A little further out, there's support for C++, but having talked to Doug
a bit more, it's clear to me that EDG has already done quite a few of
these things (e.g. vtables, generation of exception-handling cleanups
and landing pads) in its front-end, so for my particular application
those bits don't have to be abstracted out.

For this library to be fully useful from code generators that aren't
already C++ front-ends, you'd probably want to handle some of these
other things too... but that's way off in the future if it happens.

I think that's a good problem space to work in, and it's one that could
be extremely useful to a large number of projects (including clang).

John.

A good place to start would be to factor out just the C ABI support
from Clang, which is a much smaller project than the C++ ABI and would
still be hugely useful.

-Joe

In what way, precisely, is this not a proposal to reinvent all of
IR-generation as another level of abstraction?

I'm not sure whether it amounts to that, but I suppose it could
eventually end up there, in the long-term. Initially I'm interested
in abstracting out enough to handle C, which I think mostly just

       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

amounts to what you said above, i.e. argument passing, (and, I
guess, varargs interpretation).

I think that's a good problem space to work in, and it's one that could
be extremely useful to a large number of projects (including clang).

A good place to start would be to factor out just the C ABI support
from Clang, which is a much smaller project than the C++ ABI and would
still be hugely useful.

Hi Joe,

I think that's where I said I want to start. Am I missing some subtle
distinction or did you overlook that, or...?

Thanks,

No Dave, I'm just bad at reading and fixated on all the talk of the
hugeness of C++. Cheers.

-Joe

João Matos <ripzonetriton@gmail.com> writes:

I don't fully understand the scope of this library or what parts of Clang it
will wrap / replace.

Imagine you have some language X and you want to call into a C library on
x86_64. The rules for argument passing are complex enough that CreateCall
alone won't cut it. Clang solves this problem for its users by implementing
that part of the x86_64 ABI in CodeGen; but what about all other LLVM users?

Now imagine you had a tidy library called LLVMabi or so, which, when combined
with LLVM, allows you to fully interop with any C++ library from any language.
This is the grail we're questing after -- and which currently doesn't exist in
any form I know of (even projects like libffi look to confine themselves to C
considerations only).

The other set of users this will benefit is folks who have a C++ front-end,
and want to use LLVM as their new back-end, but suddenly wake up and realize
that solving the ABI problem is an even bigger job than writing the type
translator and IR generator from their ASTs! Further, it reaches into a
problem domain they may not have addressed yet for every platform the LLVMabi
would eventually target.

Sorry for digging such an old thread :slight_smile:

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?