[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ros-dev
Subject:    Re: [ros-dev] videoprt.nostrip.sys
From:       Hartmut Birr <hartmut.birr () gmx ! de>
Date:       2005-01-27 0:28:04
Message-ID: 41F83594.6050600 () gmx ! de
[Download RAW message or body]

Ge van Geldorp schrieb:

>It seems videoprt.nostrip.sys is somewhat messed up. I've attached the
>output of "objdump -p videoprt.nostrip.sys". Data Directory Entry 1 says
>there's an import directory at 0x0000b000. Then down under "PE File Base
>Relocations (interpreted .reloc section contents)" we find:
>
>Virtual Address: 0000b000 Chunk size 12 (0xc) Number of fixups 2
>	reloc    0 offset   14 [b014] HIGHLOW
>	reloc    1 offset   20 [b020] HIGHLOW
>
>When the module is loaded, the relocations are applied. This messes up the
>import table, with the result that the module fails to load (copy
>videoprt.nostrip.sys to \reactos\system32\drivers\videoprt.sys and boot
>ReactOS). The 2 relocations given above are not present in the "normal"
>videoprt.sys module.
>
>I'm inclined to blame gcc (I'm using 3.4.1) or more likely binutils (2.15.90
>20040222) for this, but before I make Filip unhappy, does anyone know if
>we're doing something wrong during the build process?
>
>Gé van Geldorp.
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Ros-dev mailing list
>Ros-dev@reactos.com
>http://reactos.com:8080/mailman/listinfo/ros-dev
>
Hi,

there was somewhere a description how a dll is build with mingw. The 
link process must run three rounds through dlltool/ld. I'm not sure if 
this helps. I've found some problems which are similar to the import 
table problem. Sometimes the relocation table contains entries for 
itself. Some time ago I've add a check for this. Scsiport.sys was my 
candidate.

- Hartmut


[prev in list] [next in list] [prev in thread] [next in thread]