freenode/#clasp - IRC Chatlog
Search
19:00:51
frgo
Could you do a dladdr call immediately after the dlsym call? Just to check if a pure call to dlsym doesn't affect location?
19:01:41
drmeister
With the address passed to the first dladdr? Should I check the result or anything?
19:05:37
frgo
So dladdr(address) -> dlsym(symbolname) -> dladdr(address) then check what dl_info tells us.
19:06:34
frgo
It might be that the call to dlsym affects a dyld-internal table and we get changing info on every dlsym call.
19:12:40
frgo
A "Library" object is a clasp compiled object, not some third party library - is that right?
19:14:49
frgo
Also, I'd be curious to see what dlerror(); returns as a message when we don't get a symbol name back.
19:19:29
drmeister
https://github.com/clasp-developers/clasp/blob/future/src/gctools/imageSaveLoad.cc#L1262
19:30:14
drmeister
I mean I can call dlsym with one symbol and get an address and call with another and get NULL.
19:32:35
frgo
Yeah I see that. I was looking at dlfcn.h here: https://opensource.apple.com/source/dyld/dyld-832.7.3/include/dlfcn.h.auto.html
19:33:24
drmeister
Ok so some of these symbols are external and some are local? I'm back to that huh?
19:35:58
drmeister
I don't know why one is external and the other is not - I'm looking at more of them now...
19:40:17
drmeister
Every case that I checked - when dlsym can't resolve the name it is a 's'/local symbol
19:41:33
drmeister
But dladdr will give you the symbol whether or not it is external - and that is helpful at least.
19:42:16
drmeister
Ok - so I have to either figure out why and then make every one of these symbols external - or I need to use '-exported_symbols_list'
19:43:46
drmeister
So why would __ZTVN4core26DerivableCxxClassCreator_OE be external and __ZTVN4core13ClassHolder_OE be local?
19:46:20
drmeister
Yeah: echo __ZTVN4core26DerivableCxxClassCreator_OE | c++filt --> "vtable for core::DerivableCxxClassCreator_O"
19:46:39
drmeister
So I'll call these vtable pointers (although in memory the pointer is actually to this + 16 bytes)
19:52:43
drmeister
Huh - so far every one of these local symbols is a vtable pointer - like: _ZTVN4core15VariadicMethoidILi0ENS_6policy5claspEMN4chem19StereoInformation_OEFvvEEE
19:59:20
drmeister
I have about 9050 addresses that I need to resolve to symbols with dladdr at snapshot save time.
20:00:40
drmeister
On linux - it's not a problem. Either they are all external linkage or dlsym on linux doesn't care
20:03:52
frgo
A completely different rout on macOS may be to use the ImageLoader class -> https://opensource.apple.com/source/dyld/dyld-832.7.3/src/ImageLoader.h.auto.html
20:05:41
drmeister
Nah - I've already got this. The problem looks like a small one now - just figure out how to get these vtable pointers with external linkage.
20:13:10
frgo
So, there are vtable pointers that are exported? If so, I seem to see that you can ignore the ones that are not exported.
20:14:32
drmeister
I can't save an snapshot and then load it back on macOS until I figure out how to make these external.
20:15:23
drmeister
I'm going to collect them in a file and try adding '-exported_symbols_list <symbol-list>' to the link command line.
20:22:21
drmeister
That appears to define the ENTIRE symbol list to export. All sorts of new problems arise if I just list the symbols I want to add to the list of exported symbols.
20:24:06
frgo
Add in the fact that macOS is based on BSD - which, strictly speaking - is not a Unix and even has a Mach-O kernel, then yeah - Oh for crying out loud.
20:30:48
drmeister
If I can use dladdr/dlsym - I'd rather do that. Figuring out the absolute value of symbols that I read from symbol tables from ELF and macho files is a massive headache.
20:31:43
drmeister
For the last couple of weeks I've been trying one thing after another and every approach has had challenges and nightmares.
20:32:40
drmeister
Right now the problem appears to be reduced to "macos vtable pointers are sometimes external and sometimes internal linkage - how do I control it?"
21:01:54
frgo
drmeister: Does clasp use clang with -fvisibility=hidden? (I can't recall if it is even the default now). If so, explicitly making a symbol external is done using something like #define EXTERNAL __attribute__((visibility("default"))) and use that to mark the failing symbols with that. Just a possibility - and not a good one as it needs code changes.
21:04:22
drmeister
I am looking at classes and I can't see any obvious difference between classes that have external vtable symbols and those that have local vtable symbols.
21:11:41
drmeister
Templated ones are a bit part of the problem - but I see regular classes as part of the problem as well.
21:27:37
drmeister
I'm writing small test cases now and compiling them. vtable symbols are all external
22:03:56
drmeister
The vtable symbol for my classes starts out in an object file with external visibility but in the executable some of them become local - so it's the linker (macOS) that makes the call. Googling how linkers decide symbols have external or local visibility.
2:17:05
Bike
i have thought about it but not super deeply. the basic issue is i don't have a sense of how much we depend on vtables
2:17:19
Bike
for actual lisp functions i don't think removing vtables would be very hard, but i don't know what the C++ is doing as well
2:27:21
Bike
i think it's probably a good idea overall, we can save a word in all objects, and we already have to do dispatch through generic functions anyway, might as well use that
2:36:37
drmeister
Uh - or the compiler - actually - never mind that. The problem is that vtable pointer symbols are hidden in the final executable - so dlsym doesn't work with them - but dladdr does work with their addresses.
2:37:17
drmeister
In snapshot save/load during save I take function/method/vtable pointers and lookup their symbols with dladdr - and build symbol tables - that's not a problem.
2:37:42
drmeister
During snapshot load I use dlsym to lookup the address of the symbols - that's where the problem shows up for some vtable pointer symbols.
2:38:06
drmeister
If the vtables are "anchored" - then the vtable symbol is exported and there is no problem.
2:38:36
drmeister
To "anchor" a vtable you need the class to have at least one out-of-line virtual method.
2:39:06
drmeister
I can do that for our classes - most have this - but I'll have to anchor a few of them like Lisp_O.
2:40:06
drmeister
However, the template classes for builtin function wrappers - those I can't anchor because they are template classes - they are created at compile time based on function pointer types - I can't anchor them. There are about 3,000 of them in cando.
2:41:33
drmeister
Now - there is a facility where I can force symbols to be exported (ld option -exported_symbols_list <filename>) - but this is a PITA - it means we have to maintain a list of about 9,000 C++ mangled symbols Bleh Bleh Bleh.
2:42:46
drmeister
The problem is that we do depend on vtables for function objects. 'templatedSizeof' is one of the reasons we need vtables.
2:46:10
drmeister
This is for function objects in general - if the function object wraps a function pointer - that adds 8 bytes. If it wraps a method pointer - that adds 16 bytes.
2:48:02
drmeister
It's not clear to me that we absolutely need vtables though - we might be able to get around the need.
2:48:37
drmeister
It would take some work and some thinking though - the simpler thing would be if we could get these vtable symbols exported.
2:50:50
drmeister
I'm going to change the names of the template classes that derive from Function_O so I can grep them out of nm output.
2:53:56
drmeister
Hmm, I'm talking with Lang again - we've been chatting about this for a couple of hours - that's how I learned all this.