error: redeclaration of 'foo' cannot add 'dllexport' attribute

[lhmouse]

If a function is declared without dllexport and called, but is later defined with dllexport, clang generates an error. GCC does not suffer from this issue (the attributes are merged, as if all declarations had dllexport).

void
foo(void);

void
bar(void)
  {
    foo();  /* the error goes away if this call is deleted  */
  }

__declspec(dllexport)
void
foo(void)  /* test.c:3:28: error: redeclaration of 'foo' cannot add 'dllexport' attribute */
  {
  }

E:\lh_mouse\Desktop>clang --version
clang version 14.0.0
Target: x86_64-w64-windows-gnu
Thread model: posix
InstalledDir: C:/MSYS2/clang64/bin

[MaskRay]

This is similar to
https://maskray.me/blog/2021-10-10-when-can-glibc-be-built-with-clang#asm-label-after-first-use

IIRC due to the Clang code gen architecture it is very difficult to emulate GCC behavior.

[lhmouse]

Note it is suggested that dllimport should not be used at all. When building a DLL, function definitions can be marked dllexport as needed, which should not conflict with undecorated declarations. This approach enables the same function declarations (in headers) to be shared between static and shared libraries.

If Clang does not work this way, it is suddenly mandatory to mark function declarations in headers with some nastily complex macros, which also requires a project-specific macro that is invisible to users, as it is not enough to check for just DLL_EXPORT; when a user is building their own DLL, they should never see dllexport from another library.

[mstorsjo]

Yes, I think this error is kinda overzealous - adding a dllimport after first being declared without it would be an issue, but adding dllexport later should, in principle, not be a problem. The problem is just with Clang and LLVM code generation - which might not be entirely straightforward to fix. As far as I understand the issue, in the example case, the function foo doesn't get a declaration in LLVM IR until it's either called or defined, and once declared in the LLVM IR, we can't add the attribute afterwards.

So to fix this, the code generation would need to go back and adjust the already-emitted declaration of foo to add the dllexport attribute (on the IR level). Going back and changing attributes for already-emitted IR declarations generally probably isn't supported much (because it's generally not correct to do so), but in the case of a late addition of dllexport, it could be ok.

[mstorsjo]

@rnk @zmodem (If you happen to have time) - I presume you have more experience with the Clang codegen than me... What would it take to fix the late-addition of dllexport in this case?

[zmodem]

The problem is indeed that going back and changing a symbol after it's already been emitted to LLVM IR isn't something Clang codegen normally does. It may of course be possible to do in theory, but I worry that it might be tricky to get completely right.

Since it would be a break with Clang's codegen architecture, I don't think we should try to do this without good motivation, such as widely used system headers relying on it. In general, well-behaved code should be consistent in how it declares its symbols.

[lhmouse]

Since it would be a break with Clang's codegen architecture, I don't think we should try to do this without good motivation, such as widely used system headers relying on it. In general, well-behaved code should be consistent in how it declares its symbols.

How do you define 'consistent'? Suppose:

fahr.h

inline double fahr(double t)  // C99 inline definition
{
  return (9.0 * t) / 5.0 + 32.0;
}

fahr.c

#include "fahr.h"

extern double fahr(double); // creates an external definition

This is formally specified by the C99 standard (see 6.7.4 Function specifiers, WG14 N1256), and how do you expect it to be 'consistent'? The two declarations can never match each other.

[zmodem]

I mean consistent about being dllimport/export/regular.

[rnk]

Perhaps upgrading to dllexport is reasonably safe, it just takes extra work, and we didn't think that work was necessary because MSVC rejects this example. GCC compatibility, historically, was not our goal and was improved later.

Clang does have this same problem for C99 inline function definitions, and I seem to recall that it requires a special codepath to go back and upgrade weak inline function definitions into strong definitions. I don't think there are any risks to adding a similar codepath for dllexport, it just doesn't exist yet, and from a general engineering design sense, less code is better.

Note that going the other direction, adding dllimport to a previous declaration, would be much riskier, since it can make the address of a symbol non-constexpr. I am aware of weird cases where clang will revise dllimport functions to dllexport functions, but again, that's moving from weaker linkages to stronger linkages.

[zmodem]

@lhmouse can you elaborate on your use case for this? Is there some project that relies on GCC's behavior?

[lhmouse]

The example was reduced from here: https://github.com/lhmouse/mcfgthread/blob/61211f574fd65ffb8b056d697539b5734248e536/src/mutex.c#L37

Previous I used -export-all-symbols, with --exclude-symbols to exclude the custom entry point, so there was no dllexport, and hence no mismatching declaration, either. Clang does not support --exclude-symbols however, and removal of it would export the entry point function undesirably. So I removed --export-all-symbols and decided to mark public functions with dllexport when building the DLL.

[mstorsjo]

Previous I used -export-all-symbols, with --exclude-symbols to exclude the custom entry point, so there was no dllexport, and hence no mismatching declaration, either. Clang does not support --exclude-symbols however, and removal of it would export the entry point function undesirably.

I presume that would be LLD not supporting --exclude-symbols (you could be using Clang with ld.bfd too, where it'd work, or GCC with LLD). Implementing that should be fairly straightforward (I just never bothered as I hadn't run into any use of it in the wild back when I initially added support for exporting all symbols in LLD). Although that doesn't change the fact that it would be nice if dllexport could be added later too.