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

Reply via email to