On Tuesday 30 April 2024 00:52:53 Martin Storsjö wrote:
> On Tue, 30 Apr 2024, Martin Storsjö wrote:
> 
> > On Mon, 29 Apr 2024, Pali Rohár wrote:
> > 
> > > So based on these experiments when building library, I can conclude
> > > that:
> > > 
> > >  X = Y
> > > 
> > > is the same as:
> > > 
> > >  Y == X
> > > 
> > > and it means that function named X in the source code is present in the
> > > result DLL library under name Y.
> > > 
> > > So `foo = bar` is also renaming of the symbol, and not aliasing.
> > > 
> > > 
> > > For completeness, what happens when both = and == are used at the
> > > same line:
> > > 
> > > $ cat test.def
> > > LIBRARY "test.dll"
> > > EXPORTS
> > > foo = func == bar
> > > 
> > > $ cat test.c
> > > void func(void) { }
> > > 
> > > $ i686-w64-mingw32-gcc -shared test.c test.def -o test.dll
> > > 
> > > $ readpe -e test.dll
> > > Exported functions
> > >    Library
> > >        Name:                            test.dll
> > >        Functions
> > >            Function
> > >                Ordinal:                         1
> > >                Address:                         0x1410
> > >                Name:                            bar
> > > 
> > > 
> > > So line "X = Y == Z" has same meaning as "Y == Z" and so same as "Z
> > > = X".
> > > 
> > > Such logic does not make sense for me, but whatever. It shows that
> > > documentation is incomplete and ambiguous.
> > 
> > As far as I know, they're used in different circumstances. When linking
> > a DLL, you'd use the syntax "X = Y" to export a symbol under a different
> > name. MS link also supports this syntax for this purpose.
> > 
> > When creating an import library with dlltool, the == syntax is used with
> > the purpose of creating an import library with a symbol with one name,
> > pointing at a DLL export with a different name.
> > 
> > I see you only inspected the export table of the linked DLLs in your
> > experiment, but you also should create an import library at the same
> > time (-Wl,--out-implib) and inspect what symbols it provides - which
> > hopefully would link against the export names of the DLL that was
> > created at the same time.
> 
> It's probably also interesting to test and see what dlltool does with this
> kind of def file.
> 
> // Martin

Ok, thanks for info. In previous email I already wrote results of the
dlltool experiment for import library and right part of '=' was ignored.

Now I created import library via --out-implib as you wrote:

$ i686-w64-mingw32-gcc -shared test.c test.def -o test.dll 
-Wl,--out-implib=test.a

$ i686-w64-mingw32-objdump --all -s -dr test.a

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000008  00000000  00000000  000000dc  2**2
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .idata$7      00000004  00000000  00000000  000000e4  2**2
                  CONTENTS, RELOC
  2 .idata$5      00000004  00000000  00000000  000000e8  2**2
                  CONTENTS, RELOC
  3 .idata$4      00000004  00000000  00000000  000000ec  2**2
                  CONTENTS, RELOC
  4 .idata$6      00000008  00000000  00000000  000000f0  2**2
                  CONTENTS
SYMBOL TABLE:
[  0](sec  1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 .text
[  1](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 .idata$7
[  2](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 .idata$5
[  3](sec  4)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 .idata$4
[  4](sec  5)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000000 .idata$6
[  5](sec -1)(fl 0x00)(ty   0)(scl   3) (nx 0) 0x00000001 @feat.00
[  6](sec  1)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000 _foo
[  7](sec  3)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000 __imp__foo
[  8](sec  0)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000 __head_test_dll

Contents of section .text:
 0000 ff250000 00009090                    .%......
Contents of section .idata$7:
 0000 00000000                             ....
Contents of section .idata$5:
 0000 00000000                             ....
Contents of section .idata$4:
 0000 00000000                             ....
Contents of section .idata$6:
 0000 01006261 72000000                    ..bar...

Disassembly of section .text:

00000000 <_foo>:
   0:   ff 25 00 00 00 00       jmp    *0x0
                        2: dir32        .idata$5
   6:   90                      nop
   7:   90                      nop


If I understand the output of the objdump correctly then it application
(linking to this import library) calls "foo" and linker resolves it to
"bar". Which is same result as from the dlltool test in previous email.


So the conclusion is that line "X = Y == Z" means:
* X - name of the function in import library
* Y - name of the function in the source file of DLL library
* Z - name of the function in DLL library

Default value for Z is X (if Z is omitted).
Default value for Y is X (if Y is omitted).

In case "A == B" left part means the function from import library
(and source file function is omitted).


Ok, now it makes sense. Seems that it is consistent between ld and
dlltool.

And that is why in mingw-w64 def files used just for creating import
libraries has to be used "==" (and not just single "=") for specifying
symbol aliases.


So thank you very much for helping me to understand this problematic.


_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to