What is incomplete for /lib/libgcc_s.so-based C++ exception handling (where WITH_LLVM_LIBUNWIND= and /usr/local/lib/gcc*/libgcc_s.so are not used)

2018-10-17 Thread Mark Millard via freebsd-toolchain
[This summarizes other results without the code and debugger evidence and such from my recent explorations. It should be much easier to follow than my exploration reports.] Documents like DWARF5.pdf document the "row" vs. Location information for Call Frame Information as (also used for .eh_frame

/lib/libgcc_s.so.1 mishandles eh_frame information that /usr/local/lib/gcc8/libgcc_s.so.1 handles (powerpc64 test context): a simple example program

2018-10-17 Thread Mark Millard via freebsd-toolchain
(I happen to be using head -r339076 and ports -r480180 vintage materials, not that I expect such narrow vintage ties.) I finally have a simple example of the issue on powerpc64 . . . The following simple C++ program shows a significant difference for powerpc64 depending on which libgcc_s.so is us

[Bug 230857] loading carp module panic i386 kernel (VIMAGE related)

2018-10-17 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230857 Bjoern A. Zeeb changed: What|Removed |Added Depends on||232291, 232289 --- Comment #8 fro