Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Martin Storsjö]

On Fri, 21 Jul 2023, Cristian Adam wrote:


Right, lldb was using the DWARF debugging information 

I've attached 3 screenshots of Qt Creator using lldb:

 1.  Unstripped MaxiDump.exe showed the bad source line and the correct
stacktrace (due to DWARF information)
 2. Stripped MaxiDump.exe with LLVM MinGW's lldb showed only assembly with
bad stacktrace
 3. Stripped MaxiDump.exe with the official llvm.org binaries (MSVC flavor)
showed also assembly but with proper stacktrace.


If this was from the same build of MaxiDump.exe - if the debug info for 
the relevant translation units was written as DWARF, it probably wasn't 
written as CodeView for PDB. Or was that based on a new build where you 
made sure "-g -gcodeview" was used in more places?


IIRC it's possible to generate both DWARF and CodeView debug info at the 
same time too, but I haven't looked into how to do that (if it'd be enough 
to just add a -gdwarf or something like that?).



For number 3 I've tried with a copy of "c:\Program Files (x86)\Microsoft
Visual Studio\2019\BuildTools\DIA SDK\bin\amd64\msdia140.dll" in "c:\Program
Files\LLVM\bin"  and without.

I know that the llvm.org lldb binary is built using DIA SDK.


Indeed, LLVM/LLDB's own PDB support is incomplete - it works for some 
cases but not everything.



Then I decided to test clang-cl 16.0.6 and test the two lldb.exe versions.

The LLVM MinGW (stripped) binary and dmp files:

 *  MaxiDump.exe 15,872 bytes
 *  MaxiDump.dmp 29,878,132 bytes

The clang-cl binary and dmp files:

 *  MaxiDump.exe 15,360 bytes
 *  MaxiDump.dmp 28,460,315 bytes

They ware more or less the "same".

Then I loaded the "core" file and the results are:

 *  MSVC lldb.exe loaded the source file, but pointed at the wrong line,
also the stack trace was missing one level
 *  MinGW lldb.exe loaded the source file at the right location and the
stacktrace was fine!


Now that's odd...


Since MinGW lldb.exe can load a MiniDump file produced by clang-cl just
fine, I assume there is a bug in the generation step of the MiniDump when
using the llvm mingw binaries.


Hmm, that's possible.

In any case, if the main intended usecase is with lldb, then using DWARF 
for the debug info should probably be the best supported path.


I'll see if I can reproduce your results and maybe look into things at 
some point...



If you can fill in the github issue with reproduction steps in the form of 
exact compilation commands (bypassing cmake, just running a single command 
to compile+link is clearest) - from the ground up, compiling, stripping, 
running executables, running command line lldb to inspect the results - 
it'd be a bit more straightforward to look into and pinpoint potential 
issues.


At least from the looks of your cmake file, you're passing the -Wl,--pdb= 
option for writing a PDB file, but you're not specifying -gcodeview 
anywhere, so it uses the toolchain default of generating DWARF debug info 
only.


// Martin
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Martin Storsjö]

On Thu, 20 Jul 2023, Cristian Adam via Development wrote:


WinDbg didn't work, but lldb.exe itself works:

  lldb MaxiDump.exe --core MaxiDump.dmp

I've updated cristianadam/MaxiDump (github.com) with this new information.


FWIW, I didn't test minidumps, but I tested that PDBs currently do work 
with at least WinDbg and MSVS. My test procedure was:


- Grab 
https://github.com/mstorsjo/llvm-mingw/blob/master/test/hello-exception.cpp 
as testcase. Change the source to intialize it with "crash = true" to 
trigger the crash case without giving command line parameters to the 
executable.


- Compile with llvm-mingw-20230712-ucrt-x86_64 with "clang++ 
hello-exception.cpp -o hello-crash.exe -g -gcodeview -Wl,--pdb= -static"


- With WinDbg: File, Open Executable, locate hello-crash.exe. Debug, Go. 
And I get the crash location in source opened, with call stack and local 
variables inspectable at least.


- With MSVS: File, Open, Project/Solution, locate hello-crash.exe. Debug, 
Start Debugging. Source for the crash site is opened, call stack and local 
variables seem reasonable.


