Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
On Sat, 27 Apr 2024, LIU Hao wrote: 在 2024-04-27 19:46, Pali Rohár 写道: Symbol alias is defined by "==". This message is incorrect. `=` really defines an alias [1]. `==` specifies the export name (the name before `==` is used by the linker). For an import library, there is likely no difference. The difference arises when building a DLL with this DEF file: * `foo = bar` (aliasing) indicates that a function called `bar` exists in the DLL's source code, and it is exported both as `foo` and `bar`. No, if this is used when linking a DLL, it does not export both names, it only exports "foo". I don't mind the casual use of "alias" for these purposes for how we normally use it - but I agree that saying "==" defines an alias, is incorrect. Anyway, I tried to clarify this bit in the commit messages (and fix a few other bits); I'll re-send the whole set of patches to the list before pushing. // Martin ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
On Saturday 27 April 2024 13:46:38 Pali Rohár wrote: > Symbol alias is defined by "==". So, in my opinion, the improved commit message could be: Right part of the single '=' operator is not used for creating import library. If DLL library symbol name differs from the symbol in import library then it has to be specified at right part of double '==' operator. What do you think? > --- > mingw-w64-crt/lib32/msvcr90d.def.in | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in > b/mingw-w64-crt/lib32/msvcr90d.def.in > index 4c31b632351e..db2eb6e01991 100644 > --- a/mingw-w64-crt/lib32/msvcr90d.def.in > +++ b/mingw-w64-crt/lib32/msvcr90d.def.in > @@ -1295,7 +1295,7 @@ _wfindfirst32i64 > _wfindfirst64 > _wfindfirst64i32 > _wfindnext32 > -_wfindnext = _wfindnext32 > +_wfindnext == _wfindnext32 > _wfindnext32i64 > _wfindnext64 > _wfindnext64i32 > -- > 2.20.1 > ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
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 0008 00dc 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .idata$7 0004 00e4 2**2
CONTENTS, RELOC
2 .idata$5 0004 00e8 2**2
CONTENTS, RELOC
3 .idata$4 0004 00ec 2**2
CONTENTS, RELOC
4 .idata$6 0008 00f0 2**2
CONTENTS
SYMBOL TABLE:
[ 0](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x .text
[ 1](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x .idata$7
[ 2](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x .idata$5
[ 3](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x .idata$4
[ 4](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x .idata$6
[ 5](sec -1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x0001 @feat.00
[ 6](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x _foo
[ 7](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x __imp__foo
[ 8](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x __head_test_dll
Contents of section .text:
ff25 9090.%..
Contents of section .idata$7:
Contents of section .idata$5:
Contents of section .idata$4:
Contents of section .idata$6:
01006261 7200..bar...
Disassembly of section .text:
<_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
Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
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
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
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.
// Martin
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
On Saturday 27 April 2024 22:47:33 LIU Hao wrote:
> The difference arises when building a DLL with this DEF file:
>
> * `foo = bar` (aliasing) indicates that a function called `bar` exists in
> the
> DLL's source code, and it is exported both as `foo` and `bar`. In the
> case of
> x86 stdcall, both `foo` and `bar` shall include an `@` suffix.
I did an another experiment for building a DLL library:
$ cat test.def
LIBRARY "test.dll"
EXPORTS
foo = bar
$ cat test.c
void bar(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:foo
So this shows that only symbol "foo" is exported. There is exported "bar".
> * `foo == bar` (renaming) indicates that a function called `foo` exists in
> the
> DLL's source code, and it is exported as `bar`. `bar` may and may not
> contain
> an `@` suffix, as the use varies.
Experiment:
$ cat test.def
LIBRARY "test.dll"
EXPORTS
foo == bar
$ cat test.c
void foo(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
And there is only bar exported. When function is source code is named as
"bar" (like in the first example) then linker throws error:
i686-w64-mingw32-ld: cannot export foo: symbol not defined
collect2: error: ld returned 1 exit status
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.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
On Saturday 27 April 2024 22:47:33 LIU Hao wrote:
> 在 2024-04-27 19:46, Pali Rohár 写道:
> > Symbol alias is defined by "==".
>
> This message is incorrect. `=` really defines an alias [1]. `==` specifies
> the export name (the name before `==` is used by the linker).
Ok, I see. Alias is somehow overloaded word and lot of times I just
use alias for both cases. I will try to avoid making confusion here.
> For an import library, there is likely no difference.
I did some experiments and results are that for an import library, right
part of the "=" is completely ignored. So there is a big difference.
Simple test case:
$ cat lib.def
LIBRARY "lib.dll"
EXPORTS
func1 = func2
func3 == func4
$ cat test.c
void func1(void);
void func3(void);
void test(void) {
func1();
func3();
}
int main() { test(); }
Compile with:
$ i686-w64-mingw32-dlltool -d lib.def -l lib.a
$ i686-w64-mingw32-gcc test.c lib.a -o test.exe
And then inspect import table of the test.exe.
$ readpe -i test.exe | tail -20
Library
Name:lib.dll
Functions
Function
Hint:2
Name:func4
Function
Hint:1
Name:func1
As can be seen, the func1 symbol is being used, even the fact that in
lib.def was line "func1 = func2". So it is same as if lib.def contained
only line "func1".
On the other hand, no "func3" is in import table. And this was due to
usage of "func3 == func4" with double "==", which renamed the symbol.
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
在 2024-04-27 19:46, Pali Rohár 写道: Symbol alias is defined by "==". This message is incorrect. `=` really defines an alias [1]. `==` specifies the export name (the name before `==` is used by the linker). For an import library, there is likely no difference. The difference arises when building a DLL with this DEF file: * `foo = bar` (aliasing) indicates that a function called `bar` exists in the DLL's source code, and it is exported both as `foo` and `bar`. In the case of x86 stdcall, both `foo` and `bar` shall include an `@` suffix. * `foo == bar` (renaming) indicates that a function called `foo` exists in the DLL's source code, and it is exported as `bar`. `bar` may and may not contain an `@` suffix, as the use varies. [1] https://sourceware.org/binutils/docs/binutils/def-file-format.html -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 2/7] crt: msvcr90d.def.in: Fix I386 symbol alias _wfindnext
Symbol alias is defined by "==". --- mingw-w64-crt/lib32/msvcr90d.def.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mingw-w64-crt/lib32/msvcr90d.def.in b/mingw-w64-crt/lib32/msvcr90d.def.in index 4c31b632351e..db2eb6e01991 100644 --- a/mingw-w64-crt/lib32/msvcr90d.def.in +++ b/mingw-w64-crt/lib32/msvcr90d.def.in @@ -1295,7 +1295,7 @@ _wfindfirst32i64 _wfindfirst64 _wfindfirst64i32 _wfindnext32 -_wfindnext = _wfindnext32 +_wfindnext == _wfindnext32 _wfindnext32i64 _wfindnext64 _wfindnext64i32 -- 2.20.1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
