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

[tritao]

What is the status of this one? There have been patches to the list reworking the declspec support, so this might be fixed.

[llvmbot]

Clang issues just a warning when it encounters __declspec(thread), at least in linux:

conftest.c:45:16: warning: __declspec attribute 'thread' is not supported [-Wignored-attributes]

In fact this will lead to some hard to debug runtime issues (in the case if the warning is ignored by the users or build scripts). Would it possible to promote this from a warning to an error? Or just alias __declspec(thread) to __thread?

[oscarfv]

haael: please don't mess with the fields of the bug form.

[llvmbot]

haael: please don't mess with the fields of the bug form.

I'm sorry. I opened the wrong ticket accidentally.

[rnk]

Clang can handle these, but exporting or importing a full record decl is covered by http://llvm.org/bugs/show_bug.cgi?id=11170 .

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#6275

[llvmbot]

mentioned in issue llvm/llvm-bugzilla-archive#6815