[Bug libgcc/110955] New: SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[Bug libgcc/110955] New: SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[sumbera at volny dot cz]

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

            Bug ID: 110955
           Summary: SIGSEGV in
                    libgcc_s.so.1`classify_object_over_fdes+0x140 on
                    Solaris SPARC with GCC 13 runtime
           Product: gcc
           Version: 13.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sumbera at volny dot cz
  Target Milestone: ---

I see this on Solaris 11.4 SPARC with libgcc_s.so.1 from GCC 13.1.0 and 13.2.0.
But not with libgcc_s.so.1 from GCC 12.2.0. I don't see this with Solaris i386.

/usr/bin/gnome-shell terminated by SIGSEGV with following stack:

Loading modules: [ libc.so.1 ld.so.1 ]
gnome-shell:core> $C
    7ed252312fd1 libgcc_s.so.1`classify_object_over_fdes+0x140(a044b6f700?,
7ec86d0593d4?, 7ed252313950?, 0?, 0?, ffffb3c4?)
    7ed2523130a1 libgcc_s.so.1`__register_frame_info_bases+0x48(7ec76d05e010?,
a044b6f700?, a044b6f700?, 0?, 0?, a04460aa08?)
    7ed252313161
libLLVM-13.so`_ZN4llvm19RTDyldMemoryManager16registerEHFramesEPhmm+0x30(a0445ef9e0?,
7ec76d05e010?, 7ec76d05e010?, 4c?, 7ec76d518944?, 0?)
    7ed252313231
swrast_dri.so`_ZN26DelegatingJITMemoryManager16registerEHFramesEPhmm+0x40(a0446337a0?,
7ec76d05e010?, 7ec76d05e010?, 4c?, 7ec76dbc2a40?, 0?)
    7ed2523132e1
libLLVM-13.so`_ZN4llvm14RuntimeDyldELF16registerEHFramesEv+0xac(a044611130?,
0?, f0?, a04460c3f8?, 4?, 0?)
    7ed2523133a1
libLLVM-13.so`_ZN4llvm11RuntimeDyld16registerEHFramesEv+0x40(a04460f370?,
a04460f470?, 1?, 0?, a04460f310?, 1?)
    7ed252313461
libLLVM-13.so`_ZN4llvm5MCJIT21finalizeLoadedModulesEv+0x488(a04460f0a0?,
a04460f370?, a04460f430?, a04460f448?, a04460f430?, a04460f430?)
    7ed252313571
libLLVM-13.so`_ZN4llvm5MCJIT14finalizeObjectEv+0x290(a04460f0a0?, a04460f3c8?,
7ed252313e20?, a04460f3f0?, 7ed252313e60?, 7ed252313e60?)
    7ed2523136e1 libLLVM-13.so`LLVMGetPointerToGlobal+0x38(a04460f0a0?,
a044607d88?, 291c00?, 0?, 0?, 336?)
    7ed2523137a1 swrast_dri.so`llvmpipe_update_fs+0xe94(a0423cc3c0?,
a0446010b4?, a042451ba0?, a0426a6080?, a044601000?, 0?)
    7ed2523140f1 swrast_dri.so`llvmpipe_update_derived+0x468(a0423cc3c0?,
43de?, 43d9?, a0426a44a0?, 4299?, 43df?)
    7ed2523141a1 swrast_dri.so`llvmpipe_draw_vbo+0x3f4(a0423cc3c0?,
7ed252314b50?, 0?, 0?, 7ed252314b30?, 1?)
    7ed252314261 swrast_dri.so`util_blitter_draw_rectangle+0x250(a042651fd0?,
a042654790?, 7ec763aa09c8?, 0?, 7ec7639f2248?, 7ed252314b50?)
    7ed252314371 swrast_dri.so`blitter_draw_tex+0x1c4(a042651fd0?, 0?, 0?,
3c0?, 258?, a047321990?)
    7ed2523144e1 swrast_dri.so`util_blitter_blit_generic+0x1760(a042651fd0?,
a047321990?, 7ed25231519c?, 0?, 2?, 0?)
    7ed252314761 swrast_dri.so`util_blitter_blit+0xf4(a042651fd0?,
7ed252315190?, 0?, 1?, a043d52ba0?, a047321990?)
    7ed2523148d1 swrast_dri.so`lp_blit+0x3bc(a0423cc3c0?, 0?, 0?, 0?, 0?,
4590?)
    7ed252314a31 swrast_dri.so`util_gen_mipmap+0xd0(a0423cc3c0?, a0445edc60?,
4b0?, 1?, a?, 0?)
    7ed252314b81 swrast_dri.so`st_generate_mipmap+0x188(a0427d47c0?, de1?,
a043d52730?, 0?, a042694130?, a?)
    7ed252314c51 swrast_dri.so`_mesa_GenerateMipmap+0x174(de1?, 3?, 14d78?,
a043f6ef80?, a043d52730?, a0427d47c0?)
    7ed252314d01 libglapi.so.0.0.0`shared_dispatch_stub_674+0x1c(de1?, 3?,
7ed25231566c?, a042699290?, a04281d2d8?, a042698a40?)
    7ed252314db1
