freenode/#clasp - IRC Chatlog
Search
18:20:51
drmeister
I have a challenge with snapshot save/load. I need to link a lot of GC managed object that contain function pointers and vtable pointers to the absolute addresses of these objects when the snapshot is brought back to life.
18:21:22
drmeister
I've been wrestling with this for a couple of weeks - trying one thing or another and getting caught in some rabbit holes.
18:22:21
drmeister
I thought it was a list of all function/method pointers that I can't resolve using dladdr/dlsym. But there are virtual methods in there that I need to weed out. Hang on.
18:23:49
drmeister
virtual methods are not function pointers - they are small integers <1024. So I ignore them if (uintptr_t)functionPointer < 1024
18:27:31
drmeister
I've been wrestling with this for weeks and I got things working on linux - but in a way that I fear is a bit brittle.
18:27:47
drmeister
I expected worse problems on macOS - but it looks like I have less problems on macOS.
18:32:09
drmeister
I couldn't get dladdr/dlsym to work for certain addresses - I think for functions that have 'internal' linkage. So I did all sorts of backflips to parse ELF files and to figure out absolute addresses of symbols.
18:38:26
drmeister
The names are the clasp names - I call dladdr on the pointer and if I don't get anything back then it generates that message.
18:38:55
drmeister
If I do get something back I run the result through some other tests like "can I call dlsym on the name that dladdr returns" - and they all pass.
19:04:55
drmeister
I'm trying to figure that out. These are "public:" methods. I always thought that automatically meant external/global linkage.
19:05:41
Bike
i would think that public just means the compiler controls rather than anything about the elf
19:06:35
drmeister
Yes, CreateCondBr has internal linkage and on linux that means if you pass it's address to dladdr - you get nothing back.
19:07:35
drmeister
Yeah - and I have thousands of other function/method pointers that work fine with dladdr - I don't know what is different about them yet. I'm digging deeper.
19:08:45
drmeister
Sure - note though - dladdr doesn't work with these methods on linux - on macOS they return info just fine.
19:12:20
drmeister
If I could use dladdr to look up all these addresses and then at load time use dlsym to find the address from the name I'd be happy.
19:22:51
Bike
the libLLVM on my home system doesn't have CreateCondBr at all, apparently? maybe i'm using nm wrong
19:41:33
drmeister
I can't get a lot of these symbols that dladdr works with to show up when I grep the output of
19:43:08
drmeister
I assumed that "public:" symbols for functions/methods were external/global linkage and would show up with a "T" in nm output and work with dladdr. Right now I'm ready to toss that assumption out the window.
19:43:57
Bike
the access control stuff like public: just makes the compiler complain about things, there's no reason to affect the runtime i don't think
19:44:15
Bike
and you can do access control for things that aren't in the binary at all, like typedefs.
20:51:06
drmeister
Someone on the #llvm discord answered my question about this - these are probably inlined methods.
20:51:34
drmeister
So the compiler generates a function when I ask for the pointer - but it doesn't have a real address.
21:06:41
drmeister
Hmmm, on macOS this isn't a problem - I can identify symbols with dladdr for everything.
21:13:10
Bike
today i realized tagbody SJLJ unwinds have been broken for six months, which i guess goes to show how rare those are
21:14:23
drmeister
What should I do about this? The obvious, bullet-proof thing I can do is write functions wrappers that take the object and arguments and do nothing but call the method and return the result.
21:14:59
Bike
this is for restoring the image, right? these are pointers that already exist before the image dump?
21:15:25
drmeister
Yes - for restoring the image and yes - the pointers already exist before the image dump.
21:15:38
Bike
so how do we have pointers to these things if these things do not in fact have addresses?
21:16:58
drmeister
That's a mystery that I have only in the last few minutes become aware of. I believe that on linux a method is instantiated by the compiler - but it doesn't get an address/symbol that dladdr/dlsym can resolve?
21:18:43
Bike
i mean, basically, so it's not in the SO, but when we include the header we need an actual pointer so the compiler instantiates one
21:19:14
drmeister
I'm going to start writing wrapper functions. It's the only thing I am certain will solve this problem.
21:21:17
drmeister
I put a function to call dladdr on every function/method we expose when we startup clasp the old way.
21:23:19
drmeister
https://github.com/clasp-developers/clasp/blob/future/src/llvmo/llvmoExpose.cc#L1378
21:24:38
drmeister
https://github.com/clasp-developers/clasp/blob/future/src/llvmo/llvmoExpose.cc#L1378
21:25:23
drmeister
https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/Module.h#L300
21:27:49
drmeister
But I gotta look up EVERY ONE of these functions and write a wrapper for it. Bleh.
21:30:23
drmeister
Oh glob - and when you add a function - pretty much everything needs to be recompiled.