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.

Sign up for GitHub

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

Remove dependency on libgcc-dw2-1.dll from win32 executables. #29177

Merged
merged 10 commits into from
Nov 1, 2015
Merged

Remove dependency on libgcc-dw2-1.dll from win32 executables. #29177

Changes from 1 commit
Commits
Show all changes
10 commits
Select commit Hold shift + click to select a range
1da4662
Revisit implementation of custom unwind resume;
vadimcn Oct 18, 2015
def917a
Implement `eh_unwind_resume` in libstd.
vadimcn Oct 18, 2015
c807ff3
Create entry points for unwind frame registry in libstd.
vadimcn Oct 18, 2015
bd0cf1b
Don't use GCC's startup objects (crtbegin.o/crtend.o); build and use …
vadimcn Oct 18, 2015
adce670
Fix up tests and docs.
vadimcn Oct 18, 2015
145b843
Use `cfg_attr` for switching `link` attrs in libunwind.
vadimcn Oct 18, 2015
9a71c5c
Use `gcc -print-file-name` for finding C runtime startup objects:
vadimcn Oct 21, 2015
d710f8b
Moar comments.
vadimcn Oct 21, 2015
afc3046
Drop `advapi32` and `shell32` from late_link_args.
vadimcn Oct 23, 2015
0332ee9
Fix stage0 ICE caused by the old _Unwind_Resume override trickery.
vadimcn Nov 1, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Use cfg_attr for switching link attrs in libunwind.
  • Loading branch information
@vadimcn
vadimcn committed Oct 20, 2015
commit 145b8438fe19b81d964b60132eeeb6c95e8646e9
50 changes: 17 additions & 33 deletions src/libstd/sys/common/libunwind.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -99,39 +99,23 @@ pub type _Unwind_Exception_Cleanup_Fn =
extern "C" fn(unwind_code: _Unwind_Reason_Code,
exception: *mut _Unwind_Exception);

#[cfg(any(all(target_os = "linux", not(target_env = "musl")),
target_os = "freebsd"))]
#[link(name = "gcc_s")]
extern {}

#[cfg(all(target_os = "linux", target_env = "musl", not(test)))]
#[link(name = "unwind", kind = "static")]
extern {}

#[cfg(any(target_os = "android", target_os = "openbsd"))]
#[link(name = "gcc")]
extern {}

#[cfg(all(target_os = "netbsd", not(target_vendor = "rumprun")))]
#[link(name = "gcc")]
extern {}

#[cfg(all(target_os = "netbsd", target_vendor = "rumprun"))]
#[link(name = "unwind")]
extern {}

#[cfg(target_os = "dragonfly")]
#[link(name = "gcc_pic")]
extern {}

#[cfg(target_os = "bitrig")]
#[link(name = "c++abi")]
extern {}

#[cfg(all(target_os = "windows", target_env="gnu"))]
#[link(name = "gcc_eh")]
extern {}

#[cfg_attr(any(all(target_os = "linux", not(target_env = "musl")),
target_os = "freebsd"),
link(name = "gcc_s"))]
#[cfg_attr(all(target_os = "linux", target_env = "musl", not(test)),
link(name = "unwind", kind = "static"))]
#[cfg_attr(any(target_os = "android", target_os = "openbsd"),
link(name = "gcc"))]
#[cfg_attr(all(target_os = "netbsd", not(target_vendor = "rumprun")),
link(name = "gcc"))]
#[cfg_attr(all(target_os = "netbsd", target_vendor = "rumprun"),
link(name = "unwind"))]
#[cfg_attr(target_os = "dragonfly",
link(name = "gcc_pic"))]
#[cfg_attr(target_os = "bitrig",
link(name = "c++abi"))]
#[cfg_attr(all(target_os = "windows", target_env="gnu"),
link(name = "gcc_eh"))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So just to clarify gcc_eh is a static library which contains all these unwinding functions? We were just previously linking to the dynamic version and using those instead?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Er actually... let me rephrase, can you clarify what gcc_eh is?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, gcc_eh exports all those _Unwind_XXX functions. The dynamic version of libgcc, is actually a bundle of libgcc.a and libgcc_eh.a.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah ok, so I know that with MinGW you can sometimes get seh, dwarf, or sjlj exceptions, so does that matter here? For example I think we're basically only compatible with the dwarf strategy on 32-bit and seh on 64 (right?) and is gcc_eh just whatever the installation happens to be? Or is it guaranteed to always be the one we use?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, gcc_eh depends on the flavor of gcc installed. If it's the sjlj one, we'll just fail to link, I think.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah and as one final clarification, after talking with @brson, so this means that we are statically linking the unwinding support into the standard library? If so, should this be kind = "static"? Also if so, we may want to checkup on the licenses to ensure that we're covered to statically link this code from gcc (we probably are though)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If so, should this be kind = "static"?

It probably should. However this doesn't work right now, because it's in the system libs directory, which rustc is not aware of, so it fails to find it.

Also if so, we may want to checkup on the licenses to ensure that we're covered to statically link this code from gcc (we probably are though)

Yes, I believe so. libgcc_eh is covered by the linking exception.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If so, should this be kind = "static"?

It probably should. However this doesn't work right now, because it's in the system libs directory, which rustc is not aware of, so it fails to find it.

This is the same issue that I've been complaining about with getting dllimport fixed.

extern "C" {
// iOS on armv7 uses SjLj exceptions and requires to link
// against corresponding routine (..._SjLj_...)
Expand Down