From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DFF903858D35; Mon, 8 May 2023 21:02:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DFF903858D35 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1683579737; bh=2YuenzDWppp3G75rAJI79a7dEAOgBunfwd/yimh6u5Q=; h=From:To:Subject:Date:From; b=BuoFlsjRnSBCkn+wEYTdInI0oUPQa9dO37/6SHC2Hl4ZrhIvdEL/xpWp+ro5l3Pj2 VczGuk+G2A/3lQnM2homd47hJjlXHaypE7H0UUSVEGCA0laZqSMZTynQKHp+WWvoRh +xmJTDrGmEAMw32YNvwHqXrQCrjysJOxCgyHM5EY= From: "mikeowens at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug c++/30430] New: SIGABRT on run (Illumos on SPARC) Date: Mon, 08 May 2023 21:02:17 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: c++ X-Bugzilla-Version: 13.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mikeowens at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30430 Bug ID: 30430 Summary: SIGABRT on run (Illumos on SPARC) Product: gdb Version: 13.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ Assignee: unassigned at sourceware dot org Reporter: mikeowens at gmail dot com Target Milestone: --- This is specifically a SPARC issue. I am running the latest OpenIndiana on a T4-1. I can provide SSH access to the machine to assist anyone willing to h= elp with this bug. I experience the following problem with every version of gdb I can get: 10.= 1, 12.1-202, 13.1. No matter how simple the program, the moment I start it to debug I get the = same result. Here is a simple case. I use the following program: int main() { return 0; } Compile as follows: g++ -ggdb test.cpp The gcc version is 11.3.0 (OpenIndiana 11.3.0-oi-4) Then I run gdb as follows: # $ gdb a.out Exception caught while booting Guile. Error in function "load-thunk-from-memory": ELF file does not have native word size /usr/local/bin/gdb: warning: Could not complete Guile gdb module initialization from: /usr/local/share/gdb/guile/gdb/boot.scm. Limited Guile support is available. Suggest passing --data-directory=3D/path/to/gdb/data-directory. GNU gdb (GDB) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.11". Type "show configuration" for configuration details. For bug reporting instructions, please see: . Find the GDB manual and other documentation resources online at: . For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /var/data/tmp/a.out... (gdb) run Starting program: /tmp/a.out [Thread debugging using libthread_db enabled] Fatal signal: Abort ----- Backtrace ----- Abort (core dumped) If I run mbd on the core file I get no useful information: # mdb core Loading modules: [ libc.so.1 ld.so.1 ] > $C mdb: failed to get current register set: invalid thread identifier When I run truss I see the following: /1: open("/lib/64/libc.so.1", O_RDONLY) =3D 18 /1: fcntl(18, F_GETFD, 0x00000000) =3D 0 /1: fcntl(18, F_SETFD, 0x00000001) =3D 0 /1: lseek(18, 1467912, SEEK_SET) =3D 1467912 /1: fstat(18, 0xFFFFFFFF7FFF9760) =3D 0 /1: fstat(18, 0xFFFFFFFF7FFF9580) =3D 0 /1: ioctl(18, TCGETA, 0xFFFFFFFF7FFF969E) Err#25 ENOTTY /1: read(18, "7F D O F02020102\b\b\0\0".., 131072) =3D 131072 /1: open("/var/data/tmp/a.out", O_RDONLY) =3D 20 /1: fcntl(20, F_GETFD, 0x00000000) =3D 0 /1: fcntl(20, F_SETFD, 0x00000001) =3D 0 /1: lseek(20, 4328, SEEK_SET) =3D 4328 /1: fstat(20, 0xFFFFFFFF7FFF5F70) =3D 0 /1: fstat(20, 0xFFFFFFFF7FFF5D90) =3D 0 /1: ioctl(20, TCGETA, 0xFFFFFFFF7FFF5EAE) Err#25 ENOTTY /1: read(20, "\0\0\0\0\0\0\001\0\0\0\0".., 10752) =3D 6024 /1: lseek(17, 0, SEEK_SET) =3D 0 /1: read(17, "\t \003\0\0\001\006\003".., 1392) =3D 1392 /1: lseek(19, 4294967360, SEEK_SET) =3D 4294967360 /1: read(19, "\0\0\006\0\0\005\0\0\0\0".., 56) =3D 56 /1: lseek(17, 0, SEEK_SET) =3D 0 /1: read(17, "\t \003\0\0\001\006\003".., 1392) =3D 1392 /1: lseek(19, 4294967416, SEEK_SET) =3D 4294967416 /1: read(19, "\0\0\003\0\0\004\0\0\0\0".., 56) =3D 56 /1: lseek(17, 0, SEEK_SET) =3D 0 /1: read(17, "\t \003\0\0\001\006\003".., 1392) =3D 1392 /1: lseek(19, 4294967472, SEEK_SET) =3D 4294967472 /1: read(19, "\0\0\001\0\0\005\0\0\0\0".., 56) =3D 56 /1: lseek(17, 0, SEEK_SET) =3D 0 ... /1: read(20, "\0\0\0\0\0\0\001\0\0\0\0".., 10752) =3D 6024 /1: lseek(17, 0, SEEK_SET) =3D 0 /1: read(17, "\t \003\0\0\001\006\003".., 1392) =3D 1392 /1: lseek(19, 4296020768, SEEK_SET) =3D 4296020768 /1: read(19, "FFFFFFFF `84 \0", 8) =3D 8 /1: sigaction(SIGABRT, 0x00000000, 0xFFFFFFFF7FFF5820) =3D 0 /1: lwp_kill(1, SIGABRT) =3D 0 /1: Received signal #6, SIGABRT [caught] /1: siginfo: SIGABRT pid=3D20069 uid=3D100 code=3D-1 /1: lwp_sigmask(SIG_SETMASK, 0x00000000, 0x00000000, 0x00000000, 0x00000000) =3D 0xFFBFFEFF [0xFFFFFFFF] I get this exact same error on every version of gdb I test with. I understand that SPARC is a dead platform, but thankfully it seems that gdb still has theoretical support for it. The code built cleanly from source. Y= ou can still get really good deals on SPARC hardware and I would love to be ab= le to use this system for a long time to come. But without a working debugger, th= is system is utterly useless. Like I said, I can provide direct access to the machine for anyone willing = to work on the issue. It's a great machine with 250GB RAM and 64 cores. It's a= lot of fun to work on it. And I have pkgsrc set up on it so I can build any additional tools that might be helpful. --=20 You are receiving this mail because: You are on the CC list for the bug.=