Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rust, Windows, and MSVC #1061

Closed
20 of 47 tasks
retep998 opened this issue Apr 13, 2015 · 96 comments
Closed
20 of 47 tasks

Rust, Windows, and MSVC #1061

retep998 opened this issue Apr 13, 2015 · 96 comments
Labels
T-dev-tools Relevant to the development tools team, which will review and decide on the RFC.

Comments

@retep998
Copy link
Member

retep998 commented Apr 13, 2015

High priority tasks

Lower priority tasks

Completed tasks

Wishlist

Related links

rust-lang/rust#1768

@retep998
Copy link
Member Author

cc @brson @ricky26 @vadimcn

@retep998 retep998 changed the title Support MSVC toolchain on Windows Rust, Windows, and MSVC Apr 17, 2015
@brson
Copy link
Contributor

brson commented Apr 17, 2015

Thanks @retep998. This is going to be a big focus this year and we need to get clear on what the goals are.

@Manishearth
Copy link
Member

cc me

@alexchandel
Copy link

The best solution for msvcrt.dll may be to statically link a CRT.

@Diggsey
Copy link
Contributor

Diggsey commented May 4, 2015

Why does rust require a CRT at all on windows? It's rust not C, it can (and AFAIK, does in most places) just call windows APIs directly?

Also, which license prevents open source projects from using the redistributable msvcrt.dlls?

@retep998
Copy link
Member Author

retep998 commented May 4, 2015

@Diggsey GPL does not allow you to link GPL code with proprietary code, unless it is a system library in which case there is an exception for that. Since there's no GPL compatible CRTs on Windows, this means the only option for such software is to link dynamically to the system msvcrt.dll which is a system library and thus falls under the exception. Even though Rust is not C, if it statically links to any C code that relies on the CRT, like jemalloc, then it needs to link to the CRT and use the CRT entry points.

@Diggsey
Copy link
Contributor

Diggsey commented May 4, 2015

@retep998 Thanks for the explanation, although after doing some reading, it seems that the "system library" exception explicitly includes compiler runtimes, from the GPL:

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

And apparantly other people are interpretting it this way:
http://lists.gnu.org/archive/html/bug-gnu-utils/2004-01/msg00124.html

So as long as you aren't actually distributing msvcrt.dll you could still be GPL compatible.

Since the redistributable can be freely downloaded from the microsoft site, it should be possible to prompt the user to install that first as part of any install process?

@retep998
Copy link
Member Author

retep998 commented May 4, 2015

@Diggsey Given that, then we should at least be able to use other versions of the CRT so long as we link dynamically.
I'd still like to have the option to statically link to the CRT for software that isn't tied down by GPL though.

@vadimcn
Copy link
Contributor

vadimcn commented May 4, 2015

I am getting very confused here... What does msvcrt.dll have to do with GPL??

@retep998
Copy link
Member Author

retep998 commented May 4, 2015

@vadimcn GPL forbids distribution of software that falls under GPL if it has any components which are not GPL-compatible, unless they are system libraries which are not distributed with the software. Which means GPL software has to be dynamically linked to msvcrt and cannot be distributed with the CRT redistributable.

@Diggsey
Copy link
Contributor

Diggsey commented May 4, 2015

@vadimcn Programs built using VC++ link to msvcrt.dll for their C runtime library, which is the "correct" runtime library to use for new programs: because it's versioned it means microsoft can release new versions without breaking all existing programs.

However, programs built using the mingw toolchain link to msvcrt.dll, which is unversioned and only exists for backwards compatibility reasons. The reason is that msvcrt.dll comes preinstalled on all windows machines, whereas versioned crts must be installed separately, and the GPL prohibits you from distributing the proprietary msvcrt.dll with GPL software.

Ideally there would be an open source C runtime for windows which would solve all the problems, but AFAIK that doesn't exist.

@vadimcn
Copy link
Contributor

vadimcn commented May 4, 2015

@retep998: I kinda doubt that's the reason. All GCC libs, that Rust binaries are linked with, are covered by the GCC runtime library linking exception.
Edit: And I think the same goes for a lot of c++ programs compiled with GCC.

@retep998
Copy link
Member Author

retep998 commented May 4, 2015

@vadimcn The problem is not the GCC libraries we use, but rather if someone wants to build GPL software on Windows using Rust.

@gkoz
Copy link

gkoz commented May 4, 2015

@retep998

