Building gdb-9.1 on OSX: gdb's exceptions are not getting caught

Building gdb-9.1 on OSX: gdb's exceptions are not getting caught

[krokus]

gdb 9.1 is being built from sources .tar.gz on OSX 10.13 with clang 8.0.
The build proceeds successfully, resulting in a runnable gdb binary
(properly codesign'ed).

I get the (gdb) prompt. Known commands (e.g. info) are properly executed.
However entering an incorrect command results in Abort trap: 6 with the
message:
"libc++abi.dylib: terminating with uncaught exception of type
gdb_exeption_error"

I'm trying to diagnose why gdb appears to be failing to catch its own
exceptions.

In case of executing an incorrect command, the try/catch handling is
supposed to be done in event-top.c::gdb_rl_callback_handler(). Indeed, the
crash log (see below) shows this entry which correctly proceeds to
throw_it() , yet never gets caught back at the gdb_rl_callback_handler().

I even tried to explicitly put a throw("catch-this") in the
gdb_rl_callback_handler() and then added a catch(...) clause in hope to
catch it there rightaway. Yet it goes uncaught, as if there's no catch
there.

Anybody experienced similar issues with non-functioning exceptions while
building on OSX?

The configure flags I used:
../configure --disable-binutils
--enable-targets="x86_64-apple-darwin,x86_64-linux-gnu,i686-linux-gnu"
--without-lzma --without-python"

This build should use gdb's own readline (the system's own is too old
according to the configure).

Clang+LLVM 8.0.0 installed from a pre-built binary (from llvm.org) at:
/usr/local/opt/llvm
Clang's flags: "-fno-jump-tables -fexceptions -funwind-tables
-fasynchronous-unwind-tables".
Link flags: "-Wl,-rpath,/usr/local/opt/llvm/lib
/usr/local/opt/llvm/lib/libc++abi.dylib"

With these flags, all  gdb code (both C and C++) should be compiled with
exception/unwind support. Just to rule out the compiler, exceptions are
caught correctly in a simple try/throw/catch standalone .cc test.

I noticed some ChangeLog entries concerning exception handling (SJLJ rework
etc.). I wonder if this has been tested to work on OSX?

Below is the crash log. The terminal try/catch is at frame 17:
17  gdb                               0x000000010570dcd1
gdb_rl_callback_handler(char*) + 417 (memory:2649)

$ gdb/gdb
(gdb) dummycommand

libc++abi.dylib: terminating with uncaught exception of type
gdb_exception_error
Abort trap: 6

-----------------------------
Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib            0x00007fff7d4e8fce __pthread_kill + 10
1   libsystem_pthread.dylib           0x00007fff7d626150 pthread_kill + 333
2   libsystem_c.dylib                 0x00007fff7d44532a abort + 127
3   libc++abi.1.dylib                 0x0000000109d7a373 abort_message + 195
4   libc++abi.1.dylib                 0x0000000109d5d922
demangling_terminate_handler() + 258
5   libc++abi.1.dylib                 0x0000000109d793e8
std::__terminate(void (*)()) + 8
6   libc++abi.1.dylib                 0x0000000109d7c49b
__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 27
7   libc++abi.1.dylib                 0x0000000109d7c421 __cxa_throw + 113
8   gdb                               0x00000001057a4dae
throw_it(return_reason, errors, char const*, __va_list_tag*) + 238
(common-exceptions.c:204)
9   gdb                               0x00000001057a4ca6
throw_verror(errors, char const*, __va_list_tag*) + 54
(common-exceptions.c:211)
10  gdb                               0x0000000105fa6d0c verror(char
const*, __va_list_tag*) + 28 (utils.c:171)
11  gdb                               0x00000001057b37e3 error(char const*,
...) + 275 (errors.c:44)
12  gdb                               0x00000001053b4710
undef_cmd_error(char const*, char const*) + 192 (cli-decode.c:1559)
13  gdb                               0x00000001053ae8a9 lookup_cmd(char
const**, cmd_list_element*, char const*, int, int) + 2857
14  gdb                               0x0000000105e745f6
execute_command(char const*, int) + 1014 (top.c:585)
15  gdb                               0x000000010570f4cb
command_handler(char const*) + 475 (event-top.c:593)
16  gdb                               0x0000000105710047
command_line_handler(std::__1::unique_ptr<char, gdb::xfree_deleter<char>
>&&) + 215 (event-top.c:777)
17  gdb                               0x000000010570dcd1
gdb_rl_callback_handler(char*) + 417 (memory:2649)
18  gdb                               0x000000010607ce61
rl_callback_read_char + 1025
19  gdb                               0x000000010571165e
gdb_rl_callback_read_char_wrapper_noexcept() + 270 (event-top.c:177)
20  gdb                               0x000000010570d075
gdb_rl_callback_read_char_wrapper(void*) + 197 (event-top.c:196)
21  gdb                               0x000000010570ee9d
stdin_event_handler(int, void*) + 301 (event-top.c:520)
22  gdb                               0x00000001057098fb
gdb_wait_for_event(int) + 1515
23  gdb                               0x0000000105708ee3 gdb_do_one_event()
+ 275
24  gdb                               0x0000000105709e15 start_event_loop()
+ 85 (event-loop.c:402)
25  gdb                               0x00000001059d574a
captured_command_loop() + 186 (main.c:364)
26  gdb                               0x00000001059d0ae5
captured_main(void*) + 53 (main.c:1202)
27  gdb                               0x00000001059d09df
gdb_main(captured_main_args*) + 31 (main.c:1228)
28  gdb                               0x00000001050f2611 main + 305
(gdb.c:33)
29  libdyld.dylib                     0x00007fff7d399145 start + 1
-----------------------------

