[Bug libbacktrace/96973] New: No backtrace for cc1 on x86_64-apple-darwin

[Bug libbacktrace/96973] New: No backtrace for cc1 on x86_64-apple-darwin

[fxcoudert at gcc dot gnu.org]

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

            Bug ID: 96973
           Summary: No backtrace for cc1 on x86_64-apple-darwin
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libbacktrace
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fxcoudert at gcc dot gnu.org
                CC: ian at gcc dot gnu.org
  Target Milestone: ---

On x86_64-apple-darwin, internal errors in the compiler are not displaying
backtraces. 

For example this code:

$ cat ../../z1.f90 
program p
   type ta
      integer :: a
   end type
   type t
      type(ta), pointer :: b
   end type
   type(t) :: z
   data z / t(ta(1)) /
end

is giving me:

$ ./f951 ../../z1.f90
 p main
Analyzing compilation unit
f951: internal compiler error: in record_reference, at cgraphbuild.c:64
libbacktrace could not find executable to open


The message about not finding an executable is from fileline.c in
fileline_initialize(). There, it's trying to find the executable in several
steps.

- state->filename is NULL
- getexecname() is not available on darwin
- the /proc filesystem is not either
- the BSD-specific function sysctl_exec_name() is not present either

I am wondering how this is supposed to work. Probably state->filename should be
set in the first place.

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[fxcoudert at gcc dot gnu.org]

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

--- Comment #1 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Continuing to debug, I've added a darwin-specific implementation of
getexecname() with this patch:

diff --git a/libbacktrace/fileline.c b/libbacktrace/fileline.c
index cc1011e8b5d..3e4161e47c6 100644
--- a/libbacktrace/fileline.c
+++ b/libbacktrace/fileline.c
@@ -47,8 +47,23 @@ POSSIBILITY OF SUCH DAMAGE.  */
 #include "internal.h"

 #ifndef HAVE_GETEXECNAME
+#if __APPLE__
+#include <mach-o/dyld.h>
+
+char execname_buf[10240];
+
+static const char *
+getexecname (void)
+{
+  unsigned size = sizeof(execname_buf);
+
+  _NSGetExecutablePath(execname_buf, &size);
+  return execname_buf;
+}
+#else
 #define getexecname() NULL
 #endif
+#endif

 #if !defined (HAVE_KERN_PROC_ARGS) && !defined (HAVE_KERN_PROC)

@@ -192,6 +207,7 @@ fileline_initialize (struct backtrace_state *state,
          abort ();
        }

+      printf("libbacktrace filename = %s\n", filename ? filename : "NULL");
       if (filename == NULL)
        continue;



Sadly, this is not enough. This is leading to another error:

rmeur /tmp/ibin/gcc $ ./f951 ../../z1.f90
 p main
Analyzing compilation unit
f951: internal compiler error: in record_reference, at cgraphbuild.c:64
libbacktrace filename = NULL
libbacktrace filename = /private/tmp/ibin/gcc/./f951

f951: internal compiler error: Bus error: 10
libbacktrace filename = NULL
libbacktrace filename = /private/tmp/ibin/gcc/./f951

Internal compiler error: Error reporting routines re-entered.
libbacktrace filename = NULL
libbacktrace filename = /private/tmp/ibin/gcc/./f951


The backtrace (provided by lldb) for this new error is:

  * frame #0: 0x00000001013c1fff