GPL forbids distribution of software that falls under GPL if it has any components which are not GPL-compatible, unless they are system libraries which are not distributed with the software.

Where does it make any distinction about whether you distribute the "system libraries"?

@kini
Copy link

kini commented May 4, 2015

IIRC in this context the term "system library" is just conservatively interpreted to mean "library that is so prevalent on systems that it need not be shipped", so shipping a library might cause it to be viewed as not being a "system library" and therefore not subject to the exemption.

@gkoz
Copy link

gkoz commented May 4, 2015

I can see it in the GPLv2 now. So discussing the GPL isn't very meaningful without specifying its version it seems... The language there is a bit ambiguous (is the second "component" the same as the first?):

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

@alexchandel
Copy link

@retep998 Just to be clear, it is jemalloc that drags in the msvcrt dependency?

@Manishearth
Copy link
Member

Perhaps we should break the issue into chunks? I believe jemalloc can be disabled, so we can try to get a working version of MSVC Rust sans jemalloc and debuginfo, then go on to jemalloc, then debuginfo.

@ricky26
Copy link

ricky26 commented May 5, 2015

From a technical point of view I managed to build a rust program into an exe using link.exe and the MSVC toolchain in LLVM (it's a hack, but it's in my branch listed above) - there were a couple of things I didn't expect going in:

  • The build system needs some serious adaptation to support MSVC - my hacked branch still uses a compiler built with MinGW which uses the LLVM toolchain in MSVC mode (which is more than a little convoluted, but not too detrimental to an end user). At the moment I've been compiling the bits of the rust runtime with cl.exe on the command-line by hand.
  • The exception handling support for LLVMxMSVC at the moment results in calls to libunwind-style personality functions - I think ldc has a hack for this which involves walking the DWARF exception records manually at runtime and then dispatching via Win32 exception handling but I've not had any luck (or much time) getting it working in my hacked branch.

@retep998
Copy link
Member Author

In VS 2015, the CRT is being refactored into a VC runtime and a Universal CRT.
http://blogs.msdn.com/b/vcblog/archive/2015/03/03/introducing-the-universal-crt.aspx

@abonander
Copy link

I have already found a need for integration with Windows resource scripts. When creating executables that link to Common Controls, it's necessary to create a manifest file that tells what version of the comctl32.dll assembly to load. This can be done manually, but it would be a lot more convenient to automate it with a resource script. However, it may be a more appropriate feature for Cargo than the Rust compiler itself.

Also, it would be nice to be able to add icon files directly to executables in Windows, which I believe is facilitated by resource scripts as well.

