Re: narwhal and PGDLLIMPORT

On 02/05/2014 01:52 PM, Tom Lane wrote:
> Craig Ringer <craig(at)2ndquadrant(dot)com> writes:
>> On 02/05/2014 06:29 AM, Tom Lane wrote:
>>> I had been okay with the manual PGDLLIMPORT-sprinkling approach
>>> (not happy with it, of course, but prepared to tolerate it) as long
>>> as I believed the buildfarm would reliably tell us of the need for
>>> it. That assumption has now been conclusively disproven, though.
>
>> I'm kind of horrified that the dynamic linker doesn't throw its toys
>> when it sees this.
>
> Indeed :-(.
>
> The truly strange part of this is that it seems that the one Windows
> buildfarm member that's telling the truth (or most nearly so, anyway)
> is narwhal, which appears to have the oldest and cruftiest toolchain
> of the lot. I'd really like to come out the other end of this
> investigation with a clear understanding of why the newer toolchains
> are failing to report a link problem, and yet not building working
> executables.

I've done some digging and asked for some input from people with
appropriate knowledge. Getting a hard answer's going to require some
quality time with a debugger that I won't have until after the CF.
Here's what I've found so far:

In a .DEF file, symbol exports default to code exports if unspecified.

http://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx

(I'm told that .DEF files take precedence over annotations in code, but
haven't found a reference to confirm that yet, and I'm not convinced
it's true since data annotated correctly with __declspec(dllexport)
seems to work. You'd think places like this would mention it, but they
don't: http://msdn.microsoft.com/en-us/library/7k30y2k5.aspx)

So we're probably generating code thunk functions for our global
variables in the import library.

There seem to be two possibilities for what's happening when you access
an extern variable defined in another module without __declspec(dllimport):

1. Our extern variable points to a thunk function's definition; or

2. Our extern variable points to the indirected pointer to the real
variable, which is what you get if you link to a CONSTANT export without
using __declspec(dllimport).

I'd need to go poking in disassemblies with the debugger to confirm
which it is, and don't have time right now. After the CF, maybe. I
suspect #1, since we're probably generating thunk functions for our data
exports.

Either way, the key thing is:

http://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx

"Note that when you export a variable from a DLL with a .def file, you
do not need to specify __declspec(dllexport) on the variable. However,
in any file that uses the DLL, you must still use __declspec(dllimport)
on the declaration of data."

See also "rules and limitations for dllimport/dllexport":

http://msdn.microsoft.com/en-us/library/da6zd0a4.aspx

This page notes that you should annotate .DEF entries for data with DATA
"to reduce the likelihood that incorrect coding will cause a problem".

http://msdn.microsoft.com/en-us/library/54xsd65y.aspx

That will prevent generation of the linker symbol that's a pointer to
the real data, so we should get linker errors when we fail to specify
__declspec(dllimport).

To do this, src/tools/msvc/gendefs.pl needs to be modified to correctly
annotate globals with DATA based on the dumpbin output. I'll have a
crack at that after the CF is closed.

However, *this modification will not get rid of the need for PGDLLIMPORT
macros in headers*, because it's still necessary to explicitly tag them
with __declspec(dllimport) for correct results.

In fact, I'm now wondering if we're using inefficient thunk based
function calls from modules because we're not specifying
__declspec(dllimport) on external functions, too. Again, that's a
post-CF thing to check out using the MSVC debugger.

BTW, there's a general reference for __declspec(dllexport) here:

http://msdn.microsoft.com/en-us/library/a90k134d.aspx

and higher level concepts here:

http://msdn.microsoft.com/en-us/library/z4zxe9k8.aspx
http://msdn.microsoft.com/en-us/library/900axts6.aspx

Other references:

http://msdn.microsoft.com/en-us/library/da6zd0a4.aspx
http://msdn.microsoft.com/en-us/library/zw3za17w.aspx
http://msdn.microsoft.com/en-us/library/619w14ds.aspx
http://msdn.microsoft.com/en-us/library/54xsd65y.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2006/07/20/672695.aspx
http://blogs.msdn.com/b/oldnewthing/archive/2006/07/18/669668.aspx

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services