libmutter-cogl-9.so.0.0.0`_cogl_texture_gl_generate_mipmaps+0xc4(a043d52650?,
a042698a40?, a042698a40?, 7ed25231566c?, 7ed252315668?, a?)
    7ed252314e71
libmutter-cogl-9.so.0.0.0`_cogl_texture_2d_pre_paint+0x48(a043d52650?, 1?, ff?,
a0445eda20?, 8?, a042698a40?)
    7ed252314f21
libmutter-cogl-9.so.0.0.0`_cogl_texture_pre_paint+0x1c(a043d52650?, 1?,
7ed25231588c?, a0445edb20?, 0?, a0445edb00?)
    7ed252314fd1
libmutter-cogl-9.so.0.0.0`_cogl_pipeline_layer_pre_paint+0x60(a0445edb20?, 0?,
a0445eda20?, 1?, a0445edb20?, a0445edb20?)
    7ed252315091
libmutter-cogl-9.so.0.0.0`_cogl_rectangles_validate_layer_cb+0x14(a0445eda20?,
0?, 7ed252315b30?, 1?, 8?, 1?)
    7ed252315141
libmutter-cogl-9.so.0.0.0`cogl_pipeline_foreach_layer+0x98(a0445eda20?,
7ec7648449a8?, 7ed252315b30?, 0?, 0?, a0445eda20?)
    7ed252315211
libmutter-cogl-9.so.0.0.0`_cogl_framebuffer_draw_multitextured_rectangles+0x44(a043fe86a0?,
a0445eda20?, 7ed252315c68?, 1?, a0445ed9c0?, a0445eda20?)
    7ed252315391
libmutter-cogl-9.so.0.0.0`cogl_framebuffer_draw_textured_rectangle+0x48(a043fe86a0?,
a0445eda20?, a043d52650?, a0445ed960?, a042699d90?, a0445edb20?)
    7ed252315481
libmutter-9.so.0.0.0`meta_background_get_texture+0x820(a0439c2600?, 0?,
a042b62aa4?, 7ed252315ee0?, 40000000300?, 0?)
    7ed2523155b1
libmutter-9.so.0.0.0`meta_background_content_paint_content+0x88c(7ed252315ed0?,
7ed252315ee0?, a04407c8c0?, a04426af50?, 0?, a042b62a20?)
    7ed2523156f1
libmutter-clutter-9.so.0.0.0`_clutter_content_paint_content+0x28(a042b62a20?,
a043212910?, a04407c8c0?, a04426af50?, 60?, a0432140e0?)
    7ed2523157a1
libmutter-clutter-9.so.0.0.0`clutter_actor_continue_paint+0x180(a043212910?,
a04426af50?, a0441438f0?, a04321268c?, a043212620?, a04407c8c0?)
    7ed252315871
libmutter-clutter-9.so.0.0.0`clutter_paint_node_paint+0x378(a04407c860?,
a04426af50?, 7ed252316280?, 1000?, a0441426b0?, a04407c860?)
    7ed2523159a1
libmutter-clutter-9.so.0.0.0`clutter_actor_paint+0x244(a043212910?,
a04426af50?, a04407c860?, 0?, 7ec76c700d20?, a043212620?)
    7ed252315af1
libmutter-clutter-9.so.0.0.0`clutter_actor_real_paint+0x14(a042833cc0?,
a04426af50?, 140c00?, 7ec76c400198?, a043e7e110?, a043212910?)
    7ed252315ba1
libmutter-clutter-9.so.0.0.0`clutter_stage_paint+0x28(a042833cc0?, a04426af50?,
1?, a042822920?, a0423b7100?, a0423b7100?)
    7ed252315ca1 libmutter-9.so.0.0.0`meta_stage_paint+0x50(a042833cc0?,
a04426af50?, 2?, a042833cc0?, a043e7e110?, a042399960?)
    7ed252315d51
libmutter-clutter-9.so.0.0.0`clutter_actor_continue_paint+0x1cc(a042833cc0?,
a04426af50?, a0438152f0?, a0442d8920?, a0428339d0?, a04407c800?)
    7ed252315e21
libmutter-clutter-9.so.0.0.0`clutter_paint_node_paint+0x50c(a04407af60?,
a04426af50?, 7ed252316830?, 1000?, a0441426b0?, a04407af60?)
    7ed252315f51
libmutter-clutter-9.so.0.0.0`clutter_actor_paint+0x244(a042833cc0?,
a04426af50?, a04407af60?, a0428339d0?, 7ec76c700d20?, a0428339d0?)
    7ed2523160a1
