Erik van Pienbroek | 23 May 23:29 2013
Picon

Regression in trunk regarding InterlockedCompareExchange

Hi,

During review of one of our Fedora packages we noticed an unexpected
change in behavior in recent mingw-w64 trunk snapshots. We noticed that
several libraries which were built against recent mingw-w64 trunk
snapshots suddenly started to export the symbols
_InterlockedCompareExchange and InterlockedCompareExchange <at> 12 in their
shared libraries. 

Libraries which now show this behavior in Fedora are:
* libasprintf-0.dll (gettext)
* libcrypto-10.dll (openssl)
* libffi-6.dll
* libgmp-10.dll
* libgnutls-xssl-0.dll
* libgnutlsxx-28.dll
* libintl-8.dll (gettext)
* libobjc-4.dll (gcc)
* libpixman-1-0.dll
* libspice-controller-0.dll (spice)
* libsqlite3-0.dll
* libusb-1.0.dll (libusbx)
* QtUiTools4.dll (qt4)

The thing all these libraries have in common that they were built
against recent mingw-w64 snapshots.

The issue can be illustrated by opening the dll in question in
dependency walker or by running objdump:

(Continue reading)

Dongsheng Song | 25 May 12:57 2013
Picon

Re: Regression in trunk regarding InterlockedCompareExchange

On Fri, May 24, 2013 at 5:29 AM, Erik van Pienbroek
<erik@...> wrote:
> Hi,
>
> During review of one of our Fedora packages we noticed an unexpected
> change in behavior in recent mingw-w64 trunk snapshots. We noticed that
> several libraries which were built against recent mingw-w64 trunk
> snapshots suddenly started to export the symbols
> _InterlockedCompareExchange and InterlockedCompareExchange <at> 12 in their
> shared libraries.
>
> Libraries which now show this behavior in Fedora are:
> * libasprintf-0.dll (gettext)
> * libcrypto-10.dll (openssl)
> * libffi-6.dll
> * libgmp-10.dll
> * libgnutls-xssl-0.dll
> * libgnutlsxx-28.dll
> * libintl-8.dll (gettext)
> * libobjc-4.dll (gcc)
> * libpixman-1-0.dll
> * libspice-controller-0.dll (spice)
> * libsqlite3-0.dll
> * libusb-1.0.dll (libusbx)
> * QtUiTools4.dll (qt4)
>
> The thing all these libraries have in common that they were built
> against recent mingw-w64 snapshots.
>
> The issue can be illustrated by opening the dll in question in
(Continue reading)

Erik van Pienbroek | 25 May 20:46 2013
Picon

Re: Regression in trunk regarding InterlockedCompareExchange

Erik van Pienbroek schreef op do 23-05-2013 om 23:29 [+0200]:
> Hi,
> 
> During review of one of our Fedora packages we noticed an unexpected
> change in behavior in recent mingw-w64 trunk snapshots. We noticed that
> several libraries which were built against recent mingw-w64 trunk
> snapshots suddenly started to export the symbols
> _InterlockedCompareExchange and InterlockedCompareExchange <at> 12 in their
> shared libraries. 

Here's a really minimal testcase which demonstrates the problem:

$ touch foo.c
$ i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--export-all-symbols
$ i686-w64-mingw32-objdump -p foo.dll
<snip>
[Ordinal/Name Pointer] Table
	[   0] InterlockedCompareExchange <at> 12
	[   1] _InterlockedCompareExchange
<snip>

So even when an empty library is built it will export the two
InterlockedCompareExchange symbols..

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
(Continue reading)

Erik van Pienbroek | 10 Jun 21:46 2013
Picon

Re: Regression in trunk regarding InterlockedCompareExchange

Erik van Pienbroek schreef op za 25-05-2013 om 20:46 [+0200]:
> Here's a really minimal testcase which demonstrates the problem:
> 
> $ touch foo.c
> $ i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--export-all-symbols
> $ i686-w64-mingw32-objdump -p foo.dll
> <snip>
> [Ordinal/Name Pointer] Table
> 	[   0] InterlockedCompareExchange <at> 12
> 	[   1] _InterlockedCompareExchange
> <snip>
> 
> So even when an empty library is built it will export the two
> InterlockedCompareExchange symbols..

Any news on this issue?

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
Kai Tietz | 10 Jun 21:49 2013

Re: Regression in trunk regarding InterlockedCompareExchange

2013/6/10 Erik van Pienbroek <erik@...>:
> Erik van Pienbroek schreef op za 25-05-2013 om 20:46 [+0200]:
>> Here's a really minimal testcase which demonstrates the problem:
>>
>> $ touch foo.c
>> $ i686-w64-mingw32-gcc -shared foo.c -o foo.dll -Wl,--export-all-symbols
>> $ i686-w64-mingw32-objdump -p foo.dll
>> <snip>
>> [Ordinal/Name Pointer] Table
>>       [   0] InterlockedCompareExchange <at> 12
>>       [   1] _InterlockedCompareExchange
>> <snip>
>>
>> So even when an empty library is built it will export the two
>> InterlockedCompareExchange symbols..
>
> Any news on this issue?