- With LLDB: As LLDB supports both DWARF and PDB, it will prefer DWARF if 
such debug info was found. As other toolchain files that are linked in 
happen to have some DWARF in them, the executable will have a little bit 
of such debug info available, so LLDB ends up using that and not looking 
at the PDB. So first I run "strip hello-crash.exe" to get rid of the 
residual DWARF, after that "lldb hello-crash.exe" followed by "run", and I 
get the crash easily visible. (This case could probably be made nicer.)


If LLDB worked for you without, possibly without stripping out residual 
DWARF, but WinDbg didn't, it sounds like it might have ended up using 
DWARF after all?


// Martin

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Martin Storsjö]

On Thu, 20 Jul 2023, Cristian Adam via Development wrote:




On 07/20/2023 15:48, Cristian Adam via Development wrote:

  At How to open Windows crash dumps? | Qt Forum this is one case
  of using Windows minidump files with MinGW, which is not
  supported.

  With the LLVM MinGW and the PDB format I expected this to ...
  work.

  I've pushed an example at cristianadam/MaxiDump (github.com) it
  works with MSVC and clang-cl. With LLVM MinGW I've got the pdb
  and the dmp files, but WinDbg would not resolve when typing
  .excr

  @Martin Storsjö Any clues why it didn't work?

WinDbg didn't work, but lldb.exe itself works:

  lldb MaxiDump.exe --core MaxiDump.dmp

I've updated cristianadam/MaxiDump (github.com) with this new information.


Nice. I faintly remember testing using the PDB files with WinDbg at some 
point (not with minidumps though, only with intercepting a live crash), 
and I think that should work, as should using the full Visual Studio IDE. 
I haven't tested that setup lately though.


If you're using lldb in the end, there shouldn't be much need for actually 
using PDBs, as lldb should be able to use minidumps together with the 
default DWARF debug info as well.


// Martin
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Martin Storsjö]

On Thu, 20 Jul 2023, Thiago Macieira wrote:


On Thursday, 20 July 2023 06:14:24 PDT Martin Storsjö wrote:

So are you saying that you're building your app with a non-default CRT
selected with the -mcrtdll option?


Yes.


If you use the GCC -mcrtdll option for picking a non-default CRT, it would
work unless you're also linking, even statically, a toolchain-provided
libstdc++ though. I'm pretty sure that at least some parts of libstdc++
touch things that have a differing ABI, even if most things might seem to
work.


We build our own GCC (after applying that patch), but I haven't checked
whether it used UCRT for cross-building libstdc++. Ideally we wouldn't need a
-mcrtdll option, but enforce it directly in the compiler.


Right - if you're already building GCC, you're actually in a great 
position to set things up properly. If you build a new sysroot for this 
GCC at the same time, it should be fairly straightforward to switch the 
CRT for this.


After building the compiler part of the new GCC (make install-gcc) you can 
set up the mingw-w64 headers/crt for this new toolchain - here you can 
configure both with --with-default-msvcrt=ucrt; after this you can finish 
building the rest of GCC's runtimes with this new sysroot, and everything 
will be built consistently with the new CRT. GCC itself will be linked 
against the CRT choice of your original toolchain, but whatever it 
produces will use the new one.


At https://martin.st/temp/gcc-mingw.docker I've got an example of such a 
bootstrap procedure. That's for starting out on Linux, building a cross 
compiler, and then using that to cross compile GCC for Windows. But if 
you're already on windows, it should be enough with the gcc/install-gcc + 
mingw-w64-headers + mingw-w64-crt + gcc/install steps.


// Martin
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Martin Storsjö]

On Thu, 20 Jul 2023, Thiago Macieira wrote:


On Wednesday, 19 July 2023 23:48:43 PDT Martin Storsjö wrote:

Switching with those flags works, as long as you're building a C-only
executable and linking libgcc statically (and not linking in any static
libraries that were built for another CRT). I'm pretty sure that libstdc++
touches lots of the things that have a differing ABI. A shared linked
libgcc will use the CRT that the toolchain was built with - although I'm
not sure if libgcc shares any CRT objects across the DLL boundary (whether
it is a real issue or just messy).


Thanks, Martin.

I was aware of this, but thanks for expanding on who it's really a binary-
incompatible choice.

For $DAYJOB project[1], we build the compiler itself and the libraries we
need, linking statically to all of them except libmingw & libwinpthread. I
need to check what those import and if they are binary-compatible.


Yeah, as there's so many different ABI affecting choices especially around 
here, building all the libraries yourself is definitely the recommended 
way to go IMO as well.


