Clang Microsoft CXX ABI support?

Hello gentlemen,

I'm working on AddressSanitizer (a.k.a. ASan,
http://code.google.com/p/address-sanitizer/ ) and trying to port it to
Windows.

So far we've made good progress using Clang as a C frontend
( see http://code.google.com/p/address-sanitizer/wiki/WindowsPort )
but struggle to make basic C++ programs work with the Microsoft CXX ABI.

I've found a few bugs already which show that Clang++ can't
compile/mangle some really basic stuff with this ABI.

Here's an ASan meta-bug to track the list of Clang++ bugs:
http://code.google.com/p/address-sanitizer/issues/detail?id=56

Can you please suggest what to do with these bugs?

[I'm very not familiar with the Clang source code neither have I
experience in writing compilers but I hope I'll be able to fix at
lesat some trivial stuff with a little guidance]

Thanks a lot!
Timur Iskhodzhanov,
Google Russia

None of the core clang developers is doing any work on the Microsoft
ABI; filing bugs isn't going to change that.

You might want to try using MinGW.

-Eli

While none of the core developers are, there are few regular contributors who are looking into this. Certainly, filing bugs doesn’t do anything in and of itself, but if you and/or others are planning to work on these bugs, tracking them in bugzilla seems reasonable to me…

The thing we don’t want are bugs which literally no one is going to ever close; my hope is that this is not the case here.

The thing we don't want are bugs which literally no one is going to ever
close; my hope is that this is not the case here.

Also, it might make sense to provide a meta bug and link all the stuff there.

Thank you for the responses!
I wonder if finishing the Microsoft ABI could be a good GSoC project :slight_smile:
AFAIK, the current implementation was done last GSoC, right?

The thing we don't want are bugs which literally no one is going to ever
close; my hope is that this is not the case here.

Also, it might make sense to provide a meta bug and link all the stuff there.

Do I read it right?
You mean create something like a "Fully support Microsoft ABI" bug and
put a comment with a link for every new small bug I file?

Timur,

Thank you for the responses!
I wonder if finishing the Microsoft ABI could be a good GSoC project :slight_smile:

I think the "easy" part was covered during that project and hard and
non-obvious part (vtable layout) left.
So, it might be too hard for another GSoC project

Do I read it right?
You mean create something like a "Fully support Microsoft ABI" bug and
put a comment with a link for every new small bug I file?

Almost. No need for comments - bugzilla already has "depends on"
facility to link the PRs.

That project really covered a very small amount of the necessary work;
I'd be happy to have another student continue with it. Things not yet
implemented include constructors, destructors, member pointers,
derived-to-base conversions that hop virtual bases, RTTI, dynamic_cast,
virtual calls, vf-table emission, vb-table emission, and I'm probably
forgetting a number of other things. There's also a lot still to be done
with mangling, IIRC.

vf-table layout would be a challenging project, but I don't think it's
unreasonable as a full-summer thing for a student with previous
clang experience. It also nicely breaks down into sub-projects,
since you can start with the simplest cases (single non-virtual
inheritance, no thunks) and gradually add complexity.

John.

Do I read it right?
You mean create something like a "Fully support Microsoft ABI" bug and
put a comment with a link for every new small bug I file?

Almost. No need for comments - bugzilla already has "depends on"
facility to link the PRs.

http://llvm.org/bugs/show_bug.cgi?id=12477 - Done!
Thank you for the idea!

Thank you for the responses!
I wonder if finishing the Microsoft ABI could be a good GSoC project :slight_smile:

I think the "easy" part was covered during that project and hard and
non-obvious part (vtable layout) left.
So, it might be too hard for another GSoC project

That project really covered a very small amount of the necessary work;
I'd be happy to have another student continue with it. Things not yet
implemented include constructors, destructors, member pointers,
derived-to-base conversions that hop virtual bases, RTTI, dynamic_cast,
virtual calls, vf-table emission, vb-table emission, and I'm probably
forgetting a number of other things. There's also a lot still to be done
with mangling, IIRC.

vf-table layout would be a challenging project, but I don't think it's
unreasonable as a full-summer thing for a student with previous
clang experience. It also nicely breaks down into sub-projects,
since you can start with the simplest cases (single non-virtual
inheritance, no thunks) and gradually add complexity.

I see an another thread from Charles [+cc] on pretty much this topic
as a GSoC project proposal.
Will talk to him there.
Thank you for the info!