Hi folks,
I recently tried to do the free build of my drivers (as opposed to the
checked build, which I’ve been doing up until now), and got a rather
nasty linker error:
error LNK2019: unresolved external symbol __aulldvrm
referenced in function
From my searches of Google and OSR online, I’ve ascertained that:
- Looks like the unresolved is a library function invoked by the
compiler to do 64 bit arithmetic, specifically a 64 bit divide, which is
consistent with my function.
- Apparently some DirectX programmers have this issue occasionally (to
do with pre-built lib files).
- There don’t appear to be any previous reports of this issue for kernel
code.
I went a bit further, and looked at the difference between checked and
free builds, and as a guess, the change in compiler optimization flags
may be giving me this issue. Specifically, the checked build includes:
“/Oi replaces some function calls with intrinsic or otherwise special
forms of the function that help your application run faster. Programs
that use intrinsic functions are faster because they do not have the
overhead of function calls, but may be larger because of the additional
code created.”
So I suspect in the checked build, an inline or intrinsic is being
generated, and in the free build it’s trying to find the library code.
However, I can’t see how to fix this - unsigned int64 operations are
sufficiently common that they should “just work” - and I’ve checked I
haven’t changed any of the ddk environment setup or header files.
Have I missed something?
MH.
This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.
Peter Viscarola wrote:
Did you try building your free build with /Oi?
Add USER_C_DEFINES=/Oi to your sources file and see if it works.
I’m not saying that’s necessarily the long-term solution.
I’m just saying that’s a way to at least SEE if this is the problem.
Ahhh… Tried that, no luck. Sorry to lead you folks up the garden
path.
You’re not, by any chance, building outside the DDK’s normal build
environment are you? You’re using the DDK distributed compiler,
linker, and build utility??
Yes, I am. Having said that, we do include some header files which are
shared between the driver build and the embedded software running on a
DSP on our PCI card … So those are next in the line of
investigation…
MH.
This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.
>Add USER_C_DEFINES=/Oi to your sources file and see if it works.
After a bit more hunting, I have figured out which code snippets give
the problem. It seems not to like this macro in “ks.h”:
#define NANOSECONDS 10000000
#define KSCONVERT_PERFORMANCE_TIME(Frequency, PerformanceTime) \
((((ULONGLONG)(ULONG)(PerformanceTime).HighPart * NANOSECONDS /
(Frequency)) << 32) + \
((((((ULONGLONG)(ULONG)(PerformanceTime).HighPart * NANOSECONDS) %
(Frequency)) << 32) + \
((ULONGLONG)(PerformanceTime).LowPart * NANOSECONDS)) /
(Frequency)))
So it looks like the 64 bit “%” operator is the thing that’s giving the
traumas, since all the other 64 bit operations (multiply, divide by
constant, shift) occur in the drivers anyway.
MH.
This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.
Are you building for Windows 2000 using the 3790 DDK? If so then this is a
DDK bug – the problem is caused by the fact that the new compiler in the
3790 DDK generates intrinsics with different names from the Windows 2000 DDK
compiler BUT the Windows 2000 int64 library in the 3790 DDK still has the
old routine (which is __aulldiv btw).
Fix is to add the wnet int64.lib to your link - dont quite recall the
syntax, but it’s something like
lib\wnet*\int64.lib
Simon
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Monday, February 21, 2005 12:57 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Problem building “free build” of my drivers.
Martin C Harvey wrote:
Hi folks,
I recently tried to do the free build of my drivers (as opposed to the
checked build, which I’ve been doing up until now), and got a rather nasty
linker error:
error LNK2019: unresolved external symbol aulldvrm
referenced in function
How are you doing your builds? Are you using the command-line “build” tool,
or are you inside Visual Studio? Are you included 3rd party libraries, or
your own libraries built elsewhere?
auldvrm is supplied in wdm.lib, ntdll.lib, libcntpr.lib, and int64.lib.
I’m not sure how you could concoct a driver build that didn’t include at
least one of those.
–
- Tim Roberts, xxxxx@probo.com mailto:xxxxx
Providenza & Boekelheide, Inc.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com</mailto:xxxxx>
Martin C Harvey wrote:
>Add USER_C_DEFINES=/Oi to your sources file and see if it works.
>
>
After a bit more hunting, I have figured out which code snippets give
the problem. It seems not to like this macro in “ks.h”:
#define NANOSECONDS 10000000
#define KSCONVERT_PERFORMANCE_TIME(Frequency, PerformanceTime) \
((((ULONGLONG)(ULONG)(PerformanceTime).HighPart * NANOSECONDS /
(Frequency)) << 32) + \
((((((ULONGLONG)(ULONG)(PerformanceTime).HighPart * NANOSECONDS) %
(Frequency)) << 32) + \
((ULONGLONG)(PerformanceTime).LowPart * NANOSECONDS)) /
(Frequency)))
So it looks like the 64 bit “%” operator is the thing that’s giving the
traumas, since all the other 64 bit operations (multiply, divide by
constant, shift) occur in the drivers anyway.
Absolutely. Divide by itself uses __aulldiv. Remainder by itself uses
__aullrem. Without optimizations, this macro uses those calls.
However, with optimizations turned on, the compiler can see that you
are doing both operations at once, and calls __aulldvrm to return both
values.
However, all three of those are present in the appropriate libraries.
The only way this error should happen is if you try to use a newer
compiler with a set of older libraries. That’s why I asked about your
specific build environment.
–
How are you doing your builds? Are you using the command-line “build”
tool, or are you inside Visual Studio? Are you included 3rd party
libraries, or your own libraries built elsewhere?
I’m using the command line build tool
I am including kernel libraries that are built elsewhere, however, I’ve
seen the error on a driver that contains the offending macro *directly*
.
I’m using the command line build tool, and all libraries included are
built via the same tool.
__auldvrm is supplied in wdm.lib, ntdll.lib, libcntpr.lib, and
int64.lib. I’m not sure how you could concoct a driver build that
didn’t include at least one of those.
__auldvrm may well be included, but the error is __aulldvrm which is the
64 bit version I assume - two l’s.
MH.
This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.
Graham, Simon wrote:
Are you building for Windows 2000 using the 3790 DDK? If so then this is
a DDK bug – the problem is caused by the fact that the new compiler in
the 3790 DDK generates intrinsics with different names from the Windows
2000 DDK compiler BUT the Windows 2000 int64 library in the 3790 DDK
still has the old routine (which is __aulldiv btw).
Fix is to add the wnet int64.lib to your link - dont quite recall the
syntax, but it’s something like
lib\wnet*\int64.lib
Simon… This is a KNOWN DDK bug? Been reported and stuff?
I don’t recall seeing it (not that I know every DDK bug in the universe),
Peter
OSR
Yes it’s known - I originally reported it on the 3718 DDK; not sure if an
“official” bug was ever created for it but it was still in 3790; I kind of
lost interest personally at that point since we switched to building for
W2K3 only…
Simon
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Peter Viscarola (OSR)
Sent: Monday, February 21, 2005 2:19 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Problem building “free build” of my drivers.
Graham, Simon wrote:
Are you building for Windows 2000 using the 3790 DDK? If so then this is
a DDK bug – the problem is caused by the fact that the new compiler in
the 3790 DDK generates intrinsics with different names from the Windows
2000 DDK compiler BUT the Windows 2000 int64 library in the 3790 DDK
still has the old routine (which is __aulldiv btw).
Fix is to add the wnet int64.lib to your link - dont quite recall the
syntax, but it’s something like
lib\wnet*\int64.lib
Simon… This is a KNOWN DDK bug? Been reported and stuff?
I don’t recall seeing it (not that I know every DDK bug in the universe),
Peter
OSR
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Martin C Harvey wrote:
How are you doing your builds? Are you using the command-line “build”
tool, or are you inside Visual Studio? Are you included 3rd party
libraries, or your own libraries built elsewhere?
I’m using the command line build tool
I am including kernel libraries that are built elsewhere, however,
I’ve seen the error on a driver that contains the offending macro
*directly* .
The macro is irrelevant. The problem happens because the libraries
don’t match what the compiler expects to find. If you use the new
compiler with old libraries, you will be screwed.
I’m using the command line build tool, and all libraries included are
built via the same tool.
What about the stock libraries, which I mention below? Are they from
the same drop of the DDK?
__auldvrm is supplied in wdm.lib, ntdll.lib, libcntpr.lib, and
int64.lib. I’m not sure how you could concoct a driver build that
didn’t include at least one of those.
__auldvrm may well be included, but the error is __aulldvrm which is
the 64 bit version I assume - two l’s.
My typo. __aulldvrm is the one I meant, and is present in the libraries
I mentioned.
–
Thanks Simon, that’s a spot on diagnosis! Yes, I’m building for Win2k
using 3790. I added this line to the “TARGETLIBS” statement in the
sources files for the various drivers:
$(BASEDIR)\lib\wnet*\int64.lib
and it now builds like a charm.
Many thanks also to Tim Roberts, who could clearly see the problem and
was pointing me in just the right direction.
MH.
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Graham, Simon
Sent: 21 February 2005 18:34
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Problem building “free build” of my drivers.
Are you building for Windows 2000 using the 3790 DDK? If so then this is
a DDK bug – the problem is caused by the fact that the new compiler in
the 3790 DDK generates intrinsics with different names from the Windows
2000 DDK compiler BUT the Windows 2000 int64 library in the 3790 DDK
still has the old routine (which is __aulldiv btw).
Fix is to add the wnet int64.lib to your link - dont quite recall the
syntax, but it’s something like
lib\wnet*\int64.lib
Simon
This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.
> Simon… This is a KNOWN DDK bug? Been reported and stuff?
Just built the project which contains ULONGLONGs and ariths with them via w2k
build env of 3790. All was fine.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Hmm… Did you build retail or checked? The checked build generates calls to
__aulldiv and __aullrem when you use ‘/’ and ‘%’ whereas the free build
generates calls to __aulldvrm - presumably an optimization added in the W2K3
DDK compiler???
/simgr
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Thursday, February 24, 2005 8:49 PM
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Problem building “free build” of my drivers.
Simon… This is a KNOWN DDK bug? Been reported and stuff?
Just built the project which contains ULONGLONGs and ariths with them via
w2k
build env of 3790. All was fine.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@stratus.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
OK, but if Simon is right, you’ll need to:
A) Build the free build.
B) Include code where (A/B) and (A%B) occur in sufficient proximity,
and A and B are not changed such that the compiler can optimise the two
into a single divide operation, which (I assume) is the whole point of
__aulldvrm
I found that I could free build an awful lot of code with int64’s in
before coming across that particular issue.
In addition, I’d suggest not making B constant, and definitely not a
constant power of 2, otherwise the compiler might well do something else
entirely…
MH.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: 25 February 2005 01:49
To: Windows System Software Devs Interest List
Subject: Re: Re:[ntdev] Problem building “free build” of my drivers.
Simon… This is a KNOWN DDK bug? Been reported and stuff?
Just built the project which contains ULONGLONGs and ariths with them
via w2k build env of 3790. All was fine.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@snellwilcox.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
This email and any attachments is confidential, may be legally privileged and is intended for the use of the addressee only. If you are not the intended recipient, please note that any use, disclosure, printing or copying of this email is strictly prohibited and may be unlawful. If received in error, please delete this email and any attachments and confirm this to the sender.
Martin C Harvey wrote:
OK, but if Simon is right, you’ll need to:
A) Build the free build.
B) Include code where (A/B) and (A%B) occur in sufficient proximity,
and A and B are not changed such that the compiler can optimise the two
into a single divide operation, which (I assume) is the whole point of
__aulldvrm
I found that I could free build an awful lot of code with int64’s in
before coming across that particular issue.
In addition, I’d suggest not making B constant, and definitely not a
constant power of 2, otherwise the compiler might well do something else
entirely…
We’re spending an awful lot of time on this issue. No more analysis is
really necessary. This is a build problem: using libraries built with a
different version of the compiler from the rest of the code. Use the
right libraries, and the problem does not exist.
–