So are you saying that you're building your app with a non-default CRT 
selected with the -mcrtdll option?


If you use the GCC -mcrtdll option for picking a non-default CRT, it would 
work unless you're also linking, even statically, a toolchain-provided 
libstdc++ though. I'm pretty sure that at least some parts of libstdc++ 
touch things that have a differing ABI, even if most things might seem to 
work.


The msys2-carried old patch only switches what library to link against, 
but a recently upstreamed one, 
https://github.com/gcc-mirror/gcc/commit/453cb585f0f8673a5d69d1b420ffd4b3f53aca00, 
also sets matching flags for at least picking the right definitions from 
headers as well. The CRT switching flag from that commit, plus recompiling 
everything (and staying away from libstdc++) should generally achieve the 
same as using a purpose-configured toolchain.


The libmingw* parts (libmingw32.a and libmingwex.a) are intended to be 
CRT-agnostic - I'm not aware of any parts in them relying on things with a 
differing ABI or interface. A statically linked libgcc also probably is 
fine. For libwinpthread, I'm not sure though.


// Martin
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Martin Storsjö]

On Thu, 20 Jul 2023, Martin Storsjö wrote:


On Wed, 19 Jul 2023, Thiago Macieira wrote:


It's also orthogonal, because GCC supports UCRT too, with this patch:
https://github.com/msys2/MINGW-packages/raw/
8d9ebb74412c1faabc2a3935bfc705bec19edb9a/mingw-w64-gcc/0006-Windows-New-
feature-to-allow-overriding.patch


Indeed UCRT support isn't Clang specific at all - but GCC doesn't really need 
that patch either.


And conversely, that patch (and a later recently upstreamed version of the 
same) gives a false sense of being able to switch between msvcrt and UCRT at 
will; that feature really needs to come with a big disclaimer.


I realized the wrap-up of that mail might have sounded like taking a 
stance for/against either compiler, which it wasn't.


So TL;DR, pretend that flag doesn't exist in GCC, and just use a toolchain 
that was bootstrapped for the desired CRT. (The flag is more useful for 
switching between older variants of the MSVC CRTs that have less hairy ABI 
differences.)


I.e. use any toolchain, based on either GCC or Clang, bootstrapped with 
the desired CRT choice from the bottom up. But don't try to switch a 
msvcrt-targeting GCC toolchain to target UCRT with that flag (unless 
specifically doing low-level experimentation).


// Martin
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Martin Storsjö]

On Wed, 19 Jul 2023, Thiago Macieira wrote:


On Wednesday, 19 July 2023 08:46:27 PDT Cristian Adam via Development wrote:


With this migration would should also switch to Universal
CRT.
The toolchain comes in both ucrt and msvcrt variants, but the former is
preferrable nowadays.


Indeed and that's great, but that's a BC break. That means you'll need to
provide two sets of binaries for a time.

It's also orthogonal, because GCC supports UCRT too, with this patch:
https://github.com/msys2/MINGW-packages/raw/
8d9ebb74412c1faabc2a3935bfc705bec19edb9a/mingw-w64-gcc/0006-Windows-New-
feature-to-allow-overriding.patch


Indeed UCRT support isn't Clang specific at all - but GCC doesn't really 
need that patch either.


And conversely, that patch (and a later recently upstreamed version of the 
same) gives a false sense of being able to switch between msvcrt and UCRT 
at will; that feature really needs to come with a big disclaimer.


That flag, allowing you to decide whether to target msvcrt or UCRT when 
building/linking your end user executable, only works in a small subset of 
scenarios if you're really careful and know what you're doing - if not, 
it's a very subtle footgun.


There are significant differences in how the mingw-w64 CRT headers behave 
between msvcrt and UCRT mode; in one mode, some functions may be inlined 
or directed towards a symbol with one name, and towards one with another 
name in the other mode. (If you strike that, you get a fairly visible 
linking error.) Worse, some structs have different layout, and there are 
other ABI differences (for the UCRT mode, we decided to modernize things 
with defaulting to a 64 bit time_t in 32 bit mode).


The only really safe way of doing this, is picking one as default and 
bootstrap the whole toolchain with that, and then having separate 
toolchains targeting ucrt or msvcrt. (In msys2, the mingw64 environment is 
gcc-based targeting msvcrt, while the ucrt64 environment is gcc-based 
targeting ucrt).


