cleanup julia_init options

[vtjnash]

this attempts to be more consistent and centralized about initializing julia paths (build_path, image_file, julia_home). this is in an attempt to make embedding julia easier. also, it should help with spawning child processes (by providing more reliable access to the parameters, without dependence of the working directory)

1. moves all configuration options into jl_compileropts
2. computes the abspath/realpath of file paths in the config to avoid issues with chdir causing files to end up in the wrong location

@tkelman @ihnorton @staticfloat

[StefanKarpinski]

💯

[staticfloat]

I like this. +1

[JeffBezanson]

Is this change related?

[vtjnash]

I moved this line to be with the rest of the signal handlers (https://github.com/JuliaLang/julia/pull/9266/files#diff-885908120835b66f90958a39baeb2018R1073). i think that should be more consistent with what these functions are intended to do (and hence falls in line with "cleanup of julia init")

[vtjnash]

@JeffBezanson these latests commits add a few more initialization-related cleanup items (also driven by #8745-related work)

[tkelman]

This should probably be #if (defined(_CPU_X86_64_) || defined(_CPU_X86_)) && !defined(_MSC_VER) since inline assembly doesn't appear to be supported in MSVC for 64 bit

Also note the appveyor failure with mingw64, I'll see if I can reproduce that locally when I get a chance.

[vtjnash]

that's incredibly annoying.

at some point, someone will have to copy the ASM instructions to a MASM file, but for now, that's why I left the option here (plus I don't have an ARM computer to test on)

[JeffBezanson]

The embedding docs should be updated; they mention JL_SET_STACK_BASE.

[JeffBezanson]

Might as well git rid of this while you're at it?

[vtjnash]

will do. the diff in that other issue was actually against this branch, i just didn't want to include it if it wasn't correct (something about Jeff not wanting to have too many different changes happening in the same PR...)

[JeffBezanson]

This PR already entirely replaces the relevant code so it's kind of moot.

[vtjnash]

i think that addresses all comments thus far

[JeffBezanson]

Could you add a comment that describes what this function does? And that it operates by reading and writing jl_compileropts.

[tkelman]

This is broken on Win64! Debug builds don't work, and it segfaults in the tests. Can we pay attention to the statuses here?

[vtjnash]

agreed. i'm currently trying to look into why that win64 build is consistently failing

[JeffBezanson]

Sorry. Will it be a quick fix or should I revert?

[tkelman]

Not sure on the test issue. It's a MemoryError on the most recent appveyor builds but a segfault locally. The debug build fails with

    LINK usr/bin/julia-debug.exe
d000001.o:(.idata$5+0x0): multiple definition of `__imp___stack_chk_guard'
/usr/lib/gcc/x86_64-w64-mingw32/4.8/libssp.dll.a(d000008.o):(.idata$5+0x0): first defined here
d000001.o:(.idata$6+0x0): multiple definition of `__nm___stack_chk_guard'
/usr/lib/gcc/x86_64-w64-mingw32/4.8/libssp.dll.a(d000008.o):(.idata$6+0x0): first defined here
collect2: error: ld returned 1 exit status
make[2]: *** [/home/tkelman/Julia/julia-win64-seh/usr/bin/julia-debug.exe] Error 1
make[1]: *** [julia-debug] Error 2
make: *** [debug] Error 2

so I think stack_chk_guard will need to use a different name.

[vtjnash]

no, i can fix it quick. i'm just being too exact about the amount of stack I'm copying

on linux and win32, %RSP points to the top of the function stack frame

on win64, %RSP points to the top of the stack frame, but there's a spill area above that equal to max(4*sizeof(void*), stack space required for pushing all arguments to the function) which must be accounted for. ref http://msdn.microsoft.com/en-us/library/ew5tede7.aspx

[vtjnash]

__stack_chk_guard is a magic variable name that is understood and special cased by the compiler/linker. but I can work around that