libera/#clasp - IRC Chatlog
Search
13:07:33
drmeister
Bike: Hey - good morning. I have a zoom call this morning demoing the sequence analysis to our collaborators down in Florida.
13:18:40
Bike
<?https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/libsupc++/eh_personality.cc#L497-L519?> here's the part where it parses the table, <?https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/libsupc++/eh_personality.cc#L544-L643?> here's where it decides whether it matches, <?https://github.com/gcc-mirror/gcc/blob/master/libstdc++-v3/libsupc++/eh_personality.cc#L649-L662?> here's the result of a
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.