You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Commit a5012a0 disables PIE (and therefore ASLR) on OS X because it breaks profiling of C++ code. Ideally, we'd figure out a way to keep it turned on except when -prof is specified on the command line.
I believe the only way to do that (except for having two separate binaries, which I don't think we want) is to re-exec the process with the _POSIX_SPAWN_DISABLE_ASLR (256) flag set. The flag is ignored for setuid/setgid binaries so in that respect -Wl,-no_pie is superior.
While this is simple enough, lldb also works when attaching to existing process. I wonder if the image ranges reported by _dyld_get_image_header() may be used to determine ASLR shift in profiler.
I've been investigating that but it's not exactly trivial: we'd first need to teach the profiler about the VM slide for each shared object and every third-party profiling tool would have to duplicate the effort.
@bnoordhuis the reason why I ask this, is that with your patch one won't be able to start the profiler at runtime, and this is certainly desirable in some environments.
If the tooling needs to break, then we probably need to keep it -no_pie for v6, and break the things in v7. Sliding all symbols by fixed value in tools/tickprocessor.js doesn't seem to be complicated at all.
Activity
src: only disable PIE on OS X when -prof is passed
bnoordhuis commentedon Apr 29, 2016
#6468
indutny commentedon Apr 29, 2016
@bnoordhuis I wonder how lldb starts the process in such way that it is still able to resolve symbols.
bnoordhuis commentedon Apr 29, 2016
@indutny In exactly the same way as the PR. :-)
indutny commentedon Apr 29, 2016
While this is simple enough, lldb also works when attaching to existing process. I wonder if the image ranges reported by
_dyld_get_image_header()may be used to determine ASLR shift in profiler.bnoordhuis commentedon Apr 29, 2016
I've been investigating that but it's not exactly trivial: we'd first need to teach the profiler about the VM slide for each shared object and every third-party profiling tool would have to duplicate the effort.
indutny commentedon Apr 29, 2016
@bnoordhuis the reason why I ask this, is that with your patch one won't be able to start the profiler at runtime, and this is certainly desirable in some environments.
If the tooling needs to break, then we probably need to keep it
-no_piefor v6, and break the things in v7. Sliding all symbols by fixed value intools/tickprocessor.jsdoesn't seem to be complicated at all.Will open an alternative PR in a bit.
indutny commentedon Apr 29, 2016
Here is my proposal: #6475
indutny commentedon Apr 29, 2016
It seems that #6475 works too, so we have to decide what is the best for us. Would love to hear @nodejs/ctc opinion on this.
jasnell commentedon Apr 29, 2016
@indutny ... to be honest, I'd trust you and @bnoordhuis most to make the decision on this. Whichever approach you each feel is right, works for me.
indutny commentedon Apr 29, 2016
@bnoordhuis how do you feel about Sumo fight?
[prof] export slide offset in profile log
deps: cherry-pick aee17a6 from v8
jasnell commentedon Jul 6, 2016
@indutny @bnoordhuis ... ping
indutny commentedon Jul 6, 2016
pong
bnoordhuis commentedon Jul 6, 2016
This PR can be closed (and that's what I'll do.) I'll post a follow-up question in #6558.