I will take a look to this this evening.  We will need to remove here
the alias-code to fix that

Kai

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
(Continue reading)

Erik van Pienbroek | 14 Jun 19:28 2013
Picon

Re: Regression in trunk regarding InterlockedCompareExchange

Kai Tietz schreef op ma 10-06-2013 om 21:49 [+0200]:
> 2013/6/10 Erik van Pienbroek <erik@...>:
> > Any news on this issue?
> 
> I will take a look to this this evening.  We will need to remove here
> the alias-code to fix that

For now I've managed to workaround the regression by partially reverting
r5713. This change makes intrincs/ilockcxch.c part of libmingwex instead
of libkernel32 (as it was before r5713). I'm using this patch now in the
Fedora mingw-w64 toolchain where it will be used until a proper solution
has come up.

Regards,

Erik van Pienbroek

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@...
(Continue reading)

Erik van Pienbroek | 16 Jun 11:42 2013
Picon

Re: Regression in trunk regarding InterlockedCompareExchange

Erik van Pienbroek schreef op vr 14-06-2013 om 19:28 [+0200]:
> For now I've managed to workaround the regression by partially reverting
> r5713. This change makes intrincs/ilockcxch.c part of libmingwex instead
> of libkernel32 (as it was before r5713). I'm using this patch now in the
> Fedora mingw-w64 toolchain where it will be used until a proper solution
> has come up.

Unfortunately a similar issue has also started to show up on the x86_64
target. As of r5898 shared libraries (which are generated without an
explicit .def file) start to export the symbol __mingw_get_msvcrt_handle
as can be seen with this minimal testcase:

$ touch foo.c 
$ cat foo.c
$ x86_64-w64-mingw32-gcc -shared foo.c -o foo.dll
$ x86_64-w64-mingw32-objdump -p foo.dll | grep -A2 '\[Ordinal/Name
Pointer\] Table'
[Ordinal/Name Pointer] Table
	[   0] __mingw_get_msvcrt_handle

In Fedora we've also reversed this specific commit (r5898) for now until
a proper solution comes up.

Regards,

Erik van Pienbroek

------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:

(Continue reading)

Jacek Caban | 17 Jun 15:14 2013

Re: Regression in trunk regarding InterlockedCompareExchange

On 06/16/13 11:42, Erik van Pienbroek wrote:
> Erik van Pienbroek schreef op vr 14-06-2013 om 19:28 [+0200]:
>> For now I've managed to workaround the regression by partially reverting
>> r5713. This change makes intrincs/ilockcxch.c part of libmingwex instead
>> of libkernel32 (as it was before r5713). I'm using this patch now in the
>> Fedora mingw-w64 toolchain where it will be used until a proper solution
>> has come up.
> Unfortunately a similar issue has also started to show up on the x86_64
> target. As of r5898 shared libraries (which are generated without an
> explicit .def file) start to export the symbol __mingw_get_msvcrt_handle
> as can be seen with this minimal testcase:
>
> $ touch foo.c 
> $ cat foo.c
> $ x86_64-w64-mingw32-gcc -shared foo.c -o foo.dll
> $ x86_64-w64-mingw32-objdump -p foo.dll | grep -A2 '\[Ordinal/Name
> Pointer\] Table'
> [Ordinal/Name Pointer] Table
> 	[   0] __mingw_get_msvcrt_handle
>
>
> In Fedora we've also reversed this specific commit (r5898) for now until
> a proper solution comes up.
>

I committed a fix for that (r5912). Thanks for the report.

Jacek

------------------------------------------------------------------------------
(Continue reading)

Erik van Pienbroek | 13 Jul 20:42 2013
Picon

Re: Regression in trunk regarding InterlockedCompareExchange

Erik van Pienbroek schreef op do 23-05-2013 om 23:29 [+0200]:
> Hi,
> 
> During review of one of our Fedora packages we noticed an unexpected
> change in behavior in recent mingw-w64 trunk snapshots. We noticed that
> several libraries which were built against recent mingw-w64 trunk
> snapshots suddenly started to export the symbols
> _InterlockedCompareExchange and InterlockedCompareExchange <at> 12 in their
> shared libraries. 

Just a heads up that this regression is resolved now in mingw-w64 trunk.
This is probably due to r5949 which was committed today (which changes
the way the Interlocked symbols are implemented in mingw-w4).

In Fedora we've dropped our local patch which was used to temporary
workaround the issue.

Regards,

Erik van Pienbroek
Fedora MinGW SIG

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk

Gmane