Switching with those flags works, as long as you're building a C-only 
executable and linking libgcc statically (and not linking in any static 
libraries that were built for another CRT). I'm pretty sure that libstdc++ 
touches lots of the things that have a differing ABI. A shared linked 
libgcc will use the CRT that the toolchain was built with - although I'm 
not sure if libgcc shares any CRT objects across the DLL boundary (whether 
it is a real issue or just messy).


So TL;DR, pretend that flag doesn't exist in GCC, and just use a toolchain 
that was bootstrapped for the desired CRT. (The flag is more useful for 
switching between older variants of the MSVC CRTs that have less hairy ABI 
differences.)


// Martin

--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] MinGW with UCRT and Qt

[Martin Storsjö]

On Thu, 10 Feb 2022, Björn Schäpers wrote:


Am 10.02.2022 um 05:06 schrieb Thiago Macieira:

On Wednesday, 9 February 2022 16:35:00 PST Björn Schäpers wrote:


What would be the best way for that? I don't think you want a #if
defined(Q_CC_MSVC) || defined(_UCRT), or do you?

No, an #ifdef _UCRT should suffice.


I'm not sure I understood correctly. Should there only be an #ifdef _UCRT? 
Does 
MSVC also define that? I couldn't find anything that suggests that.


It's not MSVC itself that defines _UCRT, but their headers do - 
vcruntime.h defines it. So yes, checking for _UCRT should be enough for 
detecting such a CRT for both MSVC and mingw, in general.


(For other features that are new in UCRT, there's no guarantee that all of 
them are hooked up in mingw-w64 headers yet though.)



  Are there any plans to adapt to UCRT MinGW?
Once it's officially supported by upstream, with default toolchain builds, 

we

should switch.

What is upstream in this case? As far as I can see in msys2 they're heavy 
working on getting everything (64 bit) to UCRT.


Indeed, official releases regarding mingw-w64 toolchains is a very fuzzy 
area.


mingw-w64 only formally is distributed as source. There used to be 
someone's binary toolchain builds that were uploaded on sourceforge in the 
mingw-w64 project (in a "personal builds" folder) that often were seen as 
the official ones, but those builds stopped when that person stopped 
producing them (around GCC 8 I think?).


But there's really no single canonical build of it, mingw-w64 is a source 
distribution that anyone can configure/bundle/build as they like.


(Those releases also were mainly labelled by the GCC version included, 
which often is mistaken as the mingw-w64 version - which makes things much 
more confusing when declaring what version of mingw-w64 has complete 
enough headers for feature X or Y.)


IIRC Cristian Adam also has forked this and is producing new similar 
builds, at https://github.com/cristianadam/mingw-builds/releases. (I don't 
think those are available configured with UCRT though.)


// Martin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] MinGW with UCRT and Qt

[Martin Storsjö]

On Thu, 10 Feb 2022, Björn Schäpers wrote:

I'm upgrading my build environment and switched my MinGW GCC from MSVCRT to 
UCRT. I'm not very far in compiling Qt, but get the following warnings:


qdatetime.cpp:2372:35: warning: 'tzname' is deprecated: Only provided for 
source 
compatibility; this variable might not always be accurate when linking to 
UCRT. 
[-Wdeprecated-declarations]

return QString::fromLocal8Bit(tzname[isDst]);

It seems to me that we should use the #if defined(Q_CC_MSVC) path.

What would be the best way for that? I don't think you want a #if 
defined(Q_CC_MSVC) || defined(_UCRT), or do you? Are there any plans to adapt 
to 
UCRT MinGW?


FWIW, the Qt CI does run one mingw toolchain with UCRT (and LLVM instead 
of GCC), and AFAIK it does pass all the tests, so the setup in itself 
shouldn't have any bigger issues. (See e.g. 
https://codereview.qt-project.org/c/qt/qt5/+/394979 for one commit 
updating that tool configuration.)


That said, there's probably still some things that could be done better, 
like this use of 'tzname'.


// Martin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing to move deploy tools to qtbase

[Martin Storsjö]

On Thu, 25 Nov 2021, Thiago Macieira wrote:


On Thursday, 25 November 2021 11:57:01 PST Martin Storsjö wrote:

On Thu, 25 Nov 2021, Thiago Macieira wrote:
It is possible (although not very common) to do cross compilation to macOS
- I maintain such a setup at https://github.com/mstorsjo/xcode-cross
(based on repos where Thomas Pöchtrager maintain patched versions of
cctools and ld64).


