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

win: precompile=yes #17179

Merged
merged 4 commits into from
Jul 3, 2016
Merged

win: precompile=yes #17179

merged 4 commits into from
Jul 3, 2016

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Jun 29, 2016

This should be the last item for making the sys.dll image reliable on x86_64. I didn't test x86, so for all I know, it's probably been doing just fine with --precompile=yes (since the OS is less demanding).

(Personality is a technical term ≠ Personification)

also fix the test for this to actually test for this,
instead of injecting a non-default build configuration
in order to test for something that bootstrapping is already testing

fix #16953
@tkelman
Copy link
Contributor

tkelman commented Jun 29, 2016

it's probably been doing just fine

It has not, it's missing type info. This would be a regression in backtrace quality on win32 which is still somewhat widely used.

@@ -278,8 +278,7 @@ static LONG WINAPI exception_handler(struct _EXCEPTION_POINTERS *ExceptionInfo)
}

#if defined(_CPU_X86_64_)
EXCEPTION_DISPOSITION _seh_exception_handler(PEXCEPTION_RECORD ExceptionRecord, void *EstablisherFrame, PCONTEXT ContextRecord, void *DispatcherContext)
{
JL_DLLEXPORT EXCEPTION_DISPOSITION __julia_personality(PEXCEPTION_RECORD ExceptionRecord, void *EstablisherFrame, PCONTEXT ContextRecord, void *DispatcherContext) {
Copy link
Contributor

Choose a reason for hiding this comment

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

this should be wrapped

@vtjnash
Copy link
Member Author

vtjnash commented Jun 29, 2016

This would be a regression in backtrace quality on win32 which is still somewhat widely used.

technically this isn't a regression, since it's a new feature introduced in the current development cycle

@@ -56,7 +56,6 @@ notifications:
- http://julia.mit.edu:8000/travis-hook
before_install:
- make check-whitespace
- JULIA_SYSIMG_BUILD_FLAGS="--output-ji ../usr/lib/julia/sys.ji"
Copy link
Contributor

@tkelman tkelman Jun 29, 2016

Choose a reason for hiding this comment

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

bootstrapping is NOT testing the case where you have a [sys.]ji file but not a dll file, which systems without linkers need to continue testing

and I added a separate test of --precompiled=no in cmdlineargs, these are testing separate things

changes to tests and CI configuration really do not belong in the same commit as changing the default value here

Copy link
Member Author

Choose a reason for hiding this comment

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

bootstrapping is NOT testing the case where you have a ji file but not a dll file

that's exactly what bootstrapping tests.

which systems without linkers need to continue testing

now that's just a red herring, since this is make, we just ran the linker

changes to tests and CI configuration really do not belong in the same commit as changing the default value here

the changes are inter-related (aside from the part where this test has severely bit-rotted)

Copy link
Contributor

Choose a reason for hiding this comment

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

bootstrapping doesn't have a sys.ji - this test is to be sure build_sysimg keeps working, where we may not have a linker

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm well aware of how bootstrapping works, and that it cycles through several names (not currently including sys.ji). The codepath that was being tested for in build_sysimg doesn't exist anymore. But forcing a non-default build configuration here has the potential to cause us to miss bugs (#16907) and is preventing me from testing other more interesting code paths (#16059).

Copy link
Contributor

Choose a reason for hiding this comment

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

Now that --precompiled=no is tested separately we wouldn't have missed #16907 locally. If this doesn't need to be deleted to add new functionality or fix the exact bug that this PR fixes, don't delete it now, in this PR. The use case of running build_sysimg from a binary without having a toolchain present certainly still exists, and should be tested. We could instead add a separate makefile target for a ji-only sys.ji output and have that build in parallel on CI if that's in any way better. Can you leave this alone for now and address it elsewhere?

Copy link
Contributor

@tkelman tkelman Jun 29, 2016

Choose a reason for hiding this comment

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

I think we're talking past each other. I don't care how it gets built, we can remove support for JULIA_SYSIMG_BUILD_FLAGS if you want (better in #16059 though, not here). As long as a no-linker .ji sys.ji file gets built somehow, separately from sys.dll is fine (parallel make to save CI time), and we test that Julia can start with it, I'm satisfied.

Copy link
Member Author

Choose a reason for hiding this comment

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

We do. It's a standard step in the build process.

Copy link
Member Author

Choose a reason for hiding this comment

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

It's also not what this test was written to test (since that's unnecessarily redundant and not quite correct). This was originally written to test the --precompile=no configuration, but was later mistakenly altered to its current form instead.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm confused - we only emit inference.ji and sys.o in a default build. I was specifically referring to sys.ji and should have spelled that out.

Copy link
Contributor

@tkelman tkelman Jun 29, 2016

Choose a reason for hiding this comment

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

Right, when the --precompiled=no configuration changed forms to being bundled inside sys.dll (and introduced as that flag) in a default build, the remaining purpose of this test was then only about the no-linker build_sysimg use case.

@nalimilan
Copy link
Member

This would be a regression in backtrace quality on win32 which is still somewhat widely used.

@tkelman Is 32-bit Windows so common among Julia users? On Linux, 32-bit seems to be very rare according to the RPM download stats. I couldn't find data regarding Windows, but for example this survey among gamers (OK, a very specific population) show very few 32-bit machines: http://store.steampowered.com/hwsurvey

@tkelman
Copy link
Contributor

tkelman commented Jun 29, 2016

32 bit OS is not so common, but downloading and using the 32 bit binaries on a 64 bit OS is still common, about a third of the win64 downloads last I checked. Will try to get more recent numbers.

@nalimilan
Copy link
Member

Maybe we should make it more obvious that 64-bit is recommended? Unless there can be bugs when interacting with other programs of course.

@tkelman
Copy link
Contributor

tkelman commented Jun 29, 2016

If you need to call into a 32 bit Python or other libraries where you might only have access to 32 bit binaries via ccall or similar, you need to use the same bitness.

- cp /tmp/julia/lib/julia/sys.ji local.ji && /tmp/julia/bin/julia -J local.ji -e 'true' &&
/tmp/julia/bin/julia-debug -J local.ji -e 'true' && rm local.ji
- /tmp/julia/bin/julia --precompiled=no -e 'true' &&
/tmp/julia/bin/julia-debug --precompiled=no -e 'true'
Copy link
Contributor

Choose a reason for hiding this comment

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

leave the indent otherwise it's not immediately obvious this is a line continuation

@Keno
Copy link
Member

Keno commented Jul 1, 2016

Cxx.jl has custom personalities on functions that it generates. Just want to make sure those don't get overriden.

@Keno
Copy link
Member

Keno commented Jul 1, 2016

Error during bootstrap after merging this:

Referencing personality function in another module!
%jl_value_t* (%jl_value_t*, i64)* @julia_getindex_3251
i32 (...)* @__julia_personality

@yuyichao yuyichao mentioned this pull request Jul 1, 2016
@kshyatt kshyatt added the system:windows Affects only Windows label Jul 1, 2016
@vtjnash
Copy link
Member Author

vtjnash commented Jul 1, 2016

Ah, of course. Will need to teach merge module about this.

@Keno
Copy link
Member

Keno commented Jul 1, 2016

Fix for the assertion failure as discussed. Breadcrumbs for issues this needed to avoid:
llvm-mirror/llvm@48f4451
llvm-mirror/llvm@fdf52d3

// Add unwind exception personalities to functions to handle async exceptions
assert(!juliapersonality_func || juliapersonality_func->getParent() == shadow_output);
if (Function *F = dyn_cast<Function>(G))
F->setPersonalityFn(juliapersonality_func);
Copy link
Contributor

Choose a reason for hiding this comment

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

indent

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
system:windows Affects only Windows
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants