Hi, > Avoiding to make it a hard dependency would be a good idea. Also, > libunwind is a hack that showed problems when vmprof previously > supported C frames, and it was removed for that reason. Maybe you > should give a word about why re-enabling C frames with libunwind looks > ok now?
Can you elaborate on that? My understanding is that Maciej at some point complained that there are some issues and removed that feature (which Antonio was not particularly happy about). I never learned the issues. One complaint I remember (should be on IRC logs some place): It was along the lines: "... some times libunwind returns garbage ..." Speaking from my experience during the development: I have not seen a C stack trace that is totally implausible (even though I thought so, but I turned out to be some other error). It was very hard to get the trampoline right and it was also not easy to get the stack walking right (considering it should work for all platform combinations). There are several cases where libunwind could say: 'hey, unsure what to do, cannot rebuild the stack' and those cases now lead to skipping the sample in the signal. I'm happy to accept the fact that 'libunwind is garbage/hack/...' if somebody proves that. So if anyone has some insight on that, please speak up. There are alternatives like: use libbacktrace from gcc (which is already included in vmprof now). Cheers, Richard _______________________________________________ pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev
