Hey All,

> If I remember correctly, I will have to reconfirm though we should not
> need the @ for short import libraries

After some testing I can confirm I was correct about not needing the @
decorator for short import libraries.
Nor do we need to prepend `_`, msvc lib.exe does that automatically and we
can easily enable the same `_` behaviour on llvm-dlltool with the flag I
linked in a previous email. https://github.com/llvm-mirror/llvm/blob/master/
include/llvm/Object/COFFModuleDefinition.h#L48

Martin added a patch to add support for stripping the @4, @8, @12 for
llvm-dlltool which led us to discover this issue.
http://cygwin.com/ml/binutils/2004-09/msg00031.html
https://msdn.microsoft.com/en-us/library/deaxefa7.aspx

With that in mind we should probably also add x86 to the unified def
proposal but at the same time keep the old i386 def files for binutils
dlltool.
We can use a flag to just change between them both at compile time.

The def files for x86 should be identical to x64, arm, arm64 etc bar
functions it does not have because we should not need any macro trickery we
discussed previously as InitializeCriticalSection will convert directly to
_InitializeCriticalSection when the short library is created, given the
fact we do not need the @4 this is directly equivalent to
_InitializeCriticalSection@4 in the old format.

Best,
Martell


On Wed, Aug 9, 2017 at 2:37 PM, Martell Malone <martellmal...@gmail.com>
wrote:

> Nevertheless llvm-dlltool should learn at least the '==' aliasing.  We
>> rely on it in our runtime, so I think it would be pretty helpful.
>
> Sorry I should clarify in case I caused confusion.
> llvm-dll tool supports `==` aliasing, it just does it using PE/COFF Aux
> spec 3 weak externals.
> binutils dlltool does it's own custom thing outside of the spec which lld
> and link.exe don't like.
> the binutils linker as a result only supports what binutils dlltool does
> for `==` and not the within spec way.
>
> Best,
> Martell
>
> On Wed, Aug 9, 2017 at 2:32 PM, Kai Tietz via Mingw-w64-public <
> mingw-w64-public@lists.sourceforge.net> wrote:
>
>> 2017-08-09 15:11 GMT+02:00 Martell Malone <martellmal...@gmail.com>:
>> >>
>> >> Just out of curiosity - the 800 def files that only are available for
>> >> x86_64 but not for i686, are they something that somebody practically
>> care
>> >> about? Should we try to add them to i686 as well (given that they
>> probably
>> >> actually exist there as well)? Do they serve any real purpose?
>> >
>> >
>> > I don't want to put this on you for this patch but while we are on this
>> > discussion, I want to bring the issue up.
>> > The same thing should apply to x64 and x86 also.
>> > binutils dlltool and mingw-w64 does some weird wrapping of the `_` for
>> x86
>> > to make it appear more like x64 symbols that is not done by msvc lib.exe
>> > and the msvc headers.
>> > We would ideally update dlltool and mingw-w64 to not do this anymore.
>> >
>> > In llvm I left room to easily enable and disable this for llvm-dlltool
>> > https://github.com/llvm-mirror/llvm/blob/master/include/
>> llvm/Object/COFFModuleDefinition.h#L48
>> >
>> > I talked to Rui a little bit before about adding a flag for
>> llvm-dlltool to
>> > disable this
>> > The same flag should be added to dlltool so that we can share def files
>> > between all 4 targets.
>> >
>> > For the rest, I guess it needs more or less manual labour to sort out
>> the
>> >> differences into some sort of template like what I described. The i686
>> ones
>> >> with stdcall probably aren't mergeable at all, unless we do even more
>> >> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection,
>> @4).
>> >
>> > If I remember correctly, I will have to reconfirm though we should not
>> need
>> > the @ for short import libraries but binutils dlltool doesn't use short
>> > import libs. :(
>> > ld supports them however.. even though it does not support the PE/COFF
>> Aux
>> > spec 3 for weak externals i.e. the `==` functions in llvm-dlltool
>> > So there are 3 issues here at least for sharing i686 with the rest.
>>
>> Right, and we have to consider backward compatibility about mangled stuff
>> ...
>>
>> > With that in mind it might be a good idea just to share the other 3 for
>> now
>> > leaving i686 as is?
>>
>> Yes, I think we should keep x86 separate.  It is pretty painful to
>> support all this nasty x86 symbol decoration stuff in a compatible way
>> for the other 3 architectures.
>>
>> Nevertheless llvm-dlltool should learn at least the '==' aliasing.  We
>> rely on it in our runtime, so I think it would be pretty helpful.
>>
>> Regards,
>> Kai
>>
>> >
>> >
>> >
>> > On Wed, Aug 9, 2017 at 1:50 PM, Martin Storsjö <mar...@martin.st>
>> wrote:
>> >
>> >> On Wed, 9 Aug 2017, Jacek Caban wrote:
>> >>
>> >> On 08.08.2017 22:32, Martin Storsjö wrote:
>> >>>
>> >>>> The libarm64 directory is a copy of libarm32 with minimal
>> modifications
>> >>>> (renamings in the *.mri scripts and in Makefile.am).
>> >>>>
>> >>>
>> >>>
>> >>> In that case I don't think we should have actual copies of every
>> single
>> >>> .def file. It should be possible to use the same files for both
>> >>> platforms by simply modifying Makefile.am. Maybe we should have
>> libarm/
>> >>> for common files and then libarm32/ and libarm64/ for things that
>> >>> differ? I'm not sure about the exact solution, but I think we should
>> >>> share those one way or another.
>> >>>
>> >>
>> >> That'd probably be a good idea - the size of the total amount of def
>> files
>> >> is staggering. There's >1100 def files in libarm32 weighing in over 7
>> MB.
>> >> This patch, generated with git format-patch -C, is even 400 KB, just to
>> >> describe the copied files... lib64 also has got about as many files,
>> while
>> >> lib32 only has got a bit over 300 files.
>> >>
>> >> Just out of curiosity - the 800 def files that only are available for
>> >> x86_64 but not for i686, are they something that somebody practically
>> care
>> >> about? Should we try to add them to i686 as well (given that they
>> probably
>> >> actually exist there as well)? Do they serve any real purpose?
>> >>
>> >>
>> >> That said, most DLLs probably are mostly identical, but some might have
>> >> minor differences. Ideally these should be dumped from real DLL files,
>> just
>> >> like on previous platforms, but since platform isn't really available
>> yet,
>> >> it's not really doable, so I started out with the one that is most
>> probable
>> >> to be similar, and then meant to add other changes on top once we know
>> more
>> >> details.
>> >>
>> >> Ideally we'd do something like wine, with minor arch annotations in the
>> >> spec files for the few functions that differ. Perhaps something with
>> CPP
>> >> macros, like we already have for def-include/msvcrt-common.def.in -
>> with
>> >> macros like FUNC_ARM_ARM64(fabsf) or something such.
>> >>
>> >> I guess the first step would be to try to compare what we have and
>> unify
>> >> those that are easily mergeable (that already are identical). Hopefully
>> >> that'd be the vast majority of them.
>> >>
>> >> For the rest, I guess it needs more or less manual labour to sort out
>> the
>> >> differences into some sort of template like what I described. The i686
>> ones
>> >> with stdcall probably aren't mergeable at all, unless we do even more
>> >> elaborate macro trickery like FUNC_STDCALL(InitializeCriticalSection,
>> @4).
>> >>
>> >> // Martin
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Reply via email to