Interesting I'll take a look.


FWIW, for cross compiling Qt 5, I set it up by setting a bunch of 
QMAKE_MAC_* variables to configure - but the basic gist of it is that you 
have e.g. "x86_64-apple-darwin-clang++" (or -g++ which does the same) 
which you can use basically like a regular target-triple-prefixed cross 
gcc.


Do you by any chance have a working icecream/iceccd compiler package? I have 
200 job slots for Linux, for Windows, and for FreeBSD, but only 12 for Mac 
(one 6-core Mac Mini).


Sorry, no, I haven't used such setups at all.


Cross compiling still requires a SDK root from Xcode (which afaik isn't
redistributable), so my setup requires copying and stripping it down from
a real Xcode install. (There are repos on github that provide the bare
sysroots though, although I'm wouldn't bet on whether one can consider
them redistributable like that - I haven't integrated scripts for making
use of that.)


Well, I have a Mac Mini, so I have the sysroot. I can package it like I did 
for FreeBSD. But I'm more interested in the icecream setup, which doesn't 
require sysroot since everything is preprocessed on the host.



> I don't know if lld is a good replacement.

These days (last 6-12 months roughly) lld has become pretty mature for
targeting macOS for x86_64 and aarch64 (AFAIK current release versions of
Chrome are built with it), but I haven't tried hooking it up in my setups.


I think Chrome uses the standard Clang too, not Apple's fork.


Yes, I'd think so too.

// Martin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing to move deploy tools to qtbase

[Martin Storsjö]

On Thu, 25 Nov 2021, Thiago Macieira wrote:


macdeployqt is less of an issue because there's no good toolchain for cross-
compiling to a Mac. Apple does not provide the sources for their ld64 linker, 
for example.


They do provide sources for it, see e.g. 
https://opensource.apple.com/source/ld64/.


It is possible (although not very common) to do cross compilation to macOS 
- I maintain such a setup at https://github.com/mstorsjo/xcode-cross 
(based on repos where Thomas Pöchtrager maintain patched versions of 
cctools and ld64).


Cross compiling still requires a SDK root from Xcode (which afaik isn't 
redistributable), so my setup requires copying and stripping it down from 
a real Xcode install. (There are repos on github that provide the bare 
sysroots though, although I'm wouldn't bet on whether one can consider 
them redistributable like that - I haven't integrated scripts for making 
use of that.)


With this setup, I've successfully cross compiled at least Qt 5.x (I 
haven't tried with 6.x though). But I haven't used the qttools repo or the 
macdeployqt tool.



I don't know if lld is a good replacement.


These days (last 6-12 months roughly) lld has become pretty mature for 
targeting macOS for x86_64 and aarch64 (AFAIK current release versions of 
Chrome are built with it), but I haven't tried hooking it up in my setups.


Besides, they fork LLVM at an arbitrary point in the branch and may 
patch it.


Yup. Apple's opensource releases usually lag 6-12 months behind their 
latest versions of Xcode, but it's not usually very important to have an 
exact match of the tools. (My cross compilation setup even uses vanilla 
llvm.org Clang instead of Apple'e version, and that works fine for the 
cases I've built so far.)


// Martin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] download.qt.io still missing some files?

[Martin Storsjö]

Hi,

On Fri, 19 Feb 2021, Martin Storsjö wrote:

I see that most of what used to be on download.qt.io has been reinstated. Is 
there still some progress ongoing in restoring files, or is the restoration 
considered complete?


E.g. under https://download.qt.io/archive/qt/4.8/, there's only 4.8.0 up to 
4.8.4, but missing 4.8.5, 4.8.6 and 4.8.7. If these are missing, what other 
bits are randomly missing elsewhere?


Are there any news regarding whether the restoration is final, or whether 
older releases actually are going to be restored?


// Martin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] download.qt.io still missing some files?

[Martin Storsjö]

Hi,

I see that most of what used to be on download.qt.io has been reinstated. 
Is there still some progress ongoing in restoring files, or is the 
restoration considered complete?


E.g. under https://download.qt.io/archive/qt/4.8/, there's only 4.8.0 up 
to 4.8.4, but missing 4.8.5, 4.8.6 and 4.8.7. If these are missing, what 
other bits are randomly missing elsewhere?


// Martin

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development