@alexcrichton alexcrichton added the T-dev-tools Relevant to the development tools team, which will review and decide on the RFC. label May 18, 2015
bors added a commit to rust-lang/rust that referenced this issue May 20, 2015
Special thanks to @retep998 for the [excellent writeup](rust-lang/rfcs#1061) of tasks to be done and @ricky26 for initially blazing the trail here!

# MSVC Support

This goal of this series of commits is to add MSVC support to the Rust compiler
and build system, allowing it more easily interoperate with Visual Studio
installations and native libraries compiled outside of MinGW.

The tl;dr; of this change is that there is a new target of the compiler,
`x86_64-pc-windows-msvc`, which will not interact with the MinGW toolchain at
all and will instead use `link.exe` to assemble output artifacts.

## Why try to use MSVC?

With today's Rust distribution, when you install a compiler on Windows you also
install `gcc.exe` and a number of supporting libraries by default (this can be
opted out of). This allows installations to remain independent of MinGW
installations, but it still generally requires native code to be linked with
MinGW instead of MSVC. Some more background can also be found in #1768 about the
incompatibilities between MinGW and MSVC.

Overall the current installation strategy is quite nice so long as you don't
interact with native code, but once you do the usage of a MinGW-based `gcc.exe`
starts to get quite painful.

Relying on a nonstandard Windows toolchain has also been a long-standing "code
smell" of Rust and has been slated for remedy for quite some time now. Using a
standard toolchain is a great motivational factor for improving the
interoperability of Rust code with the native system.

## What does it mean to use MSVC?

"Using MSVC" can be a bit of a nebulous concept, but this PR defines it as:

* The build system for Rust will build as much code as possible with the MSVC
  compiler, `cl.exe`.
* The build system will use native MSVC tools for managing archives.
* The compiler will link all output with `link.exe` instead of `gcc.exe`.

None of these are currently implemented today, but all are required for the
compiler to fluently interoperate with MSVC.

## How does this all work?

At the highest level, this PR adds a new target triple to the Rust compiler:

    x86_64-pc-windows-msvc

All logic for using MSVC or not is scoped within this triple and code can
conditionally build for MSVC or MinGW via:

    #[cfg(target_env = "msvc")]

It is expected that auto builders will be set up for MSVC-based compiles in
addition to the existing MinGW-based compiles, and we will likely soon start
shipping MSVC nightlies where `x86_64-pc-windows-msvc` is the host target triple
of the compiler.

# Summary of changes

Here I'll explain at a high level what many of the changes made were targeted
at, but many more details can be found in the commits themselves. Many thanks to
@retep998 for the excellent writeup in rust-lang/rfcs#1061 and @RicK26 for a lot
of the initial proof-of-concept work!

## Build system changes

As is probably expected, a large chunk of this PR is changes to Rust's build
system to build with MSVC. At a high level **it is an explicit non goal** to
enable building outside of a MinGW shell, instead all Makefile infrastructure we
have today is retrofitted with support to use MSVC instead of the standard MSVC
toolchain. Some of the high-level changes are:

* The configure script now detects when MSVC is being targeted and adds a number
  of additional requirements about the build environment:
  * The `--msvc-root` option must be specified or `cl.exe` must be in PATH to
    discover where MSVC is installed. The compiler in use is also required to
    target x86_64.
  * Once the MSVC root is known, the INCLUDE/LIB environment variables are
    scraped so they can be reexported by the build system.
  * CMake is required to build LLVM with MSVC (and LLVM is also configured with
    CMake instead of the normal configure script).
  * jemalloc is currently unconditionally disabled for MSVC targets as jemalloc
    isn't a hard requirement and I don't know how to build it with MSVC.
* Invocations of a C and/or C++ compiler are now abstracted behind macros to
  appropriately call the underlying compiler with the correct format of
  arguments, for example there is now a macro for "assemble an archive from
  objects" instead of hard-coded invocations of `$(AR) crus liboutput.a ...`
* The output filenames for standard libraries such as morestack/compiler-rt are
  now "more correct" on windows as they are shipped as `foo.lib` instead of
  `libfoo.a`.
* Rust targets can now depend on native tools provided by LLVM, and as you'll
  see in the commits the entire MSVC target depends on `llvm-ar.exe`.
* Support for custom arbitrary makefile dependencies of Rust targets has been
  added. The MSVC target for `rustc_llvm` currently requires a custom `.DEF`
  file to be passed to the linker to get further linkages to complete.

## Compiler changes

The modifications made to the compiler have so far largely been minor tweaks
here and there, mostly just adding a layer of abstraction over whether MSVC or a
GNU-like linker is being used. At a high-level these changes are:

* The section name for metadata storage in dynamic libraries is called `.rustc`
  for MSVC-based platorms as section names cannot contain more than 8
  characters.
* The implementation of `rustc_back::Archive` was refactored, but the
  functionality has remained the same.
* Targets can now specify the default `ar` utility to use, and for MSVC this
  defaults to `llvm-ar.exe`
* The building of the linker command in `rustc_trans::back::link` has been
  abstracted behind a trait for the same code path to be used between GNU and
  MSVC linkers.

## Standard library changes

Only a few small changes were required to the stadnard library itself, and only
for minor differences between the C runtime of msvcrt.dll and MinGW's libc.a

* Some function names for floating point functions have leading underscores, and
  some are not present at all.
* Linkage to the `advapi32` library for crypto-related functions is now
  explicit.
* Some small bits of C code here and there were fixed for compatibility with
  MSVC's cl.exe compiler.

# Future Work

This commit is not yet a 100% complete port to using MSVC as there are still
some key components missing as well as some unimplemented optimizations. This PR
is already getting large enough that I wanted to draw the line here, but here's
a list of what is not implemented in this PR, on purpose:

## Unwinding

The revision of our LLVM submodule [does not seem to implement][llvm] does not
support lowering SEH exception handling on the Windows MSVC targets, so
unwinding support is not currently implemented for the standard library (it's
lowered to an abort).

[llvm]: https://github.com/rust-lang/llvm/blob/rust-llvm-2015-02-19/lib/CodeGen/Passes.cpp#L454-L461

It looks like, however, that upstream LLVM has quite a bit more support for SEH
unwinding and landing pads than the current revision we have, so adding support
will likely just involve updating LLVM and then adding some shims of our own
here and there.

## dllimport and dllexport

An interesting part of Windows which MSVC forces our hand on (and apparently
MinGW didn't) is the usage of `dllimport` and `dllexport` attributes in LLVM IR
as well as native dependencies (in C these correspond to
`__declspec(dllimport)`).

Whenever a dynamic library is built by MSVC it must have its public interface
specified by functions tagged with `dllexport` or otherwise they're not
available to be linked against. This poses a few problems for the compiler, some
of which are somewhat fundamental, but this commit alters the compiler to attach
the `dllexport` attribute to all LLVM functions that are reachable (e.g. they're
already tagged with external linkage). This is suboptimal for a few reasons:

* If an object file will never be included in a dynamic library, there's no need
  to attach the dllexport attribute. Most object files in Rust are not destined
  to become part of a dll as binaries are statically linked by default.
* If the compiler is emitting both an rlib and a dylib, the same source object
  file is currently used but with MSVC this may be less feasible. The compiler
  may be able to get around this, but it may involve some invasive changes to
  deal with this.

The flipside of this situation is that whenever you link to a dll and you import
a function from it, the import should be tagged with `dllimport`. At this time,
however, the compiler does not emit `dllimport` for any declarations other than
constants (where it is required), which is again suboptimal for even more
reasons!

* Calling a function imported from another dll without using `dllimport` causes
  the linker/compiler to have extra overhead (one `jmp` instruction on x86) when
  calling the function.
* The same object file may be used in different circumstances, so a function may
  be imported from a dll if the object is linked into a dll, but it may be
  just linked against if linked into an rlib.
* The compiler has no knowledge about whether native functions should be tagged
  dllimport or not.

For now the compiler takes the perf hit (I do not have any numbers to this
effect) by marking very little as `dllimport` and praying the linker will take
care of everything. Fixing this problem will likely require adding a few
attributes to Rust itself (feature gated at the start) and then strongly
recommending static linkage on Windows! This may also involve shipping a
statically linked compiler on Windows instead of a dynamically linked compiler,
but these sorts of changes are pretty invasive and aren't part of this PR.

## CI integration

Thankfully we don't need to set up a new snapshot bot for the changes made here as our snapshots are freestanding already, we should be able to use the same snapshot to bootstrap both MinGW and MSVC compilers (once a new snapshot is made from these changes).

I plan on setting up a new suite of auto bots which are testing MSVC configurations for now as well, for now they'll just be bootstrapping and not running tests, but once unwinding is implemented they'll start running all tests as well and we'll eventually start gating on them as well.

---

I'd love as many eyes on this as we've got as this was one of my first interactions with MSVC and Visual Studio, so there may be glaring holes that I'm missing here and there!

cc @retep998, @ricky26, @vadimcn, @klutzy 

r? @brson
@alexcrichton
Copy link
Member

I've reorganized the description of this issue slightly and am going to be using it as a sort of metabug to track sub-bugs.

@retep998
Copy link
Member Author

Based on a binary that @alexcrichton sent me that was built using the new msvc target, it seems that the CRT is being statically linked. Considering we are explicitly linking msvcrt.lib which should be a dynamically linked CRT, something is weird.

@alexchandel
Copy link

@Diggsey That's pretty amusing. They deserve all the trouble they're enduring and more for not having included a stable C library in their os 30 years ago. It's a "code smell" to me to deliver shared objects alongside executables, especially when they're things like the standard C library, but I managed to link against the evil msvcrt.dll instead via VC6. Although I suspect that manually invoking the linker would let me statically link against the UCRT...

@Diggsey
Copy link
Contributor

Diggsey commented Oct 18, 2015

@alexchandel

They deserve all the trouble they're enduring and more for not having included a stable C library in their os 30 years ago.

Windows has always included a stable C library, the problems stem from the fact that it must maintain binary compatibility across all versions of windows, and that it combines both the compiler runtime and the language runtime in one.

The compiler runtime must, necessarily, be updated for each new version of the compiler. That means the entire runtime must be versioned according to the compiler version, so frequently you need a runtime that is newer than the version of windows on which you are running. This means you can't rely on it being pre-installed, and that is grounds for discounting it as a "core system component", which makes it incompatible with the GPL.

The UCRT solves the problem by splitting the compiler runtime and C runtime into separate DLLs, which allows the C runtime part to be the same regardless of the compiler version.

Linux doesn't have the problem only because it doesn't attempt to maintain binary compatibility for programs which rely on shared libraries: you can't just copy a program from one linux machine to another and have any guarantee of it working, unless absolutely everything is statically linked and the kernel versions match. For platforms where most software is distributed only in binary form, this obviously can't work.

@alexchandel
Copy link

@Diggsey Then it is not stable. It is an incorrect presumption that the compiler runtime "must, necessarily, be updated for each new version". I can use an (x86) crt1 Mach-O crosscompiled for OS X 10.1 with El Capitan's libSystem and a bleeding edge 3.8trunk clang with absolutely no problems whatsoever. In fact I just linked a Rust program with it.

Linux doesn't have the problem only because it doesn't attempt to maintain binary compatibility for programs which rely on shared libraries:
you can't just copy a program from one linux machine to another and have any guarantee of it working, unless Moderately everything is statically linked and the kernel versions match.

This is so false that I don't even. Linux famously does not break userspace, so kernel versions aren't generally a problem. Moreover, except for rare cases, glibc maintains backwards compatibility. As does OS X, which also guarantees libSystem compatibility, and strives for (but does not guarantee) syscall compatibility. You can play the ancient x86 build of StarCraft, linked against 10.2's libSystem.dylib, on 10.11. It actually runs better than the wine version. Obviously there is no guarantee, to use your word, if there are missing sos or if Apple decided not to ship some dylib anymore. But you are quite mistaken to assume that other platforms are as broken as Windows.

@Diggsey
Copy link
Contributor

Diggsey commented Oct 21, 2015

@alexchandel

Then it is not stable. It is an incorrect presumption that the compiler runtime "must, necessarily, be updated for each new version".

The compiler runtime is completely different from the C runtime... Obviously using an old CRT will work, that's the whole point: the CRT has a stable API, the compiler runtime does not. Windows does have a stable C runtime, because as long as you only use the C runtime parts (of any version of msvcrt) it will continue to work forever. The part that changes is the compiler runtime.

This is so false that I don't even.

Obviously there is no guarantee.

Make up your mind, either there is a guarantee or there's not. If there isn't a guarantee, than what I said is true. Windows does provide backwards compatibility guarantees, to a fault.

You seem to be missing the important distinction between should work, and does work.

@alexchandel
Copy link

@Diggsey

Make up your mind, either there is a guarantee or there's not.

If you examine the rest of that sentence, instead of cutting it out for cute rhetorical purposes like "Make up your mind", you'd see I'm referring to dylibs that are not guaranteed, unlike libSystem. libSystem is guaranteed, and does work. (And consulting Apple's dev site suggests that they don't remove dylibs after all; just the headers so new apps can't be compiled against them.) The point stands.

The compiler runtime is completely different from the C runtime...

Wrong for clang/libSystem. There are (non-MS) platforms that do not make these distinctions, and the existence of the former demonstrates that the latter should not be necessary. Binary compatibility does not have to be an issue, and distinguishing "compiler runtimes" from other stable components is meaningless or inconsequential on platforms that don't suffer from the nuanced design flaws of Windows. Not everyone is forced to accept MS's terminology, nor their justifications for instability.

And just to hammer the point home (and because you clearly misunderstood this), the functions in Apple's crt0/crt1 correspond to what MS calls the "compiler runtime", not what MS calls the "CRT" which corresponds to (part of) Apple's libSystem: I compiled an el cap binary against the current "CRT" with a HEAD compiler and a Cretaceous era "compiler runtime", because these libraries are permanently stable on non-broken platforms.

@retep998
Copy link
Member Author

It's worth noting that crt0.o is statically linked and so there's no stability concerns there. Microsoft puts some of the stuff which would typically be in crt0.o in a DLL instead, and as such that ends up having to be versioned with each compiler version. If Microsoft didn't version those bits, then they'd be forced to never change them and maintain them backwards compatibly for a very long time.
Look at these functions that are in vcruntime140.dll. Do they look like the kind of things you'd want to keep stable?

__AdjustPointer
__BuildCatchObject
__BuildCatchObjectHelper
__C_specific_handler
__C_specific_handler_noexcept
_CreateFrameInfo
__current_exception
__current_exception_context
__CxxDetectRethrow
__CxxExceptionFilter
__CxxFrameHandler
__CxxFrameHandler2
__CxxFrameHandler3
__CxxQueryExceptionSize
__CxxRegisterExceptionObject
_CxxThrowException
__CxxUnregisterExceptionObject
__DestructExceptionObject
_FindAndUnlinkFrame
__FrameUnwindFilter
_get_purecall_handler
_get_unexpected
__GetPlatformExceptionInfo
__intrinsic_setjmp
__intrinsic_setjmpex
_is_exception_typeof
_IsExceptionObjectToBeDestroyed
_local_unwind
__NLG_Dispatch2
__NLG_Return2
__processing_throw
_purecall
__report_gsfailure
__RTCastToVoid
__RTDynamicCast
__RTtypeid
_set_purecall_handler
_set_se_translator
set_unexpected
_SetWinRTOutOfMemoryExceptionCallback
__std_exception_copy
__std_exception_destroy
__std_terminate
__std_type_info_compare
__std_type_info_destroy_list
__std_type_info_hash
__std_type_info_name
__telemetry_main_invoke_trigger
__telemetry_main_return_trigger
__TypeMatch
__uncaught_exception
__uncaught_exceptions
__unDName
__unDNameEx
unexpected
__vcrt_GetModuleFileNameW
__vcrt_GetModuleHandleW
__vcrt_InitializeCriticalSectionEx
__vcrt_LoadLibraryExW

@alexchandel
Copy link

@retep998 Hah that's quite a good list. But OS X puts all of those in a DLL too. For example for the C++ exception stuff, /usr/lib/system/libunwind.dylib, which is linked behind-the-scenes by libSystem, is permanently stable, and contains similar OS X functions. Who knows how hard it is to keep it stable, but Apple does it. /usr/lib/libc++.dylib also has some exception things too. crt0.o/crt1.o have only a handful of symbols like EH_Frame1, ___keymgr_dwarf2_register_sections, func.eh, and the entry point.

Edit: But crt0.o/crt1.o are never even used on OS X. Since 10.7 it's been part of libSystem.dylib, which is dynamically linked, and executables compiled for 10.7+ simply rely on the (permanently stable) entry point in there. But even so, the fact that I can statically link against an old, pre-10.7 version of crt0.o with a different compiler and a different libSystem shows that it, too, is permanently stable.

There is simply no justifiable reason for what Microsoft did.

@brson
Copy link
Contributor

brson commented Jun 23, 2016

@retep998 What's the state of this metabug? Looks a bit stale. Can remaining items be moved to rust-lang/rust as individual bugs?

@brson brson removed the P-high label Jun 23, 2016
@brson
Copy link
Contributor

brson commented Jun 23, 2016

I went ahead and dropped the P-high tag since this bug is inactive.

@retep998
Copy link
Member Author

I do update the issue every so often. Feel free to point out anything you feel should be added or was completed and I'll update the list.

@Diggsey
Copy link
Contributor

Diggsey commented Jun 23, 2016

What's left to do re: the first wishlist item? 😜

@retep998
Copy link
Member Author

I'm not sure. I'll have to try debugging a Rust program and see how good the local variable info is.

@briansmith
Copy link

I'm not sure. I'll have to try debugging a Rust program and see how good the local variable info is.

I have noticed when debugging with MSVC's debugger, stepping into any line that uses try!(...) makes MSVC confused until you step again. It seems like it steps into the macro's code, but it does not nagivate the editor to the macro's code. Thus, debugging pretty much everything is a very confusing experience.

@alexchandel
Copy link

All of the "Remaining tasks" still appear unfinished, so presumably it's still active. Perhaps the metabug itself could be moved to rust-lang/rust.

@alexchandel
Copy link

@retep998 I've heard that the COM ABI is slightly different from the usual Win32 ABI, in ways that resulted in MSVC's C (not C++) compiler historically not being able to call it correctly. Is this true / does rustc need to do anything to support it?

@retep998
Copy link
Member Author

@alexchandel stdcall for C++ methods is slightly different than stdcall for regular functions. Since COM is based on C++ methods, that means that for some of those COM methods, the C equivalent is in fact incorrect. I already opened an issue for this #1342 which is even listed in this meta issue.

@liranringel
Copy link

Could someone elaborate in what way the quality of PDB debug info should be improved?

@gnzlbg
Copy link
Contributor

gnzlbg commented Jan 20, 2019

#2625 covers __intrinsic_setjmp .

@retep998
Copy link
Member Author

This list has stagnated for a while, and I don't think this repo is really the right place for it anyway.

A new list will be maintained the Windows WG repo: rust-windows/wg#3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-dev-tools Relevant to the development tools team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests