PATCH mingw32 PE dlltool: Use internal name in import files.

PATCH mingw32 PE dlltool: Use internal name in import files.

[Aaron W. LaFramboise]

It seems as if internal names were only implemented superficially.  The
parser read in the internal names, and would write them back out, but it
didn't actually use them when generating import libraries.  It seems a
little strange that noone ever noticed this, as this is a fairly
important feature.

This patch trivially fixes this.

2004-06-28  Aaron W. LaFramboise <aaron98wiridge9@aaronwl.com>

	* binutils/dlltool.c (make_one_lib_file): Use internal_name
	instead of name.

Index: src/binutils/dlltool.c
===================================================================
RCS file: /cvs/src/src/binutils/dlltool.c,v
retrieving revision 1.49
diff -c -3 -p -r1.49 dlltool.c
*** src/binutils/dlltool.c	15 Jun 2004 01:19:13 -0000	1.49
--- src/binutils/dlltool.c	28 Jun 2004 09:52:48 -0000
*************** make_one_lib_file (export_type *exp, int
*** 2311,2317 ****
        if (! exp->data)
  	{
  	  exp_label = bfd_make_empty_symbol (abfd);
! 	  exp_label->name = make_imp_label ("", exp->name);

  	  /* On PowerPC, the function name points to a descriptor in
  	     the rdata section, the first element of which is a
--- 2311,2317 ----
        if (! exp->data)
  	{
  	  exp_label = bfd_make_empty_symbol (abfd);
! 	  exp_label->name = make_imp_label ("", exp->internal_name);

  	  /* On PowerPC, the function name points to a descriptor in
  	     the rdata section, the first element of which is a
*************** make_one_lib_file (export_type *exp, int
*** 2340,2353 ****
        if (create_compat_implib)
  	{
  	  iname = bfd_make_empty_symbol (abfd);
! 	  iname->name = make_imp_label ("___imp", exp->name);
  	  iname->section = secdata[IDATA5].sec;
  	  iname->flags = BSF_GLOBAL;
  	  iname->value = 0;
  	}

        iname2 = bfd_make_empty_symbol (abfd);
!       iname2->name = make_imp_label ("__imp_", exp->name);
        iname2->section = secdata[IDATA5].sec;
        iname2->flags = BSF_GLOBAL;
        iname2->value = 0;
--- 2340,2353 ----
        if (create_compat_implib)
  	{
  	  iname = bfd_make_empty_symbol (abfd);
! 	  iname->name = make_imp_label ("___imp", exp->internal_name);
  	  iname->section = secdata[IDATA5].sec;
  	  iname->flags = BSF_GLOBAL;
  	  iname->value = 0;
  	}

        iname2 = bfd_make_empty_symbol (abfd);
!       iname2->name = make_imp_label ("__imp_", exp->internal_name);
        iname2->section = secdata[IDATA5].sec;
        iname2->flags = BSF_GLOBAL;
        iname2->value = 0;

Re: PATCH mingw32 PE dlltool: Use internal name in import files.

[Aaron W. LaFramboise]

I don't think this is right.  After checking, the MS tools do not seem
to do this.

Can someone explain to me what internal_name is supposed to mean?  I
can't find it documented anywhere what exactly its meaning is!

EXPORTS
name = internal_name

What does internal_name represent?  Does it even do anything?  While it
is carried from input .def to output .def, it does not appear to be put
into either output import libraries or output .exp's.

I notice that Mumit Khan added an option --add-stdcall-alias to dlltool,
but how can this possibly do anything if aliases do not seem to do anything?

Very confused,

Aaron W. LaFramboise

RE: PATCH mingw32 PE dlltool: Use internal name in import files.

[Dave Korn]

> -----Original Message-----
> From: binutils-owner On Behalf Of Aaron W. LaFramboise
> Sent: 29 June 2004 06:18

> I don't think this is right.  After checking, the MS tools do not seem
> to do this.
> 
> Can someone explain to me what internal_name is supposed to mean?  I
> can't find it documented anywhere what exactly its meaning is!
> 
> EXPORTS
> name = internal_name
> 
> What does internal_name represent?  Does it even do anything? 
>  While it
> is carried from input .def to output .def, it does not appear 
> to be put
> into either output import libraries or output .exp's.

  According to MSDN, this construct allows you to create an exported
function 'name' that corresponds to an actual function 'internal_name' in
the .dll; that is, 'internal_name' is the real function in the code and
'name' is the externally-visible alias that callers link against, that you
can look up with GetProcAddress, etc, etc.

> I notice that Mumit Khan added an option --add-stdcall-alias 
> to dlltool,
> but how can this possibly do anything if aliases do not seem 
> to do anything?

  Ah, that'll be something to do with the name decoration, won't it?  It's
not normal for plain old C symbols to get mangled, but when you use the
stdcall calling convention, M$' tools decorate the name with '@nnn', where
nnn is the number of bytes of stack arguments the function takes.  IIRC the
--add-stdcall-alias just means that for each symbol with the '@nnn' postfix,
you also get an equivalent undecorated symbol generated, to make linking
against callers that don't understand M$ stdcall name decoration that little
bit easier.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....