Re: Building gdb-9.1 on OSX: gdb's exceptions are not getting caught

[Paul Koning]

> On Apr 14, 2020, at 4:23 PM, krokus via Gdb <gdb@sourceware.org> wrote:
> 
> gdb 9.1 is being built from sources .tar.gz on OSX 10.13 with clang 8.0.
> The build proceeds successfully, resulting in a runnable gdb binary
> (properly codesign'ed).
> 
> I get the (gdb) prompt. Known commands (e.g. info) are properly executed.
> However entering an incorrect command results in Abort trap: 6 with the
> message:
> "libc++abi.dylib: terminating with uncaught exception of type
> gdb_exeption_error"
> 
> I'm trying to diagnose why gdb appears to be failing to catch its own
> exceptions.
> 
> In case of executing an incorrect command, the try/catch handling is
> supposed to be done in event-top.c::gdb_rl_callback_handler(). Indeed, the
> crash log (see below) shows this entry which correctly proceeds to
> throw_it() , yet never gets caught back at the gdb_rl_callback_handler().
> 
> I even tried to explicitly put a throw("catch-this") in the
> gdb_rl_callback_handler() and then added a catch(...) clause in hope to
> catch it there rightaway. Yet it goes uncaught, as if there's no catch
> there.
> 
> Anybody experienced similar issues with non-functioning exceptions while
> building on OSX?
> 
> The configure flags I used:
> ../configure --disable-binutils
> --enable-targets="x86_64-apple-darwin,x86_64-linux-gnu,i686-linux-gnu"
> --without-lzma --without-python"

I recently built it, and after some messing around with signatures and the like, it seems to work.  It certainly has no trouble with invalid commands.

(gdb) show config
This GDB was configured as follows:
   configure --host=x86_64-apple-darwin18.7.0 --target=x86_64-apple-darwin18.7.0
             --with-auto-load-dir=:${prefix}/share/auto-load
             --with-auto-load-safe-path=:${prefix}/share/auto-load
             --with-expat
             --with-gdb-datadir=/usr/local/share/gdb (relocatable)
             --with-jit-reader-dir=/usr/local/lib/gdb (relocatable)
             --without-libunwind-ia64
             --without-lzma
             --without-babeltrace
		             --without-intel-pt
             --with-mpfr
             --without-xxhash
             --without-python
             --without-guile
             --disable-source-highlight
             --with-separate-debug-dir=/usr/local/lib/debug (relocatable)

("Relocatable" means the directory can be moved with the GDB installation
tree, and GDB will still find it.)
(gdb) wrongcommand
Undefined command: "wrongcommand".  Try "help".
(gdb) 

	paul

Re: Building gdb-9.1 on OSX: gdb's exceptions are not getting caught

[krokus]

Thanks for the quick reply. I'll try building using your config.
What compile/link flags did you use?

I assume it's clang too. If you didn't set or pass any additional
C/CXXFLAGS to configure, it would probably use the defaults. In such case
the deffault  flags will likely show up with this command:
```
echo "int main() {return 0;}" > /tmp/x.cc  && clang++ -v -Wl,-v /tmp/x.cc
-o /dev/null && rm /tmp/x.cc
```

Re: Building gdb-9.1 on OSX: gdb's exceptions are not getting caught

[krokus]

Paul,
I tried to build with your configure flags; So far the same result, it does
not catch the exceptions. I'm puzzled.

Could you please run the test below to see which compiler and link flags
are being active during clang complie and link?
It should run clang in verbose mode and will show the flags and include/lib
paths
I will try to match your compile/link flags with my clang-8.0.

TEST:
```
echo "int main() {return 0;}" > /tmp/x.cc  && clang++ -v -Wl,-v /tmp/x.cc
-o /dev/null && rm /tmp/x.cc
```
Thanks!