This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Need help figuring out DLL load problem


Danny Backx wrote:
> On Wed, 2009-08-05 at 21:53 +0200, Danny Backx wrote:

>> I have trouble figuring out what's causing this, or where this field
>> (the BSF_FUNCTION ?) is set. Any bright ideas ?

> pavilion: {503} make
> i386-mingw32ce-g++ -c demodll.C
> i386-mingw32ce-ar crv libx.a demodll.o
> a - demodll.o
> i386-mingw32ce-ranlib libx.a
> i386-mingw32ce-dlltool --output-def libx.def --export-all libx.a

> pavilion: {505} cat *def
> ; i386-mingw32ce-dlltool --output-def libx.def --export-all libx.a
> EXPORTS
> ;       cpp()
>         _Z3cppv @ 1 DATA
> ;       DllMain(void*, unsigned long, void*)
>         _Z7DllMainPvmS_ @ 2 DATA
>         doit @ 3 DATA

  So, what's up with these symbols?

> $ objdump -t demodll.o  | grep 'cpp\|doit\|DllMain'
> [  4](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x0000007c __GLOBAL__I__Z3cppv
> [  5](sec  1)(fl 0x00)(ty   0)(scl   6) (nx 0) 0x00000098 __GLOBAL__D__Z3cppv
> [ 18](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000 __Z3cppv
> [ 19](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000005 _doit
> [ 20](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0000001e __Z7DllMainPvmS_

  Yep, as you surmised; "(ty   0)" means the symbol type is
IMAGE_SYM_DTYPE_NULL, as opposed to "(ty  20)" which is IMAGE_SYM_DTYPE_FUNCTION
and is what you'd see on other PE platforms.

  BSF_FUNCTION is BSD's internal flag which denotes this.  It should be being
set in the assembler, at the same time as the symbol's type value, based on the
.def directives emitted by the compiler in the generated assembler; these look like

	.def	_ffi_call_SYSV;	.scl	2;	.type	32;	.endef

and it's the .type subdirective with value 32 that indicates a function.

  Check if your compiler is generating these directives, it's most likely that
it isn't, since the code in the assembler to handle them is pretty generic and
simple.  In the Cygwin and MinGW compilers, this is handled by the function
i386_pe_declare_function_type() in gcc/config/i386/winnt.c (note also how it
needs to be called for undefined extern functions, see i386_pe_file_end().)
Take a look in the cygming.h header file to see which of GCC's target macros
need to be patched to emit a function .def directive by calling this code.

    cheers,
      DaveK


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]