>
> 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