Clang doesn't support declspec attributes

[llvmbot]

Bugzilla Link	6269
Resolution	FIXED
Resolved on	Sep 23, 2013 17:12
Version	trunk
OS	Windows XP
Blocks	llvm/llvm-bugzilla-archive#6815
Reporter	LLVM Bugzilla Contributor
CC	@asl,@tritao,@oscarfv,@rjmccall,@rnk

Extended Description

Hi,
I've tried this testcase with both Clang and (mingw32)gcc 4.4.3 :

__declspec(dllimport) void foo (int); void bar (void) { foo (0); }

The result was :

GCC :

.file	"testcase.c"
.text

.globl _bar
.def _bar; .scl 2; .type 32; .endef
_bar:
pushl %ebp
movl %esp, %ebp
subl $24, %esp
movl $0, (%esp)
movl __imp__foo, %eax
call *%eax
leave
ret

Clang :

.def	 _bar;	.scl	2;	.type	32;	.endef
.text
.globl	_bar
.align	16

_bar:
pushl %ebp
movl %esp, %ebp
subl $8, %esp
movl $0, (%esp)
call _foo
addl $8, %esp
popl %ebp
ret

.def	 _foo;	.scl	2;	.type	32;	.endef

It seems like clang doesn't seem to do name decorations. foo should have extension @​4 which is probably due to not handling the stdcall calling convention.

Please let me know how I can further help resolving this issue.

[llvmbot]

I think this is not about stdcall, but about dllimport.

[rjmccall]

Yes, I agree, this has nothing to do with calling conventions.

[llvmbot]

I'm with Duncan and John on this one.

The problem is that you used the __declspec() version of the attribute, which clang doesn't support, as you can see in SemaDeclAttr.cpp:

if (Attr.isDeclspecAttribute())
// FIXME: Try to deal with __declspec attributes!
return;

Did you try it with:

attribute((dllimport)) void foo (int); void bar (void) { foo (0); }

?

[llvmbot]

I tried with attribute((dllimport)) and got the same result.

[asl]

Function does not have stdcall calling convention, thus it should not be decorated.

[llvmbot]

Anton: You're right, but this bug isn't about stdcall anymore. It's about generating wrong code for calls to dllimport functions.

Like I was explaining earlier on IRC, this isn't a clang problem, but an LLVM problem.

When clang sees something like:

attribute((dllimport)) void foo(int);

it generates this LLVM IR (unnecessary details omitted):

declare dllimport void @​foo(i32)

That way, it can emit calls to foo() like usual:

define void @​bar() {
.begin:
call void @​foo(i32 0)
ret void
}

The problem lies in the X86CodeGen library (in lib/Target/X86), which is responsible for turning this into x86 assembly. I suspect that it doesn't yet know how to properly codegen calls to functions with dllimport linkage.

[asl]

The problem lies in the X86CodeGen library (in lib/Target/X86), which is
responsible for turning this into x86 assembly. I suspect that it doesn't yet
know how to properly codegen calls to functions with dllimport linkage.
Trust me, it does since LLVM 1.7 when I implemented this :) How else we're supposed to compile bunch of stuff with llvm-gcc (e.g. Qt?)

I was too fast, retitling bug, we do support dllimport codegen if declared
via attribute.

However, I'm seeing rather weird results:

1. clang -cc1 -triple=i386-mingw32 -S dllimp.c produces no __imp stuff
2. But clang -cc1 -triple=i386-mingw32 -S dllimp.c -emit-llvm && llc dllimp.ll
   produces correct assembler.

[llvmbot]

Yeah, I noticed that myself.

That is very strange. I think we've got two bugs here.

• Clang doesn't support declspec attributes
• Clang doesn't codegen calls to dllimport functions properly

I'll file the second bug so we can focus on the issue with declspec here.

[llvmbot]

• Clang doesn't support declspec attributes

It seems fixed :p

• Clang doesn't codegen calls to dllimport functions properly

Fixed in r116184.

[llvmbot]

• Clang doesn't support declspec attributes

It seems fixed :p
Yes, Clang supports some declspec attributes, but not all of them, or even a significant portion of them, for that matter. In fact, the only ones handled are dllimport and dllexport. Reopening.

[llvmbot]

Should '__declspec(align(n))' support be handled here or it is separate bug?

[rubenvb]

With current Clang, this is still a problem. This makes Clang quite unusable for building shared libraries on Windows, because they like to rely on the dllimport/dllexport stuff a lot.

The testcase.c from above generates:
M:\Development\x64\test>clang -c foo.c
foo.c:1:1: warning: unknown attribute 'dllimport' ignored [-Wattributes]
__declspec(dllimport) void foo (int); void bar (void) { foo (0); }
^
foo.c:1:12: note: instantiated from:
__declspec(dllimport) void foo (int); void bar (void) { foo (0); }
^
1 warning generated.

If the code is already in LLVM, then the attribute only needs to be passed down to X86 codegen, or am I seeing this to simple?

[asl]

If the code is already in LLVM, then the attribute only needs to be passed down
to X86 codegen, or am I seeing this to simple?
clang definitely supports dllimport / dllexport stuff. Check e.g. test/CodeGen/dllimport-dllexport.c for the testcase

[rubenvb]

If the code is already in LLVM, then the attribute only needs to be passed down
to X86 codegen, or am I seeing this to simple?
clang definitely supports dllimport / dllexport stuff. Check e.g.
test/CodeGen/dllimport-dllexport.c for the testcase

OK, I think this isn't getting properly enabled for x86_64-w64-mingw32. These things are common to all things Windows, so both Triple::OSType::MinGW32 and Triple::OSType::Win32, regardless of architecture. The warning did not get emitted for a i686-w64-mingw32 hosted Clang. Probably the implementation isn't being used for 64-bit as well.

[rubenvb]

OK, it seems it's just the warning that needs to be removed for x86_64--mingw. The produced symbol table seems ok. Although I don't know why the dll(ex/im)port symbols are marked with "fake".