libera/#clasp - IRC Chatlog
Search
13:42:59
Bike
this here is actually two completely different functions with different names and operations, depending on what is defined and what isn't
13:48:04
beach
I usually think it was pretty gutsy by RMS to choose C and Unix. I would have done the wrong thing by choosing Lisp and Genera, but then free software would not have existed. However, writing a compiler in C is just nuts.
15:21:50
drmeister
Bike: I have two sessions of clasp running under udb and one has gnu libunwind with debug symbols and the other has gcc_s with debug symbols.
15:22:33
drmeister
I can see the point where they diverge. But I have no insight (yet) into what is wrong.
15:24:12
drmeister
with gcc_s the lsda is simply returned. With libunwind it parses stuff and then returns an lsda - it's probably doing something wrong here.
15:24:35
drmeister
Comparing the lsda data is hard because I don't know what is address specific and what is invariant.
15:25:05
Bike
https://itanium-cxx-abi.github.io/cxx-abi/exceptions.pdf this has the LSDA format, if that helps
15:28:19
Bike
_Unwind_Context is an opaque type so I guess it can be different in different implemtnations
15:29:01
drmeister
So gcc_s gives me a working lsda and gnu libunwind calculates one. They are different - but are the differences significant?
15:31:44
Bike
I think this probably just means that gcc_s is figuring out where the lsda is in the unwinder (i.e. the thing calling these _Unwind functions) whereas libunwind only does it when it's requested to
15:33:05
drmeister
Yes, they are returning different values - but they are different programs running in different address spaces.
15:34:03
drmeister
It might be worth putting some print statements into the __gxx_personality_v0 function and looking at what differences there are.
15:34:23
Bike
i put in the libunwind backtrace code, conditionalized on USE_LIBUNWIND. I'm making sure it works both ways now, but if it does, should I push it? Or I guess I should try it on linux first
15:34:40
drmeister
Lang suggested comparing statically compiled code to JITted code. I'm not sure how to do that these days.
15:35:30
drmeister
I don't have clasp building properly on linux at the moment - the libunwinds having the same name is causing me grief.
15:36:08
drmeister
I did one thing. I forked llvm and applied the patch. So we have a forked/patched llvm now.
15:37:51
drmeister
I'm going to drive to ThirdLaw - I'll give you a call from the road. We have tools (udb and symbolicated libraries on linux) - I'm not sure how to debug this though without a deep understanding of the lsda.
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