libmutter-clutter-9.so.0.0.0`clutter_stage_do_paint_view+0xf4(a042833cc0?,
a042364380?, a0442708c0?, a042827b00?, 3020?, a04426af50?)

gnome-shell:core> libgcc_s.so.1`classify_object_over_fdes+0x140::dis
libgcc_s.so.1`classify_object_over_fdes+0x118:  cmp       %g2, 0x3
libgcc_s.so.1`classify_object_over_fdes+0x11c:  bne,pn    %icc, +0x54  
<libgcc_s.so.1`classify_object_over_fdes+0x170>
libgcc_s.so.1`classify_object_over_fdes+0x120:  mov       %i2, %g1
libgcc_s.so.1`classify_object_over_fdes+0x124:  ldx       [%fp + 0x7f7], %g2
libgcc_s.so.1`classify_object_over_fdes+0x128:  and       %g2, %g1, %g1
libgcc_s.so.1`classify_object_over_fdes+0x12c:  brz,a,pn  %g1, +0x20   
<libgcc_s.so.1`classify_object_over_fdes+0x14c>
libgcc_s.so.1`classify_object_over_fdes+0x130:  mov       %l6, %g2
libgcc_s.so.1`classify_object_over_fdes+0x134:  ldx       [%i0], %g1
libgcc_s.so.1`classify_object_over_fdes+0x138:  cmp       %g1, %g2
libgcc_s.so.1`classify_object_over_fdes+0x13c:  bleu,pt   %xcc, +0xc   
<libgcc_s.so.1`classify_object_over_fdes+0x148>
libgcc_s.so.1`classify_object_over_fdes+0x140:  add       %i4, 0x1, %i4
libgcc_s.so.1`classify_object_over_fdes+0x144:  stx       %g2, [%i0]
libgcc_s.so.1`classify_object_over_fdes+0x148:  mov       %l6, %g2
libgcc_s.so.1`classify_object_over_fdes+0x14c:  srl       %i5, 0x0, %i5
libgcc_s.so.1`classify_object_over_fdes+0x150:  add       %i5, 0x4, %i5
libgcc_s.so.1`classify_object_over_fdes+0x154:  add       %i1, %i5, %i1
libgcc_s.so.1`classify_object_over_fdes+0x158:  ld        [%i1], %i5
libgcc_s.so.1`classify_object_over_fdes+0x15c:  cmp       %i5, 0x0
libgcc_s.so.1`classify_object_over_fdes+0x160:  bne,a,pt  %icc, -0x11c 
<libgcc_s.so.1`classify_object_over_fdes+0x44>
libgcc_s.so.1`classify_object_over_fdes+0x164:  ld        [%i1 + 0x4], %g1
libgcc_s.so.1`classify_object_over_fdes+0x168:  return    %i7 + 0x8

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=108994

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Are you sure this is NOT a LLVM JIT issue?
There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
side.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-08-09
             Status|UNCONFIRMED                 |WAITING

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[schwab@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
Maybe the .eh_frame section is not properly terminated, like PR 110066.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[sumbera at volny dot cz]

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

--- Comment #3 from Petr Sumbera <sumbera at volny dot cz> ---
(In reply to Andrew Pinski from comment #1)
> Are you sure this is NOT a LLVM JIT issue?
> There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
> side.

Don't really know. But the binary gnome-shell which was compiled by GCC 12
doesn't run with GCC 13 runtime.

Also when I copy gcc/libgcc/unwind-dw2-fde.(c|h) from GCC 12 to GCC 13 it
doesn't crash then.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[tneumann at users dot sourceforge.net]

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

--- Comment #4 from Thomas Neumann <tneumann at users dot sourceforge.net> ---
I am not sure what caused that, but in GCC 13 the unwinding logic now looks
into the table when registering the frame, while previously the table was only
inspected on the first exception. Which means we might notice invalid tables
earlier.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[ro at gcc dot gnu.org]

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

--- Comment #5 from Rainer Orth <ro at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Are you sure this is NOT a LLVM JIT issue?

I certainly cannot exclude that.  Currently, the Solaris LLVM build includes a
local
JIT patch that I tried to get upstream: https://reviews.llvm.org/D118450.
Unfortunately, that went nowhere in the end, but my testing discovered that
there are at least two JIT test failures that would have to be fixed before.

OTOH, the same code works with GCC 12 libgcc (but so did the aarch64 one).

> There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
> side.

It looks similar indeed.  However, AFAICS the LLVM JIT code has been
reorganized
quite a bit since my last attempt to get the SPARC code in.  Seems like quite
an amount of work to even get there...

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[ro at gcc dot gnu.org]

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

--- Comment #6 from Rainer Orth <ro at gcc dot gnu.org> ---
(In reply to Rainer Orth from comment #5)

> > There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
> > side.
> 
> It looks similar indeed.  However, AFAICS the LLVM JIT code has been
> reorganized
> quite a bit since my last attempt to get the SPARC code in.  Seems like quite
> an amount of work to even get there...

Looking closer, that's a different JIT engine: aarch64 uses the newer JITLink
one while the sparc code is based on MCJIT/RuntimeDyld.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[ro at gcc dot gnu.org]

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

--- Comment #7 from Rainer Orth <ro at gcc dot gnu.org> ---
(In reply to Petr Sumbera from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > Are you sure this is NOT a LLVM JIT issue?
> > There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
> > side.
> 
> Don't really know. But the binary gnome-shell which was compiled by GCC 12
> doesn't run with GCC 13 runtime.
> 
> Also when I copy gcc/libgcc/unwind-dw2-fde.(c|h) from GCC 12 to GCC 13 it
> doesn't crash then.

I'm not sure if we taked about this before: have you tried building SPARC LLVM
without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
until someone fixes and integrates SPARC JIT support for real.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #7 from Rainer Orth <ro at gcc dot gnu.org> ---
> (In reply to Petr Sumbera from comment #3)
>> (In reply to Andrew Pinski from comment #1)
>> > Are you sure this is NOT a LLVM JIT issue?
>> > There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
>> > side.
>> 
>> Don't really know. But the binary gnome-shell which was compiled by GCC 12
>> doesn't run with GCC 13 runtime.
>> 
>> Also when I copy gcc/libgcc/unwind-dw2-fde.(c|h) from GCC 12 to GCC 13 it
>> doesn't crash then.
>
> I'm not sure if we taked about this before: have you tried building SPARC LLVM
> without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
> until someone fixes and integrates SPARC JIT support for real.

Another question: do you have a way to reliably reproduce that SEGV?
When I run gnome-shell with X11 forwarding (i.e. without a full GNOME
session), I get this instead:

mutter-Message: 12:43:16.908: Running GNOME Shell (using mutter 41.9) as a X11
window and compositing manager

(gnome-shell:17373): GLib-GIO-ERROR **: 12:43:18.865: Settings schema
'org.gnome.mutter' is not installed
Trace/Breakpoint Trap

and under mdb (gdb gets an internal error):

mutter-Message: 12:40:24.426: Running GNOME Shell (using mutter 41.9) as a X11
window and compositing manager

(gnome-shell:17027): GLib-GIO-ERROR **: 12:40:24.547: Settings schema
'org.gnome.mutter' is not installed
mdb: stop on SIGTRAP
mdb: target stopped at:
libc.so.1`__lwp_sigqueue+8:     bcc,a,pt  %icc, +0x10  
<libc.so.1`__lwp_sigqueue+0x18>
mdb: You've got symbols!
gnome-shell:17027*> $C
    7c11b6412e71 libc.so.1`__lwp_sigqueue+8(5?, 7c11b64137d0?, 4?, 0?,
    7b107f7e2e44?, 7b107fa005b0?)
    7c11b6412f21 libglib-2.0.so.0.7000.5`g_log_default_handler+0xbc(
    7b107e48e070?, 6?, 7b76f39c00?, 0?, ffffffffffffffff?, 7b107f78cb68?)
    7c11b6413031 libglib-2.0.so.0.7000.5`g_logv+0x220(7b76f39c00?,
    7b107fa005d0?, 0?, 7b107e48e070?, 6?, 4?)
    7c11b6413141 libglib-2.0.so.0.7000.5`g_log+0x20(7b107e48e070?, 4?,
    7b107e4a1c78?, 7b76f26860?, 0?, 0?)
    7c11b6413201 libgio-2.0.so.0.7000.5`g_settings_set_property+0x170(
    7b76ee44a0?, 2?, 7c11b6413b70?, 7b76ed0de0?, 7b76ee4480?, 7b76f26860?)
    7c11b64132b1 libgobject-2.0.so.0.7000.5`g_object_new_internal+0x318(
    7b76f1e340?, 7c11b6413cc0?, 1?, 7b76ece230?, 7c11b6413cd0?, 7b76f1e340?)
    7c11b64133a1 libgobject-2.0.so.0.7000.5`g_object_new_valist+0x120(
    7b76ee4c90?, 1?, 0?, 7c11b6413cc0?, 7c11b6413dc0?, 1?)
    7c11b6413741 libgobject-2.0.so.0.7000.5`g_object_new+0x24(7b76ee4c90?,
    7b107e4a2068?, 7b107f16e340?, 0?, 0?, 0?)
    7c11b6413801 libmutter-9.so.0.0.0`meta_settings_init+0x58(7b76ee8800?,
    7b76f05db0?, ff000000?, 2946?, 7b107fe18944?, 7b107f16aad0?)
    7c11b64138b1 libgobject-2.0.so.0.7000.5`g_type_create_instance+0x1cc(
    7b76ee8800?, 0?, 7b76f05db0?, 7b76f0e2b8?, 7b76f0e270?, 7b76f0e2b8?)
    7c11b6413961 
libgobject-2.0.so.0.7000.5`g_object_new_internal.constprop.0+0x34(7b76f05db0?,
    7b107ed00250?, 0?, 0?, 0?, 7b76f0e270?)
    7c11b6413a41 libgobject-2.0.so.0.7000.5`g_object_new_with_properties+0x2a0(
    7b76f0e270?, 0?, 0?, 0?, 7b1080442a40?, 0?)
    7c11b6413af1 libgobject-2.0.so.0.7000.5`g_object_new+0x40(7b76f0e270?, 0?,
    1b3000?, 7b76f1c7b0?, 7b107fa00878?, 7b76ec4350?)
    7c11b6413bb1 libmutter-9.so.0.0.0`meta_settings_new+0x6c(7b76ee1150?,
    7b76ed3d60?, ff000000?, 7b76ed3d60?, 7b76ed2c00?, 7b76ed3d60?)
    7c11b6413c61 libmutter-9.so.0.0.0`meta_backend_initable_init+0x38(
    7b76ee1150?, 0?, 7c11b6414b88?, 7b107f4001f8?, 7b76ee1090?, 7b76ee1150?)
    7c11b6413d11 libmutter-9.so.0.0.0`meta_backend_x11_initable_init+0x104(
    7b76ee1150?, 0?, 7c11b6414b88?, 7b107f400830?, 7b76f0e270?, 7b76ee1010?)
    7c11b6413dc1 libgio-2.0.so.0.7000.5`g_initable_init+0x68(7b76ee1150?, 0?,
    7c11b6414b88?, 7c11b6414400?, 7c11b64143f8?, 7b76ee02c0?)
    7c11b6413e81 libgio-2.0.so.0.7000.5`g_initable_new_valist+0x78(
    7b76ee1150?, 7b107f16a2a8?, 7c11b6414890?, 0?, 7c11b6414b88?, 7b76ec4350?)
    7c11b6413f31 libgio-2.0.so.0.7000.5`g_initable_new+0x20(7b76ed2c00?, 0?,
    7c11b6414b88?, 7b107f16a2a8?, 7b76ed2060?, 7b107f16d178?)
    7c11b6413ff1 libmutter-9.so.0.0.0`meta_context_main_create_backend+0x80(
    7b76ed2060?, 7c11b6414b88?, 7b107f208110?, 7b107f1dcbc8?, 7b10801eb280?,
    7b76ed2060?)
    7c11b64140b1 libmutter-9.so.0.0.0`meta_context_real_setup+0x30(
    7b76ed2010?, 7c11b6414b88?, 0?, 7b76ecfd10?, 7b76ecfca0?, 7b76ecfca0?)
    7c11b6414161 libmutter-9.so.0.0.0`meta_context_main_setup+0x64(
    7b76ed2060?, 7c11b6414b88?, 7b107f176268?, 7b76ec3fb0?, 7b76ecff00?,
    7b76ed2060?)
    7c11b6414211 libmutter-9.so.0.0.0`meta_context_setup+0x168(7b76ed2060?,
    7c11b6414b88?, 103000?, 7b76ed2060?, ffffffffffffffb0?, 7b76ed2010?)
    7c11b64142c1 main+0x1ac(7c11b6414b90?, 7b76ec40b0?, 7c11b6414b88?,
    7c11b6414ba0?, 7b1080400138?, 7b76ed2060?)
    7c11b64143c1 _start+0x64(, ...)

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[sumbera at volny dot cz]

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