f951`backtrace_free_locked(state=0x0000000142fd3000, addr=0x0000000144e94410,
size=5450529520) at mmap.c:104:15
    frame #1: 0x00000001013c21f4 f951`backtrace_alloc(state=0x0000000142fd3000,
size=25872, error_callback=(f951`::bt_err_callback(void *, const char *, int)
at diagnostic.c:552:3), data=0x00007ffeefbff26c) at mmap.c:152:3
    frame #2: 0x00000001013c1572 f951`macho_add(state=0x0000000142fd3000,
filename="/usr/local/opt/isl/lib/libisl.22.dylib", descriptor=5, offset=0,
match_uuid=0x0000000000000000, base_address=5415538688, skip_symtab=0,
error_callback=(f951`::bt_err_callback(void *, const char *, int) at
diagnostic.c:552:3), data=<unavailable>, fileline_fn=0x00007ffeefbfe858,
found_sym=0x00007ffeefbfe854) at macho.c:575:6
    frame #3: 0x00000001013c1d11
f951`backtrace_initialize(state=0x0000000142fd3000,
filename="/tmp/ibin/gcc/f951", descriptor=5,
error_callback=(f951`::bt_err_callback(void *, const char *, int) at
diagnostic.c:552:3), data=0x00007ffeefbff26c, fileline_fn=0x00007ffeefbfe8b8)
at macho.c:1259:12
    frame #4: 0x00000001013c015f
f951`fileline_initialize(state=0x0000000142fd3000,
error_callback=(f951`::bt_err_callback(void *, const char *, int) at
diagnostic.c:552:3), data=0x00007ffeefbff26c) at fileline.c:241:12

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[fxcoudert at gcc dot gnu.org]

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

--- Comment #2 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
I've gone a bit further with this, using the patch in comment #1 to fix the
executable path issue. I am now trying to make the backtrace work within
libgfortran, on a case with a known runtime error:

$ cat a.f90                     
  integer, allocatable :: i(:)
  allocate(i(10))
  print *, i(20)
  end
 $ ./bin/gfortran a.f90 -fbounds-check -g && ./a.out
At line 3 of file a.f90
Fortran runtime error: Index '20' of dimension 1 of array 'i' above upper bound
of 10

Error termination. Backtrace:
Could not print backtrace: executable file is not in Mach-O format


Why is it complaining? Looking at the code in macho_add(), it's being called a
number of times:

filename = /private/tmp/irun/./a.out
header.magic = 0xfeedfacf
filename = /private/tmp/irun/./a.out.dSYM/Contents/Resources/DWARF/a.out
header.magic = 0xfeedfacf
filename = /tmp/irun/lib/libgfortran.5.dylib
header.magic = 0xfeedfacf
filename = /usr/lib/libSystem.B.dylib
header.magic = 0xbebafeca
filename = /usr/lib/libSystem.B.dylib
header.magic = 0x00000000

It makes sense that it's called twice on libSystem.B.dylib, which is a fat i386
+ x86_64 library on darwin19. The first time it correctly sees a fat magic, but
the second time it finds it nul…

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[fxcoudert at gcc dot gnu.org]

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

--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
In macho_add_fat(), the code correctly identifies 2 archs, with the right types
(first i386, then x86_64). It's then calling macho_add() for the x86_64 arch,
with an foffset of 0x0000b00000000000, which looks very weird to me.

That code has a FIXME, so maybe that's the issue?

          /* FIXME: What about cpusubtype?  */
          foffset = fat_arch.offset;
          if (swapped)
            foffset = __builtin_bswap64 (foffset);
          backtrace_release_view (state, &arch_view, error_callback, data);
          return macho_add (state, filename, descriptor, foffset, match_uuid,
                            base_address, skip_symtab, error_callback, data,
                            fileline_fn, found_sym);

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[fxcoudert at gcc dot gnu.org]

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

--- Comment #4 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
I've identified the issue and found a fix. The problem is in the calculation of
the offset when !is_64. The current code is take the uint32_t offset value,
casting it into a uint64_t, then calling bswap64, which is wrong.

The correct way is to call bswap32 and then cast to uint64_t.



diff --git a/libbacktrace/macho.c b/libbacktrace/macho.c
index bd737226ca6..5974d8d8a5b 100644
--- a/libbacktrace/macho.c
+++ b/libbacktrace/macho.c
@@ -797,9 +797,13 @@ macho_add_fat (struct backtrace_state *state, const char
*filename,
       uint32_t fcputype;

       if (is_64)
-       memcpy (&fat_arch,
-               (const char *) arch_view.data + i * arch_size,
-               arch_size);
+       {
+         memcpy (&fat_arch,
+                 (const char *) arch_view.data + i * arch_size,
+                 arch_size);
+         if (swapped)
+           fat_arch.offset = __builtin_bswap64 (fat_arch.offset);
+       }
       else
        {
          struct macho_fat_arch fat_arch_32;
@@ -809,7 +813,10 @@ macho_add_fat (struct backtrace_state *state, const char
*filename,
                  arch_size);
          fat_arch.cputype = fat_arch_32.cputype;
          fat_arch.cpusubtype = fat_arch_32.cpusubtype;
-         fat_arch.offset = (uint64_t) fat_arch_32.offset;
+         if (swapped)
+           fat_arch.offset = (uint64_t) __builtin_bswap32(fat_arch_32.offset);
+         else
+           fat_arch.offset = (uint64_t) fat_arch_32.offset;
          fat_arch.size = (uint64_t) fat_arch_32.size;
          fat_arch.align = fat_arch_32.align;
          fat_arch.reserved = 0;
@@ -821,14 +828,9 @@ macho_add_fat (struct backtrace_state *state, const char
*filename,

       if (fcputype == cputype)
        {
-         uint64_t foffset;
-
          /* FIXME: What about cpusubtype?  */
-         foffset = fat_arch.offset;
-         if (swapped)
-           foffset = __builtin_bswap64 (foffset);
          backtrace_release_view (state, &arch_view, error_callback, data);
-         return macho_add (state, filename, descriptor, foffset, match_uuid,
+         return macho_add (state, filename, descriptor, fat_arch.offset,
match_uuid,
                            base_address, skip_symtab, error_callback, data,
                            fileline_fn, found_sym);
        }

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iains at gcc dot gnu.org

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #3)
> In macho_add_fat(), the code correctly identifies 2 archs, with the right
> types (first i386, then x86_64). It's then calling macho_add() for the
> x86_64 arch, with an foffset of 0x0000b00000000000, which looks very weird
> to me.
> 
> That code has a FIXME, so maybe that's the issue?
> 
>           /* FIXME: What about cpusubtype?  */

cpu subtype is about x86_64/x86_64h or ppc601 c.f ppc7400 slices - it should
not be relevant in cases we'll encounter at present in GCC.  I suppose that it
could conceivably be tricky if we have two slices that are valid for the
current arch (we'd have to figure which one was going to be selected).

It might be some future GCC version could have slices for x86_64, x86_64h and
arm64 / arm64e - we would then need to revisit this.

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[iains at gcc dot gnu.org]

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

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Francois-Xavier Coudert from comment #4)

from fat.h

FAT headers are always written bigendian

 * at least there's no statement revoking that in the section on FAT64
 * it doesn't seem that the FAT64 format is considered stable yet - so we might
need to experiment,

There's no statement that says the FAT64
>        if (is_64)
> -       memcpy (&fat_arch,
> -               (const char *) arch_view.data + i * arch_size,
> -               arch_size);
> +       {
> +         memcpy (&fat_arch,
> +                 (const char *) arch_view.data + i * arch_size,
> +                 arch_size);
> +         if (swapped)
> +           fat_arch.offset = __builtin_bswap64 (fat_arch.offset);
> +       }
>        else
>         {
>           struct macho_fat_arch fat_arch_32;
> @@ -809,7 +813,10 @@ macho_add_fat (struct backtrace_state *state, const
> char *filename,
>                   arch_size);
>           fat_arch.cputype = fat_arch_32.cputype;
>           fat_arch.cpusubtype = fat_arch_32.cpusubtype;
> -         fat_arch.offset = (uint64_t) fat_arch_32.offset;
> +         if (swapped)
> +           fat_arch.offset = (uint64_t)
> __builtin_bswap32(fat_arch_32.offset);
> +         else
> +           fat_arch.offset = (uint64_t) fat_arch_32.offset;

So in the case of 32b FAT entries...

We also need to swap any other items we use (and before promoting to 64b in the
case of the size.)

>           fat_arch.size = (uint64_t) fat_arch_32.size;
>           fat_arch.align = fat_arch_32.align;
>           fat_arch.reserved = 0;

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[fxcoudert at gcc dot gnu.org]

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

--- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Actually we're not using the other members. So how about simply:

diff --git a/libbacktrace/macho.c b/libbacktrace/macho.c
index bd737226ca6..7f093f309fb 100644
--- a/libbacktrace/macho.c
+++ b/libbacktrace/macho.c
@@ -793,40 +793,33 @@ macho_add_fat (struct backtrace_state *state, const char
*filename,

   for (i = 0; i < nfat_arch; ++i)
     {
-      struct macho_fat_arch_64 fat_arch;
       uint32_t fcputype;
+      uint64_t foffset;

       if (is_64)
-       memcpy (&fat_arch,
-               (const char *) arch_view.data + i * arch_size,
-               arch_size);
+       {
+         struct macho_fat_arch_64 fat_arch;
+         memcpy (&fat_arch,
+                 (const char *) arch_view.data + i * arch_size,
+                 arch_size);
+
+         foffset = swapped ? __builtin_bswap64 (fat_arch.offset) :
fat_arch.offset;
+         fcputype = swapped ? __builtin_bswap32 (fat_arch.cputype) :
fat_arch.cputype;
+       }
       else
        {
          struct macho_fat_arch fat_arch_32;
-
          memcpy (&fat_arch_32,
                  (const char *) arch_view.data + i * arch_size,
                  arch_size);
-         fat_arch.cputype = fat_arch_32.cputype;
-         fat_arch.cpusubtype = fat_arch_32.cpusubtype;
-         fat_arch.offset = (uint64_t) fat_arch_32.offset;
-         fat_arch.size = (uint64_t) fat_arch_32.size;
-         fat_arch.align = fat_arch_32.align;
-         fat_arch.reserved = 0;
-       }

-      fcputype = fat_arch.cputype;
-      if (swapped)
-       fcputype = __builtin_bswap32 (fcputype);
+         foffset = swapped ? __builtin_bswap32 (fat_arch_32.offset) :
fat_arch_32.offset;
+         fcputype = swapped ? __builtin_bswap32 (fat_arch_32.cputype) :
fat_arch_32.cputype;
+       }

       if (fcputype == cputype)
        {
-         uint64_t foffset;
-
          /* FIXME: What about cpusubtype?  */
-         foffset = fat_arch.offset;
-         if (swapped)
-           foffset = __builtin_bswap64 (foffset);
          backtrace_release_view (state, &arch_view, error_callback, data);
          return macho_add (state, filename, descriptor, foffset, match_uuid,
                            base_address, skip_symtab, error_callback, data,

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Ian Lance Taylor <ian@gcc.gnu.org>:

https://gcc.gnu.org/g:488e33339e6dea3262a11307592e9aad87a97c8d

commit r11-3055-g488e33339e6dea3262a11307592e9aad87a97c8d
Author: Ian Lance Taylor <iant@golang.org>
Date:   Tue Sep 8 13:16:44 2020 -0700

    libbacktrace: correctly swap Mach-O 32-bit file offset

    libbacktrace/ChangeLog:
            PR libbacktrace/96973
            * macho.c (macho_add_fat): Correctly swap 32-bit file offset.

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[ian at airs dot com]

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

Ian Lance Taylor <ian at airs dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
                 CC|                            |ian at airs dot com
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #9 from Ian Lance Taylor <ian at airs dot com> ---
Thanks.  I committed a version of your patch.  Let me know if there is still a
problem.

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[fxcoudert at gcc dot gnu.org]

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

--- Comment #10 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Hi Ian,

There is still the issue in comment #1: none of the mechanisms for finding the
executable path are currently working on darwin (at least in the circumstances
I am testing in).

- state->filename is NULL
- getexecname() is not available on darwin
- the /proc filesystem is not either
- the BSD-specific function sysctl_exec_name() is not present either

I would like to propose adding a mechanism using darwin's native function,
which is _NSGetExecutablePath (defined in the <mach-o/dyld.h> header). Two
questions, which are for you to decide, are:

1. should it be implemented as an addition case in the switch statement? or as
a fallback for getexecname(), as I have done?
2. should it be guarded by an __APPLE__ preprocessor check, or detected in
configure?

My personal preference would be:

1. I don't really care
2. I don't see the value of a configure check, given it is directly and
unambiguously linked to the target (and therefore to the __APPLE__ preprocessor
macro being present)

Please let me know what you prefer, and I will prepare and test a proper patch.

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Ian Lance Taylor <ian@gcc.gnu.org>:

https://gcc.gnu.org/g:181f877b6c0e365c940b117c306e7309e19ffd89

commit r11-3064-g181f877b6c0e365c940b117c306e7309e19ffd89
Author: Ian Lance Taylor <iant@golang.org>
Date:   Tue Sep 8 19:09:21 2020 -0700

    libbacktrace: fetch executable path on macOS

            PR libbacktrace/96973
            * fileline.c (macho_get_executable_path): New static function.
            (fileline_initialize): Call macho_get_executable_path.

[Bug libbacktrace/96973] No backtrace for cc1 on x86_64-apple-darwin

[ian at airs dot com]

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

--- Comment #12 from Ian Lance Taylor <ian at airs dot com> ---
Thanks, that part should now be fixed also.