[PATCH] D89518: [windows-itanium] Add Windows Itanium How-To Guide

[ben via Phabricator via llvm-commits]

bd1976llvm added a comment.

@mstorsjo are you happy with this now?



================
Comment at: llvm/docs/HowToBuildWindowsItaniumPrograms.rst:39
+
+link.exe (the MS linker) is unsuitable as it rejects the COMDATs produced by
+LLVM. It also doesn't support auto-importing which is currently required.
----------------
mstorsjo wrote:
> mstorsjo wrote:
> > bd1976llvm wrote:
> > > mstorsjo wrote:
> > > > Did you look into why it produces such comdats? Because for msvc triple targets, it should work with link.exe.
> > > I think I conflated several issues here, as I was trying to get the build set up, and got myself confused. Originally, I think I was somehow generating the "leaderless comdats" that you mentioned in another thread. I had thought that the leaderless comdats were related to multiply defined symbols being present. Happily, I no longer see the leaderless comdats and the remaining multiply defined symbol problems have now been solved and were unrelated. I can now link with MS's link.exe and I have adjusted the doc accordingly.
> > > 
> > > There is a remaining comdat issue that I see when building libc++ when not using the internal assembler which occurs if I try to use the ' -save-temps=obj' option for debugging. Errors are emitted such as:
> > > 
> > >     #                It seems that source -> assembly -> obj may report comdat
> > >     #                errors (when assembling) that are not reported doing source-> obj.
> > >     #                Example:
> > >     #                  src/CMakeFiles/cxx_shared.dir\locale.s:107958:2: error: section '.xdata$' is already linkonce
> > >     #                  .linkonce       discard
> > > 
> > > I doubt this is related to Windows Itanium and I haven't looked into it more as it isn't currently blocking me.
> > Ok, great to hear that those bits are sorted out.
> > 
> > Regarding roundtripping through assembly, it's possible that it ends up misgenerated for these cases, but it doesn't seem like I can reproduce it for a trivial case at least. For the gnu assembly syntax, GCC (which doesn't properly use all the aspects of COFF comdats) uses one syntax, while llvm has extended the syntax to support indicating the leader symbol.
> > 
> > A COFF comdat generated by GCC looks like this:
> > ```
> >         .section        .text$_Z6myfuncv,"x"
> >         .linkonce discard
> > ```
> > while generated by clang it looks like this:
> > ```
> >         .section        .text$_Z6myfuncv,"xr",discard,_Z6myfuncv
> > ```
> > 
> > (For comdats without a leader symbol, LLVM also generates the GCC-like syntax.)
> > 
> > It sounds to me like there's some mixup between these two happening?
> > 
> > With a test file like this:
> > ```
> > inline void myfunc(void) {}
> > void (*ptr)(void) = myfunc;
> > ```
> > I get the expected syntax for a `x86_64-windows-itanium` target, but maybe it happens with cases that are a bit harder to trigger, like jump tables or something like that...
> The doc still talks about generating invalid comdats that MS link.exe rejects - that's no longer the case right?
Correct. Thanks!


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D89518/new/

https://reviews.llvm.org/D89518