--- Comment #9 from Petr Sumbera <sumbera at volny dot cz> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #8)
> > I'm not sure if we taked about this before: have you tried building SPARC LLVM
> > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
> > until someone fixes and integrates SPARC JIT support for real.

I will try to build LLVM without the patch and will see. But the patch says it
was created because of gnome-shell.

> Another question: do you have a way to reliably reproduce that SEGV?
> When I run gnome-shell with X11 forwarding (i.e. without a full GNOME
> session), I get this instead:

Yes, it fails everytime one try to run vncserver on SPARC on st-152.

Maybe you need install pkg:/group/feature/multi-user-desktop?!

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #9 from Petr Sumbera <sumbera at volny dot cz> ---
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #8)
>> > I'm not sure if we taked about this before: have you tried building
>> > SPARC LLVM
>> > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
>> > until someone fixes and integrates SPARC JIT support for real.
>
> I will try to build LLVM without the patch and will see. But the patch says it
> was created because of gnome-shell.

Fine, thanks.

>> Another question: do you have a way to reliably reproduce that SEGV?
>> When I run gnome-shell with X11 forwarding (i.e. without a full GNOME
>> session), I get this instead:
>
> Yes, it fails everytime one try to run vncserver on SPARC on st-152.
>
> Maybe you need install pkg:/group/feature/multi-user-desktop?!

