[Bug libbacktrace/105590] New: GCC should give backtraces on Darwin when it ICEs

[Bug libbacktrace/105590] New: GCC should give backtraces on Darwin when it ICEs

[acoplan at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105590

            Bug ID: 105590
           Summary: GCC should give backtraces on Darwin when it ICEs
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: libbacktrace
          Assignee: unassigned at gcc dot gnu.org
          Reporter: acoplan at gcc dot gnu.org
                CC: ian at gcc dot gnu.org
  Target Milestone: ---

I noticed that GCC doesn't give backtraces for ICEs on Darwin hosts. It would
be great if we could also get backtraces for ICEs on Darwin. It would make it
much easier to triage user bug reports, for example.

[Bug libbacktrace/105590] GCC should give backtraces on Darwin when it ICEs

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105590

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
disclaimer: I have not looked at libbacktrace for some time - but the current
behaviour matches my understanding of the situation.

On Darwin, debug information is not stored in the main executable, but in a
separate file package named 'exe-name'.dSYM (where the exe has a name
'exe-name').

Actually, for most executables there are unwind frames in the main executable
(but those might also be 'compacted').  I guess it might be possible to amend
libbacktrace to attempt to find the unwind data from the exe and then fall back
to using the .dSYM (someone needs to find the time to implement [or fix that if
it is supposed to work already])

Anyway, AFAIR, the current implementation of libbacktrace does not attempt to
find the unwind data from the exe, but instead looks for the 'exe-name.dSYM' to
find it.  If that file package is absent, the backtrace is omitted.

We do not automatically build the .dSYM files for a gcc build [cc1, cc1plus
etc] (nor do we install them).

However, suppose you have a current build of gcc:

"dsymutil gcc/cc1plus" will generate 'cc1plus.dSYM' and then we get a working
backtrace:

$ ./gcc/xg++ -Bgcc -std=c++20
/src-local/cxx-coroutines/gcc/testsuite/g++.dg/coroutines/pr102508-2.C -S
/src-local/cxx-coroutines/gcc/testsuite/g++.dg/coroutines/pr102508-2.C: In
function ‘void
foo(foo()::_Z3foov.Frame*)’:/src-local/cxx-coroutines/gcc/testsuite/g++.dg/coroutines/pr102508-2.C:34:17:
internal compiler error: in gimplify_expr, at gimplify.cc:15905
   34 |                 co_return ex;
      |                 ^~~~~~~~~
0x100fa4b28 gimplify_cleanup_point_expr
        /src-local/gcc-master/gcc/gimplify.cc:7151
0x100fa4b28 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
        ???:0
0x100fa7658 gimplify_stmt(tree_node**, gimple**)
        /src-local/gcc-master/gcc/gimplify.cc:7151
0x100fa5353 gimplify_statement_list
        /src-local/gcc-master/gcc/gimplify.cc:2019
0x100fa5353 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
        ???:0
0x100fa7658 gimplify_stmt(tree_node**, gimple**)
        /src-local/gcc-master/gcc/gimplify.cc:7151
<snip>

So one could generate the gcc/.dSYM for cc1*, f951, gnat1 etc. before a test
suite run.

NOTE: I have no idea if this would work for my (currently out of tree) arm64
port it's unlikely, I guess without some work to implement the low-level glue.

[Bug libbacktrace/105590] GCC should give backtraces on Darwin when it ICEs

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105590

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=88745

--- Comment #2 from Eric Gallager <egallager at gcc dot gnu.org> ---
Was thinking this was a duplicate of bug 88745 but that's already supposed to
be fixed, so maybe there's something else going on...