freenode/#sbcl - IRC Chatlog
Search
15:49:57
dougk_
borodust: if you're using x86-64, look in the file src/code/aprof.lisp for instructions on how to enable allocation profiling. aprof will tell you exactly what functions are consing what objects
22:37:15
dougk_
fitzsim: the changes for abi version 2 are much more involved than just changing that section name. Most of the hand-generated assembly needs to change, as does call_into_lisp and call_into_c
22:45:10
dougk_
i'm not so concerned with where to put. I think I need to assume ABI version 1 is for big-endian and ABI version 2 for little-endian. If we actually have to be sensitive to the value of #define _CALL_ELF, that's not so great. We could only do it from the .S file
22:46:56
dougk_
true but I'm hoping that v2 is the future. The manual says regarding v1 "This ABI is currently only used for big-endian". The only big-endian machine I have seems to use v1. So if we assume that's invariant, then little-endian can only possibly use v2
22:48:04
dougk_
the essential difference is that function pointers are actually pointers to code in v2, but in v1 they are pointers to data which points to code
22:52:16
dougk_
along these lines I want to eliminate ldso-stubs, using it nothing more than an anchor for all C functions that we currently need. So the whole file will just be '.long _ext, accept, access, acos, acosh'. Etc. We can rely on sb-dynamic-core to actually create the lisp->c links.
22:53:18
dougk_
i suspect that soon after after #+linkage-table came along, ldso-stubs was probably soon thereafter irrelevant.
22:55:17
dougk_
like I agree that if you don't force the C linker that you are going to use some C symbol, it may not make it accessible in dlsym() depending on what components of your libc are truly statically linked, but as long as we use dlsym() at all, we don't need the extra layer of writing stubs when we can just look up the thing we're trying to look up
22:56:25
dougk_
the next interesting port would be convert IR1 to C and making a truly portable backend. So the elbrus person can have his SBCL. There's no way anyone's writing an instruction bundler add-on to our assembler for VLIW instructions
22:57:52
dougk_
yes, agree it will be slower. I think we can do the same thing that memory-pool system does: allow ambiguous interior pointers to pin objects.
22:58:17
dougk_
So as long as the C compiler produces code that doesn't "completely" discard a pointer to an object, it can stay alive
1:01:53
fitzsim
dougk_: from what I've heard in #talos-workstation, it's fine to assume that ppc64le is exclusively ABI version 2, but ppc64 big endian is ABI version 1 on some systems for backward compatibility, and ABI version 2 on some systems to match the now-more-common ppc64le
1:03:06
fitzsim
dougk_: so it would be nice to have SBCL support building for ppc64 (big endian), ABI version 1 or 2 (though I don't know if that'd make a lot of extra work)