Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

building drivers for 64 bit kernels

2009-01-27
2013-06-06
1 2 > >> (Page 1 of 2)
  • Brian Hawley
    Brian Hawley
    2009-01-27

    We have been building 32 bit drivers using mingw32 in a msys environment.  We recently downloaded and installed a snapshot build mingw-w64-bin_i686-mingw_20090121.  And other than a header pathing issue, and a couple other minor hiccups, things seemed to be ok.

    However, when we go to link our final output we have a problem.

    Our problem now is that there does not appear to be a 64 bit version of ntoskrnl (or a 32 bit in this package).  I looked in our install tree (/home/engr/tools/generic-i386-winxp64 -- which happens to be a networked drive under mingw) in mingw/lib64.  I'm making an assumption that this library is automatically listed in the paths to be searched for libraries.  I do see a lib64/libhal.a.

    Any help is appreciated.

    Here is the output.  gcc is actually a shell which invokes bin/x86_64-pc-mingw32-gcc.exe when it sees the -m64 flag.

    gcc -shared    -L/home/engr/tmp/bhawley/generic-i386-winxp/LicenseMgr/1.8.0.13/lib  -L/home/engr/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib  -L/home/engr/support/generic-i386-winxp/LicenseMgr/1.8.0.13/lib  -L/home/engr/support/generic-i386-winxp/Libraries/2.2.0.0/lib  -L/home/engr/support/generic-i386-winxp/w32compat/pthread/lib  -m64 -shared -Wl,--entry,_DriverEntry@8 -nostartfiles -nostdlib -static-libgcc  /home/engr/tmp/bhawley/generic-i386-winxp/LicenseMgr/1.8.0.13/llmdrv/generic-i386-winxp-entry.o_K64 /home/engr/tmp/bhawley/generic-i386-winxp/LicenseMgr/1.8.0.13/llmdrv/llmdrv.o_K64 /home/engr/tmp/bhawley/generic-i386-winxp/LicenseMgr/1.8.0.13/llmdrv/version.o_K64 -o /home/engr/tmp/bhawley/generic-i386-winxp/LicenseMgr/1.8.0.13/drv/llmdrv_K64.sys -lLicenseMgr_K64 -lbase_K64 -lntoskrnl -lhal -lgcc
    using 64bit compiler
    v:/tools/generic-i386-winxp64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/bin/ld.exe: cannot find -lntoskrnl
    collect2: ld returned 1 exit status

     
    • Brian Hawley
      Brian Hawley
      2009-01-27

      We had since added a -L/home/engr/tools/generic-i386-winxp64/mingw/lib  to the flags.  However, since no library was there, it still could not be found.

      When we copied the libntoskrnl.a from the mingw win32 project, it found the library but gave us lots of undefined symbols such as:

      e:\projects\current\bhawley_Base_Libraries\libraries\base/HashTable.c:945: undefined reference to `_imp__ExAllocatePoolWithTag'

      I'm not surprised, I guess, since I wouldn't expect the 32 bit libraries to work with a 64 bit build. 

      Curiously, running ranlib on the library file

      bhawley@IRRATIONAL /home/engr/tools/generic-i386-winxp64/mingw/lib64
      ../../bin/x86_64-pc-mingw32-ranlib.exe libntoskrnl.a

      now makes ld complain that there is no index and that ranlib needs to be run.

      v:/tools/generic-i386-winxp64/mingw/lib64/libntoskrnl.a: could not read symbols: Archive has no index; run ranlib to add one

       
    • Kai Tietz
      Kai Tietz
      2009-01-28

      Well, at the moment we don't have the DDK package include for 32-bit and not for 64-bit.
      But if you need for 32-bit (and/or 64-bit) an import library you can use the gendef tool (to be found in our experimental tree) to generate the corresponding .def files. By them you can generate those import-libraries.

      Cheers,
      Kai

      PS: If you have working .def files, please let us know.

       
    • Brian Hawley
      Brian Hawley
      2009-01-28

      Thanks Kai.

      I'm very much a novice when it comes to the windows builds (hence my reason for using msys and mingw).

      What I have is whatever comes in the mingw32 package and the packages you have available.  The 32 bit libraries were already present in the mingw32 project although one of them did need to be tweaked for the correct signature.

      I also have a hal.def and ntoskrnl.def which either came with the mingw32 package or which I came across subsequently because of the aforementioned glitch in the 32 bit libraries that had to be fixed.

      Are you saying that with the ntoskrnl.def I can generate a 64 bit .a that can be used for linking 64 bit binaries?

      If so, please tell this novice how to go about it.

      Thanks.

       
      • NightStrike
        NightStrike
        2009-01-29

        You have to run the gendef tool against the 64-bit library to generate a 64-bit def file.  From that, you can easily generate the 64-bit .a file, and we'll gladly accept your generated .def file into our repository so that we can provide .a files for it in future releases.

         
    • Brian Hawley
      Brian Hawley
      2009-01-29

      Please keep in mind I know nothing of the gendef, and very little of the import/export windows stuff, def files, dlls, etc.  I'm a unix guy and work with .a's and .so's.

      Are you saying to run gendef against the 64 bit libraries in the Windows DDK?

      Can you provide an example, or point me to a documentation for gendef?

      All I have are the .def files along with the 32 bit libraries, the contents of which look something like:

      LIBRARY ntoskrnl.exe
      EXPORTS
      ;CcCanIWrite
      ;CcCopyRead
      ;CcCopyWrite
      ;CcDeferWrite
      ;CcFastCopyRead
      ;CcFastCopyWrite
      ;CcFastMdlReadWait
      ;CcFastReadNotPossible
      ;CcFastReadWait
      ;CcFlushCache
      ;CcGetDirtyPages
      ;CcGetFileObjectFromBcb
      ;CcGetFileObjectFromSectionPtrs
      ;CcGetFlushedValidData
      ;CcGetLsnForFileObject
      ;CcInitializeCacheMap
      ;CcIsThereDirtyData
      ;CcMapData
      ;CcMdlRead
      ;CcMdlReadComplete
      ;CcMdlWriteAbort
      ;CcMdlWriteComplete

       
      • Kai Tietz
        Kai Tietz
        2009-01-29

        Hello

        I added the file ntoskrnl.def to our 64-bit libraries. So when we have added it to our makefile, it will be available.

        Best regards,
        Kai

         
        • NightStrike
          NightStrike
          2009-01-29

          Done.

           
          • Brian Hawley
            Brian Hawley
            2009-02-11

            The Feb 08 build has the ntoskrnl.def file in the ../lib/  directory.  So, I ran

            ../../bin/x86_64-pc-mingw32-dlltool.exe --def ntoskrnl.def --output-lib libntoskrnl.a

            and put it in the lib64 directory.  I'm assuming that was the correct thing to do, since I think this was a multi-lib build and the lib directory contains the 32 bit binaries.  However, I still have to explicitly add the lib64 path to the -L options.  Am I missing something here?

            $ x86_64-pc-mingw32-gcc -print-search-dirs
            install: v:\tools\generic-i386-winxp64\bin\../lib/gcc/x86_64-pc-mingw32/4.4.0/
            programs: =v:/tools/generic-i386-winxp64/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/;v:/tools/generic-i386-winxp64/bin/../libexec/gcc/;v:/tools/generic-i386-winxp64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/bin/x86_64-pc-mingw32/4.4.0/;v:/tools/generic-i386-winxp64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/bin/
            libraries: =v:/tools/generic-i386-winxp64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/;v:/tools/generic-i386-winxp64/bin/../lib/gcc/;v:/tools/generic-i386-winxp64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib/x86_64-pc-mingw32/4.4.0/;v:/tools/generic-i386-winxp64/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib/;c:/buildbot/vista64-mingw32/mingw-x86/build/root/mingw/lib64/x86_64-pc-mingw32/4.4.0/;c:/buildbot/vista64-mingw32/mingw-x86/build/root/mingw/lib64/

             
    • Brian Hawley
      Brian Hawley
      2009-01-29

      Thanks Kai. 

      I appreciate the efforts.  I apologize for being so naive and unhelpful. 

      How can I tell when it is available?

      On a related but different note, could you or nitestrike contact me 'off-forum' for how I might be able to contribute to/support your efforts.

      Thanks,

      -- Brian

       
      • NightStrike
        NightStrike
        2009-01-29

        Take any automated build starting tomorrow or the next day.  It'll get picked up with the daily builds.

         
    • Brian Hawley
      Brian Hawley
      2009-02-11

      We still have some undefined symbols.  While the ntoskrnl.def contains a variety of spinlock functions:

      KeAcquireSpinLockAtDpcLevel
      KeAcquireSpinLockForDpc
      KeAcquireSpinLockRaiseToDpc
      KeAcquireSpinLockRaiseToSynch

      The following are no where to be found.

      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x1129): undefined reference to `_imp__KeAcquireSpinLock'
      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x11d8): undefined reference to `_imp__KeAcquireSpinLock'
      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x135b): undefined reference to `_imp__KeQuerySystemTime'
      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x1417): undefined reference to `_imp__KeInitializeSpinLock'
      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.0/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x14e5): undefined reference to `_imp__KeAcquireSpinLock'

      Looking at my 32 bit def files:

      $ fgrep KeAcquireSpinLock *.def
      hal.def:KeAcquireSpinLock@8
      hal.def:;KeAcquireSpinLockRaiseToSynch
      ntoskrnl.def:;KeAcquireSpinLockAtDpcLevel

      Makes me think that perhaps of some these should be getting picked up from libhal.a. 

      For what its worth here are the others and where they are defined:

      $ fgrep KeQuerySystemTime *.def
      ntoskrnl.def:KeQuerySystemTime@4

      $ fgrep KeInitializeSpinLock *.def
      ntoskrnl.def:KeInitializeSpinLock@4

       
      • Kai Tietz
        Kai Tietz
        2009-02-11

        Well, it seems that for 64-bit the API it doesn't exist anymore. I can't find e.g the export of KeQuerySystemTime for 64-bit

        Sadly I have no further documentation about this

        Cheers,
        Kai

         
        • Brian Hawley
          Brian Hawley
          2009-02-11

          I looked at the latest online DDK reference, and KeQuerySystemTime is not there...however, the KeAcquireSpinLock, and KeInitializeSpinLock are present.

          It is relatively easy for me to do something other than SystemTime, but I can't easily substitute something for a spin lock.

           
          • Brian Hawley
            Brian Hawley
            2009-02-11

            This online reference for the current DDK has KeQuerySystemTime, I just didn't see it the first time I looked.   But maybe there is a different DDK that isn't readily obvious to me that you are referring to that does not contain it.

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

             
            • Brian Hawley
              Brian Hawley
              2009-02-11

              This subsection discussing 64bit issues in the DDK does not indicate that functions listed earlier in the reference guide are not available in 64 bit mode.

              Perhaps those macro's were simply ReactOS's way of implementing the windows ddk so existing code would compile.

               
              • Kai Tietz
                Kai Tietz
                2009-02-14

                Could be that this is ReactOS specific, but I have about this doubts. It seems so, that at least on XP64 (and Vista64) those exports aren't present in ntoskrnl, nor in hal. But I try to clarify this.

                Another question I have. How are you signing your 64-bit driver? AFAIK are XP64 and for sure Vista64 needing signed drivers, otherwise it rejects to use them, or do I misunderstood here something?

                Cheers,
                Kai

                 
                • Brian Hawley
                  Brian Hawley
                  2009-02-17

                  I have some people checking into the signing.

                  But I'm completely dumbfounded that KeInitializeSpinLock and KeAcquireSpinLock would be removed from the API, but KeReleaseSpinLock would still be present...

                  Perhaps there is a header in win64 that changes KeInitializeSpinLock to something else, but I haven't found it in the windows ddk include files.

                   
                  • Brian Hawley
                    Brian Hawley
                    2009-02-20

                    Signing is needed for windows 2008.  But not for windows XP.

                    I'm willing to do whatever I can to help.

                    The 6001 DDK and documentation does not indicate support for these being removed, nor do the header files have any special macros for 64 bit in the case of the spinlock routines.

                    What am I not finding that you are, and what can I do to help.

                     
                    • Kai Tietz
                      Kai Tietz
                      2009-02-20

                      The KeInitializeSpinLock is a method just present as inline

                      try the following implementation

                      FORCEINLINE
                      VOID
                      NTAPI
                      KeInitializeSpinLock(
                        PKSPIN_LOCK SpinLock)
                      {
                          *SpinLock = 0;
                      }

                      it should work

                      Cheers,
                      Kai

                       
                      • Brian Hawley
                        Brian Hawley
                        2009-02-20

                        I will look at adding that to the ddk header files under a _MINGW64_ ifdef (I think thats the correct one).

                        But what about KeAcquireSpinLock?

                        I'm still puzzled why KeReleaseSpinLock would be in the DDK but Acquire would not.

                         
                        • Kai Tietz
                          Kai Tietz
                          2009-02-20

                          Well, KeAcquireSpinLock should be something like this:

                          #define KeAcquireSpinLock(SpinLock, OldIrql) \   *(OldIrql) = KeAcquireSpinLockRaiseToDpc(SpinLock)

                          I read the parts in ddk documentations now too. And there seems to be no hint that those methods are deprecated, but this means not that there must be such a export in ntoskernl, hal, ...
                          A define is possible, too. In fact is pretty often common in msdn documentation, that the describe the macro alias, but not the real method name. E.g. for Ascii and Unicode versions of functions, The talk about CreateFile, but not that the physical method behind are CreateFileA and CreateFileW. So I think that the headers from ReactOS are reasonable.

                          Cheers,
                          Kai

                           
                          • Brian Hawley
                            Brian Hawley
                            2009-02-20

                            Thanks.

                            Yes, I quite agree.  Many of the Ex.... are #defined to the Ke variants.

                            With more digging in different DDK's have found some #defines for some architecture variants, which cover these.  I should have seen them in the first place, but was working under a different set of assumptions for what was defined by the compiler (i.e. IA64, etc).

                            Is _MINGW64_ the proper ifdef under which to bring these macros into the mingw header file(s)?

                            Thanks for your help.

                             
                            • Kai Tietz
                              Kai Tietz
                              2009-02-21

                              The proper macro to be used for architecture stuff is __x86_64__. The __MINGW64__ is defined by gcc by targeting w64, so it would be fine at the moment, too. If there will be IA64, then it would be false, because it would be also __MINGW64__ but the architecture define would be __ia64__ IIRC

                              Cheers,
                              Kai

                               
                              • Brian Hawley
                                Brian Hawley
                                2009-03-04

                                Just to close the loop and leave something usable for anyone following this thread in the future...here is what I got to work.  It would probably be better in the w32api ntddk.h (and hence the undefs would not be needed) but I don't know if they want it.

                                #if defined(__x86_64__)
                                // the w32api does not have the #defines to reflect the changes in wdm
                                // for 64 bit...specifically the following appear to have become
                                // #defines in the wdm.h

                                #define KeInitializeSpinLock(SpinLock) *SpinLock = 0
                                #define KeAcquireSpinLock(SpinLock, OldIrql) \   *(OldIrql) = KeAcquireSpinLockRaiseToDpc(SpinLock)

                                #undef KI_USER_SHARED_DATA
                                #define KI_USER_SHARED_DATA 0xFFFFF78000000000ULL

                                #undef SharedUserData
                                #define SharedUserData ((KUSER_SHARED_DATA * const)KI_USER_SHARED_DATA)

                                #define SharedInterruptTime (KI_USER_SHARED_DATA + 0x8)
                                #define SharedSystemTime (KI_USER_SHARED_DATA + 0x14)
                                #define SharedTickCount (KI_USER_SHARED_DATA + 0x320)

                                #define KeQueryInterruptTime() *((volatile ULONG64 *)(SharedInterruptTime))

                                #define KeQuerySystemTime(CurrentCount)                                     \     *((PULONG64)(CurrentCount)) = *((volatile ULONG64 *)(SharedSystemTime))

                                #define KeQueryTickCount(CurrentCount)                                      \     *((PULONG64)(CurrentCount)) = *((volatile ULONG64 *)(SharedTickCount))

                                #endif // AMD64

                                 
1 2 > >> (Page 1 of 2)