libera/#clasp - IRC Chatlog
Search
17:05:37
drmeister
Hey - any ideas yet? I'm going to drive to Blue Bell. I'll be afk for about 45 min.
17:11:41
drmeister
https://libunwind-devel.nongnu.narkive.com/jkimTV06/unw-get-proc-info-never-gets-unwind-info
17:11:59
drmeister
"For x86_64, specifically, and for dwarf generally, unw_get_proc_info does not set the unwind_info field of the unw_proc_info_t to any non-NULL value, ever. "
17:15:34
Bike
the unwind_info is some user thing anyway. we don't need to worry about that. not relevant
17:35:54
Bike
libunwind calls dl_iterate_phdr in dwarf_find_proc_info, but i've lost track of where the runtime does it
17:50:34
Bike
"For statically generated code, the compiler normally takes care of emitting unwind-info which provides the minimum amount of information needed to reconstruct the frame-state for each instruction in a procedure. For dynamically generated code, the runtime code generator must use the dynamic unwind-info interface provided by libunwind to supply the equivalent information."
19:02:41
drmeister
undefined reference to '__register_frame' when I link iclasp-boehm without -lgcc_s
19:07:31
drmeister
We are linking against an llvm that has been patched to expect the llvm libunwind.
19:08:29
drmeister
I put a break on __register_frame and loaded a fasp file - it shows llvm::orc::walkAppleEHFrameSection on the stack
19:09:44
drmeister
Dammit - so we've been chasing our tails for the last day or so with gnu libunwind.
19:11:58
drmeister
Well, we've learned something about the unwinding - but the current problem may be a phantom.
19:15:11
drmeister
Right - on linux. I'm not sure that's wrong - but it triggered the memory that the llvm we are working with has been patched to expect the llvm libunwind on linux and we are playing around with linking gnu libunwind.
19:16:19
drmeister
So I should build an llvm that expects the gnu libunwind before we dig any deeper.
19:36:42
drmeister
There doesn't appear to be a link from the documentation to this function. Do you see anything?
19:39:29
drmeister
So how about I build an llvm on hermes that will use the gnu libunwind and we check if this libunwind-dynamic registration is happening properly.
19:42:32
Bike
https://github.com/llvm/llvm-project/blob/main/libunwind/src/UnwindLevel1-gcc-ext.c#L237-L244 hmmmmm
22:03:43
drmeister
I have gnu libunwind running and when I (load "/tmp/push.fasp") it invokes __register_frame - not _U_dyn_register
22:06:51
drmeister
@lhames From what we read the gnu libunwind dynamic interface involves calling `_U_dyn_register` to register frames with gnu libunwind. We don't see `_U_dyn_register` anywhere in the llvm code and while the `_U_dyn_register` is defined in our runtime - it is never invoked.
22:07:17
Bike
i think what's supposed to happen is a definition of __register_frame is provided which calls the registration function
22:07:38
Bike
like you can see the llvm libunwind's definition of __register_frame which calls __unw_add_dynamic_fde
22:12:34
drmeister
I think the llvm folks would rather that we use llvm libunwind. llvm libunwind is a PITA to link in - I haven't figured out how yet.
0:46:06
drmeister
When you have time can you fill me in on your thinking about registration - or the lack of registration.
0:59:30
drmeister
It looks to me like it's calling __register_frame in libgcc_s and so libunwind doesn't know anything about jitted frames.
1:07:01
drmeister
I think llvm is designed to with with libgcc_s on linux and on macOS whatever unwinds normally or llvm libunwind.
1:10:00
Bike
well what i'm thinking is just that an appropriate definition of __register_frame that calls _U_dyn_register could be provided, and then bam
1:15:34
Bike
because clearly, llvm can tell libgcc_s and its libunwind about jitted code, and gnu libunwind has some kind of interface for this, so llvm should be able to do so for gnu libunwind just as well
2:05:51
drmeister
I don't see the relationship between __register_frame and _U_dyn_register - they seem like very different interfaces.
2:07:20
drmeister
If we used the gnu libunwind we'd have to figure out how to redirect the call from __register_frame to something that converts the argument to something _U_dyn_register can handle. Likewise for the deregister function.
2:15:49
Bike
mm, they're different interfaces, but one of the _U_dyn_register modes is telling it about regular debug tables, looks like
2:16:22
Bike
the downside of using llvm libunwind would just be the specific dependency, but that's not bad itself