I'm a bit reluctant to do so, honestly.  The gnome-shell installation
already dragged in almost 100 packages I don't need on that system.
Perhaps do it in a scratch local zone instead...

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #9 from Petr Sumbera <sumbera at volny dot cz> ---
>> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #8)
>>> > I'm not sure if we taked about this before: have you tried building
>>> > SPARC LLVM
>>> > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
>>> > until someone fixes and integrates SPARC JIT support for real.
>>
>> I will try to build LLVM without the patch and will see. But the patch says it
>> was created because of gnome-shell.
>
> Fine, thanks.

I think I re-discovered what's going on: gnome-shell (directly or
indirectly) seems to depend on mesa, which again has a hard dependency on
LLVM's MCJIT in src/gallium/auxiliary/gallivm/lp_bld_{init,misc}.*.
What a mess...

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[sumbera at volny dot cz]

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

--- Comment #12 from Petr Sumbera <sumbera at volny dot cz> ---
(In reply to Petr Sumbera from comment #9)
> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #8)
> > > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
> > > until someone fixes and integrates SPARC JIT support for real.
> 
> I will try to build LLVM without the patch and will see. But the patch says
> it
> was created because of gnome-shell.

When I updated test system with LLVM built without 033-solaris-LLVM-JIT.patch
(without rebuilding any other component) it fails in different way (probably
earlier). See bellow. I think that the patch is really needed.

    7e0fbf09e3d1 libc.so.1`__lwp_sigqueue+8(6?, 2012d400?, 0?, 9697d5d9b0?,
9697d50170?, 0?)
    7e0fbf09e481 dump_gjs_stack_on_signal_handler+0xb4(6?, 0?, 7e0fbf09f060?,
0?, 7af3c050012c?, 49?)
    7e0fbf09e551 libc.so.1`__sighndlr+0xc(6?, 0?, 7e0fbf09f060?, 7af3c0303624?,
0?, 7af3bff0c7c8?)
    7e0fbf09e601 libc.so.1`call_user_handler+0x400((int) 0?, (siginfo_t *) 0?,
(ucontext_t *) 0x12?)
    7e0fbf09e6f1 libc.so.1`sigacthandler+0xd0((int) 6?, (siginfo_t *) 0?, (void
*) 0x7e0fbf09f060?)
    7e0fbf09eb41 libc.so.1`__lwp_sigqueue+8(6?, 6?, 7e0fbf09f4c0?, 0?, 0?, 0?)
    7e0fbf09ebf1 libc.so.1`abort+0xb4()
    7e0fbf09ecd1
libLLVM-13.so`_ZN4llvm18report_fatal_errorERKNS_5TwineEb+0xb4(7e0fbf09f6e0?,
1?, 1?, 0?, 0?, 7e0fbf09f588?)
    7e0fbf09ee31
libLLVM-13.so`_ZN4llvm18report_fatal_errorEPKcb+0x5c(7af3b1eb0168?, 1?, 0?, 1?,
9699b1b788?, 9699b1b690?)
    7e0fbf09ef11
libLLVM-13.so`_ZN4llvm14RuntimeDyldELF23resolveX86_64RelocationERKNS_12SectionEntryEmmjlm+0x64(969a060b00?,
9699f673c0?, 20?, 7af3bfb12000?, 18?, 0?)
    7e0fbf09efd1
libLLVM-13.so`_ZN4llvm14RuntimeDyldELF17resolveRelocationERKNS_12SectionEntryEmmjlmj+0x6c(969a060b00?,
9699f673c0?, 20?, 7af3bfb12000?, 6?, 0?)
    7e0fbf09f0a1
libLLVM-13.so`_ZN4llvm14RuntimeDyldELF17resolveRelocationERKNS_15RelocationEntryEm+0xd8(969a060b00?,
9699f6b6d0?, 7af3bfb12000?, 9699b28a40?, 0?,
    9699b166e8?)
    7e0fbf09f171
libLLVM-13.so`_ZN4llvm15RuntimeDyldImpl21resolveRelocationListERKNS_11SmallVectorINS_15RelocationEntryELj64EEEm+0xa4(969a060b00?,
9699f6b6c0?,
    7af3bfb12000?, 9699b166e8?, 70?, 0?)
    7e0fbf09f231
libLLVM-13.so`_ZN4llvm15RuntimeDyldImpl23resolveLocalRelocationsEv+0x8c(969a060b00?,
0?, 0?, 9699b166e8?, 0?, 9699f6b6b0?)
    7e0fbf09f2f1
libLLVM-13.so`_ZN4llvm15RuntimeDyldImpl18resolveRelocationsEv+0x200(969a060b00?,
1?, 0?, 0?, 1?, 969a060bf0?)
    7e0fbf09f3e1
libLLVM-13.so`_ZN4llvm11RuntimeDyld18resolveRelocationsEv+0x30(9699b1b6f0?, 6?,
1?, 0?, 9699b1b690?, 0?)
    7e0fbf09f4a1
libLLVM-13.so`_ZN4llvm5MCJIT21finalizeLoadedModulesEv+0x60(9699b1b420?,
9699b1b6f0?, 0?, 1?, 9699b1b788?, 9699b1b690?)
    7e0fbf09f5b1
libLLVM-13.so`_ZN4llvm5MCJIT14finalizeObjectEv+0x290(9699b1b420?, 9699b1b748?,
7e0fbf09fe60?, 9699b1b770?, 7e0fbf09fea0?, 7e0fbf09fea0?)
    7e0fbf09f721 libLLVM-13.so`LLVMGetPointerToGlobal+0x38(9699b1b420?,
9699b12078?, 291c00?, 0?, 0?, 336?)
    7e0fbf09f7e1 swrast_dri.so`llvmpipe_update_fs+0xe94(96978b7d00?,
9699b0b344?, 969793d560?, 9697b91a40?, 9699b0b290?, 0?)
..

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #12 from Petr Sumbera <sumbera at volny dot cz> ---
> (In reply to Petr Sumbera from comment #9)
>> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #8)
>> > > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
>> > > until someone fixes and integrates SPARC JIT support for real.
>> 
>> I will try to build LLVM without the patch and will see. But the patch says
>> it
>> was created because of gnome-shell.
>
> When I updated test system with LLVM built without 033-solaris-LLVM-JIT.patch
> (without rebuilding any other component) it fails in different way (probably
> earlier). See bellow. I think that the patch is really needed.
[...]
> libLLVM-13.so`_ZN4llvm14RuntimeDyldELF23resolveX86_64RelocationERKNS_12SectionEntryEmmjlm+0x64(969a060b00?,
> 9699f673c0?, 20?, 7af3bfb12000?, 18?, 0?)

Seems so.  Calling llvm::RuntimeDyldELF::resolveX86_64Relocation on a
SPARC ELF file is obviously complete bullshit.  Might be something
already fixed in newer LLVM versions.  Somehow, the architecture
detection is amiss...

However, given my impression from the mesa code is that even a proper
error handling in RuntimeDyLD wouldn't help there.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #12 from Petr Sumbera <sumbera at volny dot cz> ---
>> (In reply to Petr Sumbera from comment #9)
>>> (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #8)
>>> > > without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
>>> > > until someone fixes and integrates SPARC JIT support for real.
>>> 
>>> I will try to build LLVM without the patch and will see. But the patch says
>>> it
>>> was created because of gnome-shell.
>>
>> When I updated test system with LLVM built without 033-solaris-LLVM-JIT.patch
>> (without rebuilding any other component) it fails in different way (probably
>> earlier). See bellow. I think that the patch is really needed.
> [...]
>> libLLVM-13.so`_ZN4llvm14RuntimeDyldELF23resolveX86_64RelocationERKNS_12SectionEntryEmmjlm+0x64(969a060b00?,
>> 9699f673c0?, 20?, 7af3bfb12000?, 18?, 0?)
>
> Seems so.  Calling llvm::RuntimeDyldELF::resolveX86_64Relocation on a
> SPARC ELF file is obviously complete bullshit.  Might be something
> already fixed in newer LLVM versions.  Somehow, the architecture
> detection is amiss...

That's almost certainly due to Solaris still including LLVM 13, which is
pretty old by now.  In particular, it lacks llvm::sys::getHostCPUName.
My patch to implement this on SPARC only landed in LLVM 16.

> However, given my impression from the mesa code is that even a proper
> error handling in RuntimeDyLD wouldn't help there.

Mesa uses the same function, so this may well be a second instance of
the same problem.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> ---
> --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
> Uni-Bielefeld.DE> ---
>> --- Comment #7 from Rainer Orth <ro at gcc dot gnu.org> ---
>> (In reply to Petr Sumbera from comment #3)
>>> (In reply to Andrew Pinski from comment #1)
>>> > Are you sure this is NOT a LLVM JIT issue?
>>> > There was a similar issue on aarch64 too; PR 108994 which was fixed in LLVM
>>> > side.
>>> 
>>> Don't really know. But the binary gnome-shell which was compiled by GCC 12
>>> doesn't run with GCC 13 runtime.
>>> 
>>> Also when I copy gcc/libgcc/unwind-dw2-fde.(c|h) from GCC 12 to GCC 13 it
>>> doesn't crash then.
>>
>> I'm not sure if we taked about this before: have you tried building SPARC LLVM
>> without the JIT patch (033-solaris-LLVM-JIT.patch)?  It may be worth a try
>> until someone fixes and integrates SPARC JIT support for real.
>
> Another question: do you have a way to reliably reproduce that SEGV?
> When I run gnome-shell with X11 forwarding (i.e. without a full GNOME
> session), I get this instead:

I've now done some more digging and found a way to reproduce the issue
without gnome-shell.

To do this, I refreshed the SPARC RuntimeDyLD patch to apply to current
LLVM main.  Then I built and ran the whole thing with both GCC 13 and
GCC 12 (and the corresponding versions of libgcc_s.so.1).  The set of
failures is almost the same between those two trials, however the exact
error conditions vary.  I've now got some of the failing tests that fail
in classify_object_over_fdes with GCC 13, but run into SIGILL with GCC
12. 
clang/unittests/Interpreter/ExceptionTests/./ClangReplInterpreterExceptionTests
is an example:

* GCC 13:

0  ClangReplInterpreterExceptionTests 0x0000000102561a6c
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 36
1  ClangReplInterpreterExceptionTests 0x000000010256234c SignalHandler(int) +
896
2  libc.so.1                          0xffffffff7eec57c8 __sighndlr + 12
3  libc.so.1                          0xffffffff7eeb8070 call_user_handler +
1024
4  libc.so.1                          0xffffffff7eeb8430 sigacthandler + 160
5  libc.so.1                          0xffffffff7edd7ab8 strlen + 24
6  libgcc_s.so.1                      0xffffffff383127a4
classify_object_over_fdes + 96
7  libgcc_s.so.1                      0xffffffff383132a8
__register_frame_info_bases + 72
8  ClangReplInterpreterExceptionTests 0x0000000102c10ff4
llvm::RTDyldMemoryManager::registerEHFrames(unsigned char*, unsigned long,
unsigned long) + 20
9  ClangReplInterpreterExceptionTests 0x0000000102c299b4
llvm::RuntimeDyldELF::registerEHFrames() + 144
10 ClangReplInterpreterExceptionTests 0x0000000102c1c608
llvm::RuntimeDyldImpl::finalizeAsync(std::unique_ptr<llvm::RuntimeDyldImpl,
std::default_delete<llvm::RuntimeDyldImpl>>, llvm::unique_function<void
(llvm::object::OwningBinary<llvm::object::ObjectFile>,
std::unique_ptr<llvm::RuntimeDyld::LoadedObjectInfo,
std::default_delete<llvm::RuntimeDyld::LoadedObjectInfo>>, llvm::Error)>,
llvm::object::OwningBinary<llvm::object::ObjectFile>,
std::unique_ptr<llvm::RuntimeDyld::LoadedObjectInfo,
std::default_delete<llvm::RuntimeDyld::LoadedObjectInfo>>)::$_0::operator()(llvm::Expected<std::map<llvm::StringRef,
llvm::JITEvaluatedSymbol, std::less<llvm::StringRef>,
std::allocator<std::pair<llvm::StringRef const, llvm::JITEvaluatedSymbol>>>>) +
348
[...]

* GCC 12:

0  ClangReplInterpreterExceptionTests 0x0000000102561b4c
llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) + 36
1  ClangReplInterpreterExceptionTests 0x000000010256242c SignalHandler(int) +
896
2  libc.so.1                          0xffffffff7e2c57c8 __sighndlr + 12
3  libc.so.1                          0xffffffff7e2b8070 call_user_handler +
1024
4  libc.so.1                          0xffffffff7e2b8460 sigacthandler + 208
5  libc.so.1                          0xffffffff7f5ec508 sigacthandler +
20136312
6  libc.so.1                          0xffffffff7f5ec01c sigacthandler +
20135052
7  ClangReplInterpreterExceptionTests 0x000000010213b308 (anonymous
namespace)::InterpreterTest_CatchException_Test::TestBody() + 1884
8  ClangReplInterpreterExceptionTests 0x000000010257f198 testing::Test::Run() +
432
[...]

So there was definitely something amiss before, only exact failure mode
changed with GCC 13.

Definitely easier to investigate than gnome-shell, but still pretty much
a nightmare.

[Bug libgcc/110955] SIGSEGV in libgcc_s.so.1`classify_object_over_fdes+0x140 on Solaris SPARC with GCC 13 runtime

[sumbera at volny dot cz]

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

--- Comment #16 from Petr Sumbera <sumbera at volny dot cz> ---
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #14)
> That's almost certainly due to Solaris still including LLVM 13, which is
> pretty old by now.  In particular, it lacks llvm::sys::getHostCPUName.
> My patch to implement this on SPARC only landed in LLVM 16.

LLVM update is quite complicated due Mesa dependency. But main update blocker
is now: https://bugzilla.mozilla.org/show_bug.cgi?id=1795899