NetBSD Problem Report #56153

From www@netbsd.org  Fri May  7 12:37:25 2021
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7174E1A9262
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  7 May 2021 12:37:25 +0000 (UTC)
Message-Id: <20210507123723.99CB91A9263@mollari.NetBSD.org>
Date: Fri,  7 May 2021 12:37:23 +0000 (UTC)
From: rokuyama.rk@gmail.com
Reply-To: rokuyama.rk@gmail.com
To: gnats-bugs@NetBSD.org
Subject: gdb is broken for alpha
X-Send-Pr-Version: www-1.0

>Number:         56153
>Category:       port-alpha
>Synopsis:       gdb is broken for alpha
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    thorpej
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 07 12:40:01 +0000 2021
>Closed-Date:    Wed Jul 07 05:33:33 +0000 2021
>Last-Modified:  Wed Jul 07 05:33:33 +0000 2021
>Originator:     Rin Okuyama
>Release:        9.99.82
>Organization:
Department of Physics, Meiji University
>Environment:
NetBSD ds10 9.99.82 NetBSD 9.99.82 (GENERIC-$Revision: 1.410 $) #52: Fri May  7 19:53:47 JST 2021  rin@latipes:/sys/arch/alpha/compile/DS10 alpha
>Description:
gdb is broken for alpha. It cannot even load cat.core:

----
ds10$ cat
^\[1]   Quit (core dumped)      cat
ds10$ gdb cat cat.core
GNU gdb (GDB) 11.0.50.20200914-git
...(snip)...
Reading symbols from cat...
Reading symbols from /usr/libdata/debug//bin/cat.debug...
[New process 18637]
[1]   Abort trap (core dumped) gdb cat cat.core
----

Backtrace by gdb.old reads:

----
ds10$ ./gdb.old gdb gdb.core
GNU gdb (GDB) 8.3
...(snip)...
Type "apropos word" to search for commands related to "word"...
Reading symbols from gdb...
Reading symbols from /usr/libdata/debug//usr/bin/gdb.debug...
[New process 6099]
[New process 5797]
Core was generated by `gdb'.
Program terminated with signal SIGABRT, Aborted.
#0  0x000003fffd9365d8 in _lwp_kill () from /usr/lib/libc.so.12
[Current thread is 1 (process 6099)]
(gdb) bt
#0  0x000003fffd9365d8 in _lwp_kill () from /usr/lib/libc.so.12
#1  0x000003fffd936568 in raise (s=<optimized out>)
    at /usr/src/lib/libc/gen/raise.c:48
#2  0x000003fffd936964 in abort () at /usr/src/lib/libc/stdlib/abort.c:74
#3  0x000000012004c118 in handle_sigsegv (sig=<optimized out>)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/event-top.c:885
#4  <signal handler called>
#5  atomic_load_p (mo=atomic_memory_order_relaxed, a=0x3fff8)
    at /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/atomic_gcc_atomic.h:31
#6  rtree_leaf_elm_bits_read (dependent=true, elm=0x3fff8,
    rtree=<optimized out>, tsdn=<optimized out>)
    at /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/rtree.h:175
#7  rtree_szind_slab_read (r_slab=<synthetic pointer>,
    r_szind=<synthetic pointer>, dependent=true, key=8589928040,
    rtree_ctx=0x3fffde9a468, rtree=<optimized out>, tsdn=<optimized out>)
    at /usr/src/external/bsd/jemalloc/lib/../include/jemalloc/internal/rtree.h:464
#8  ifree (slow_path=false, tcache=0x3fffde9a600, ptr=0x1ffffe668,
    tsd=<optimized out>)
    at /usr/src/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2243
#9  free (ptr=0x1ffffe668)
    at /usr/src/external/bsd/jemalloc/lib/../dist/src/jemalloc.c:2433
#10 0x000000012055b4a8 in freea (p=0x1)
    at /usr/src/external/gpl3/gdb/lib/libgnulib/../../dist/gnulib/import/malloca.c:95
#11 0x000000012055ad54 in rpl_realpath (name=<optimized out>,
    resolved=<optimized out>)
    at /usr/src/external/gpl3/gdb/lib/libgnulib/../../dist/gnulib/import/canonicalize-lgpl.c:379
#12 0x000000012052a31c in gdb_realpath (filename=0x3fffde9a568 "")
    at /usr/src/external/gpl3/gdb/lib/libgdbsupport/../../dist/gdbsupport/pathstuff.cc:72
#13 0x00000001202157fc in openp (path=<optimized out>, opts=...,
    string=<optimized out>, mode=<optimized out>,
    filename_opened=<optimized out>)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/source.c:916
#14 0x00000001201fc83c in symfile_bfd_open (
    name=0x3fffd5da040 "/usr/libdata/debug//lib/libc.so.12.218.debug")
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdbsupport/enum-flags.h:193
#15 0x000000012039c688 in elf_symfile_read (objfile=0x3fffd6db900,
    symfile_flags=...)
    at /build/dest/alpha/usr/include/g++/bits/basic_string.h:2299
#16 0x0000000120202d7c in read_symbols (objfile=0x3fffde9a578, add_flags=...)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/symfile.c:781
--Type <RET> for more, q to quit, c to continue without paging--
#17 0x00000001202023d0 in syms_from_objfile_1 (add_flags=...,
    addrs=0x1fffff318, objfile=0x3fffd6db900)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/symfile.c:978
#18 syms_from_objfile (add_flags=..., addrs=<optimized out>,
    objfile=0x3fffd6db900)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/symfile.c:995
#19 symbol_file_add_with_addrs (abfd=<optimized out>,
    name=0x3fffd682a10 "/lib/libc.so.12", add_flags=...,
    addrs=<optimized out>, flags=..., parent=<optimized out>)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/symfile.c:1098
#20 0x000000012021f20c in solib_read_symbols (so=0x3fffd682800, flags=...)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdbsupport/enum-flags.h:125
#21 0x0000000120220d54 in solib_add (pattern=0x0, from_tty=<optimized out>,
    readsyms=<optimized out>)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/solib.c:1010
#22 0x00000001200188b4 in post_create_inferior (target=0x3fffd513da0,
    from_tty=<optimized out>)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/infcmd.c:334
#23 0x00000001200963ac in core_target_open (arg=<optimized out>,
    from_tty=<optimized out>)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/corelow.c:521
#24 0x000000012000c468 in catch_command_errors (
    command=0x3fffd931534 <memmove>, arg=0x0, from_tty=0)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/main.c:457
#25 0x000000012000f4c0 in captured_main_1 (context=<optimized out>)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/main.c:1167
#26 0x000000012000fa80 in captured_main (data=0x3fffde9a578)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/main.c:1268
#27 gdb_main (args=0x3fffde9a578)
    at /usr/src/external/gpl3/gdb/lib/libgdb/../../dist/gdb/main.c:1268
#28 0x00000001205c1a34 in main (argc=1, argv=0x3fffde9a568)
    at /usr/src/external/gpl3/gdb/bin/gdb/../../dist/gdb/gdb.c:32
Warning: the current language does not match this frame.
(gdb)
----
>How-To-Repeat:
Described above.
>Fix:
N/A

>Release-Note:

>Audit-Trail:
From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: toolchain-manager@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: toolchain/56153: gdb is broken for alpha
Date: Fri, 7 May 2021 09:16:33 -0400

 --Apple-Mail=_144A71E5-2518-406C-9DAF-0BB12F9280EC
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=us-ascii

 Looks like a memory allocation issue, can you run with the debugging =
 flags for jemalloc or link with a different memory allocator?
 Perhaps this is a generic alpha jemalloc bug.

 christos

 --Apple-Mail=_144A71E5-2518-406C-9DAF-0BB12F9280EC
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 	filename=signature.asc
 Content-Type: application/pgp-signature;
 	name=signature.asc
 Content-Description: Message signed with OpenPGP

 -----BEGIN PGP SIGNATURE-----
 Comment: GPGTools - http://gpgtools.org

 iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYJU9sQAKCRBxESqxbLM7
 OiDmAKDz8gGVrblMAiir67mK/5DtBE54DwCeLMlP83ZnudLO2MGc0JTSADVkmXE=
 =DX5U
 -----END PGP SIGNATURE-----

 --Apple-Mail=_144A71E5-2518-406C-9DAF-0BB12F9280EC--

From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Christos Zoulas <christos@zoulas.com>, gnats-bugs@netbsd.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: toolchain/56153: gdb is broken for alpha
Date: Fri, 7 May 2021 22:45:40 +0900

 On 2021/05/07 22:16, Christos Zoulas wrote:
 > Looks like a memory allocation issue, can you run with the debugging flags for jemalloc or link with a different memory allocator?
 > Perhaps this is a generic alpha jemalloc bug.

 Hmm, (1)-(3) below results in the same crash for ``gdb cat cat.core''.

 (1) Replace libc with that with old jemalloc by LD_LIBRARY_PATH
 (2) Set LD_PRELOAD=/usr/lib/libbsdmalloc.so
 (3) Set LD_PRELOAD=/usr/lib/libgnumalloc.so

 With libc built with -DJEMALLOC_DEBUG:

 ----
 $ LD_LIBRARY_PATH=~/jemalloc_debug gdb cat cat.core
 GNU gdb (GDB) 11.0.50.20200914-git
 ...(snip)...
 Reading symbols from cat...
 Reading symbols from /usr/libdata/debug//bin/cat.debug...
 [New process 18637]
 <jemalloc>: /usr/src/external/bsd/jemalloc/lib/../dist/src/rtree.c:205: Failed assertion: "!dependent || leaf != NULL"
 [1]   Abort trap (core dumped) LD_LIBRARY_PATH=~/jemalloc_debug gdb cat cat.core
 ----

 Thanks,
 rin

From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: toolchain-manager@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 rokuyama.rk@gmail.com
Subject: Re: toolchain/56153: gdb is broken for alpha
Date: Fri, 7 May 2021 10:03:39 -0400

 --Apple-Mail=_D5A3BB99-822F-48B5-A725-067060F74FEF
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=us-ascii


 >=20
 > Hmm, (1)-(3) below results in the same crash for ``gdb cat cat.core''.
 >=20
 > (1) Replace libc with that with old jemalloc by LD_LIBRARY_PATH
 > (2) Set LD_PRELOAD=3D/usr/lib/libbsdmalloc.so
 > (3) Set LD_PRELOAD=3D/usr/lib/libgnumalloc.so

 By the same crash you mean in the same free call or the same jemalloc =
 stack trace?

 >=20
 > With libc built with -DJEMALLOC_DEBUG:
 >=20
 > ----
 > $ LD_LIBRARY_PATH=3D~/jemalloc_debug gdb cat cat.core
 > GNU gdb (GDB) 11.0.50.20200914-git
 > ...(snip)...
 > Reading symbols from cat...
 > Reading symbols from /usr/libdata/debug//bin/cat.debug...
 > [New process 18637]
 > <jemalloc>: =
 /usr/src/external/bsd/jemalloc/lib/../dist/src/rtree.c:205: Failed =
 assertion: "!dependent || leaf !=3D NULL"
 > [1]   Abort trap (core dumped) LD_LIBRARY_PATH=3D~/jemalloc_debug gdb =
 cat cat.core
 >=20

 That seems like the tree data structure is corrupted? Multiple frees? =
 But it should have caught that.

 christos


 --Apple-Mail=_D5A3BB99-822F-48B5-A725-067060F74FEF
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 	filename=signature.asc
 Content-Type: application/pgp-signature;
 	name=signature.asc
 Content-Description: Message signed with OpenPGP

 -----BEGIN PGP SIGNATURE-----
 Comment: GPGTools - http://gpgtools.org

 iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYJVIuwAKCRBxESqxbLM7
 OhX2AKDDM5czJmyl3WKgeNnUebWWaoGkwQCghHval8uj6Xy0+dbABHHk65JBTUQ=
 =hypZ
 -----END PGP SIGNATURE-----

 --Apple-Mail=_D5A3BB99-822F-48B5-A725-067060F74FEF--

From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: toolchain-manager@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 rokuyama.rk@gmail.com
Subject: Re: toolchain/56153: gdb is broken for alpha
Date: Fri, 7 May 2021 10:17:44 -0400

 --Apple-Mail=_7DEA87DD-34C9-4494-8ADE-06DB36976398
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=us-ascii

 Can you try undef'ing all the HAVE_ALLOCA?

 [10:15am] 224>find . -name \*.h -exec grep HAVE_ALLOCA {} + | grep alpha
 ./libbfd/arch/alpha/config.h:/* #undef HAVE_ALLOCA_H */
 ./libgdb/arch/alpha/config.h:#define HAVE_ALLOCA 1
 ./libgdb/arch/alpha/config.h:/* #undef HAVE_ALLOCA_H */
 ./libiberty/arch/alpha/config.h:/* #undef HAVE_ALLOCA_H */
 ./libgdbsupport/arch/alpha/gdbsupport/config.h:#define HAVE_ALLOCA 1
 ./libgdbsupport/arch/alpha/gdbsupport/config.h:/* #undef HAVE_ALLOCA_H =
 */
 ./libgnulib/arch/alpha/gnulib/config.h:#define HAVE_ALLOCA 1
 ./libgnulib/arch/alpha/gnulib/config.h:/* #undef HAVE_ALLOCA_H */

 christos

 > On May 7, 2021, at 10:05 AM, Christos Zoulas <christos@zoulas.com> =
 wrote:
 >=20
 > The following reply was made to PR toolchain/56153; it has been noted =
 by GNATS.
 >=20
 > From: Christos Zoulas <christos@zoulas.com>
 > To: gnats-bugs@netbsd.org
 > Cc: toolchain-manager@netbsd.org,
 > gnats-admin@netbsd.org,
 > netbsd-bugs@netbsd.org,
 > rokuyama.rk@gmail.com
 > Subject: Re: toolchain/56153: gdb is broken for alpha
 > Date: Fri, 7 May 2021 10:03:39 -0400
 >=20
 > --Apple-Mail=3D_D5A3BB99-822F-48B5-A725-067060F74FEF
 > Content-Transfer-Encoding: quoted-printable
 > Content-Type: text/plain;
 > 	charset=3Dus-ascii
 >=20
 >=20
 >> =3D20
 >> Hmm, (1)-(3) below results in the same crash for ``gdb cat =
 cat.core''.
 >> =3D20
 >> (1) Replace libc with that with old jemalloc by LD_LIBRARY_PATH
 >> (2) Set LD_PRELOAD=3D3D/usr/lib/libbsdmalloc.so
 >> (3) Set LD_PRELOAD=3D3D/usr/lib/libgnumalloc.so
 >=20
 > By the same crash you mean in the same free call or the same jemalloc =
 =3D
 > stack trace?
 >=20
 >> =3D20
 >> With libc built with -DJEMALLOC_DEBUG:
 >> =3D20
 >> ----
 >> $ LD_LIBRARY_PATH=3D3D~/jemalloc_debug gdb cat cat.core
 >> GNU gdb (GDB) 11.0.50.20200914-git
 >> ...(snip)...
 >> Reading symbols from cat...
 >> Reading symbols from /usr/libdata/debug//bin/cat.debug...
 >> [New process 18637]
 >> <jemalloc>: =3D
 > /usr/src/external/bsd/jemalloc/lib/../dist/src/rtree.c:205: Failed =3D
 > assertion: "!dependent || leaf !=3D3D NULL"
 >> [1]   Abort trap (core dumped) LD_LIBRARY_PATH=3D3D~/jemalloc_debug =
 gdb =3D
 > cat cat.core
 >> =3D20
 >=20
 > That seems like the tree data structure is corrupted? Multiple frees? =
 =3D
 > But it should have caught that.
 >=20
 > christos
 >=20
 >=20
 > --Apple-Mail=3D_D5A3BB99-822F-48B5-A725-067060F74FEF
 > Content-Transfer-Encoding: 7bit
 > Content-Disposition: attachment;
 > 	filename=3Dsignature.asc
 > Content-Type: application/pgp-signature;
 > 	name=3Dsignature.asc
 > Content-Description: Message signed with OpenPGP
 >=20
 > -----BEGIN PGP SIGNATURE-----
 > Comment: GPGTools - http://gpgtools.org
 >=20
 > iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYJVIuwAKCRBxESqxbLM7
 > OhX2AKDDM5czJmyl3WKgeNnUebWWaoGkwQCghHval8uj6Xy0+dbABHHk65JBTUQ=3D
 > =3DhypZ
 > -----END PGP SIGNATURE-----
 >=20
 > --Apple-Mail=3D_D5A3BB99-822F-48B5-A725-067060F74FEF--
 >=20


 --Apple-Mail=_7DEA87DD-34C9-4494-8ADE-06DB36976398
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 	filename=signature.asc
 Content-Type: application/pgp-signature;
 	name=signature.asc
 Content-Description: Message signed with OpenPGP

 -----BEGIN PGP SIGNATURE-----
 Comment: GPGTools - http://gpgtools.org

 iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYJVMCAAKCRBxESqxbLM7
 OoFoAJ9cJkVCaohiat69CoEjd+ZX8r6G2QCeOHJO94Bz+Y3DDd80Lqw+Urbgl7U=
 =6BXN
 -----END PGP SIGNATURE-----

 --Apple-Mail=_7DEA87DD-34C9-4494-8ADE-06DB36976398--

From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Christos Zoulas <christos@zoulas.com>, gnats-bugs@netbsd.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: toolchain/56153: gdb is broken for alpha
Date: Fri, 7 May 2021 23:20:49 +0900

 On 2021/05/07 23:03, Christos Zoulas wrote:
 > 
 >>
 >> Hmm, (1)-(3) below results in the same crash for ``gdb cat cat.core''.
 >>
 >> (1) Replace libc with that with old jemalloc by LD_LIBRARY_PATH
 >> (2) Set LD_PRELOAD=/usr/lib/libbsdmalloc.so
 >> (3) Set LD_PRELOAD=/usr/lib/libgnumalloc.so
 > 
 > By the same crash you mean in the same free call or the same jemalloc stack trace?

 Oops, sorry for the ambiguity. I meant that gdb crashes after reading debug
 symbol for cat(1). I've confirmed that each library is loaded by pmap(1), but
 I've never examined backtrace yet.

 > Can you try undef'ing all the HAVE_ALLOCA?

 Sure. I will soon!

 Thanks,
 rin

From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Christos Zoulas <christos@zoulas.com>, gnats-bugs@netbsd.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: toolchain/56153: gdb is broken for alpha
Date: Fri, 7 May 2021 23:31:13 +0900

 >> Can you try undef'ing all the HAVE_ALLOCA?
 > 
 > Sure. I will soon!

 That's it! It works fine at least for cat.core:

 ----
 ds10$ ./gdb.noalloca cat cat.core
 GNU gdb (GDB) 11.0.50.20200914-git
 ...(snip)...
 Reading symbols from cat...
 Reading symbols from /usr/libdata/debug//bin/cat.debug...
 [New process 18637]
 Core was generated by `cat'.
 Program terminated with signal SIGQUIT, Quit.
 #0  0x000003fffdc242b8 in read () from /lib/libc.so.12
 (gdb) bt
 #0  0x000003fffdc242b8 in read () from /lib/libc.so.12
 #1  0x0000000120001910 in raw_cat (rfd=<optimized out>)
      at /usr/src/bin/cat/cat.c:313
 #2  0x0000000120001b0c in raw_args (argv=0x1fffff728)
      at /usr/src/bin/cat/cat.c:277
 #3  0x0000000120002160 in main (argc=<optimized out>, argv=0x1fffff728)
      at /usr/src/bin/cat/cat.c:136
 (gdb)
 ----

 Thanks,
 rin

From: Christos Zoulas <christos@zoulas.com>
To: gnats-bugs@netbsd.org
Cc: toolchain-manager@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org,
 rokuyama.rk@gmail.com
Subject: Re: toolchain/56153: gdb is broken for alpha
Date: Fri, 7 May 2021 10:51:54 -0400

 --Apple-Mail=_45B77F1B-56A3-47D3-8E48-FA6835F21DC7
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 	charset=us-ascii

 Which means (in theory :-) that the malloca.c allocates with alloca(3) =
 and frees with regular
 free which gives jemalloc a heartache. The next step is to instrument =
 them malloca.h and malloca.c
 calls with printfs to see what's happening...

 christos

 > On May 7, 2021, at 10:35 AM, Rin Okuyama <rokuyama.rk@gmail.com> =
 wrote:
 >=20
 > The following reply was made to PR toolchain/56153; it has been noted =
 by GNATS.
 >=20
 > From: Rin Okuyama <rokuyama.rk@gmail.com>
 > To: Christos Zoulas <christos@zoulas.com>, gnats-bugs@netbsd.org
 > Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
 > netbsd-bugs@netbsd.org
 > Subject: Re: toolchain/56153: gdb is broken for alpha
 > Date: Fri, 7 May 2021 23:31:13 +0900
 >=20
 >>> Can you try undef'ing all the HAVE_ALLOCA?
 >>=20
 >> Sure. I will soon!
 >=20
 > That's it! It works fine at least for cat.core:
 >=20
 > ----
 > ds10$ ./gdb.noalloca cat cat.core
 > GNU gdb (GDB) 11.0.50.20200914-git
 > ...(snip)...
 > Reading symbols from cat...
 > Reading symbols from /usr/libdata/debug//bin/cat.debug...
 > [New process 18637]
 > Core was generated by `cat'.
 > Program terminated with signal SIGQUIT, Quit.
 > #0  0x000003fffdc242b8 in read () from /lib/libc.so.12
 > (gdb) bt
 > #0  0x000003fffdc242b8 in read () from /lib/libc.so.12
 > #1  0x0000000120001910 in raw_cat (rfd=3D<optimized out>)
 >      at /usr/src/bin/cat/cat.c:313
 > #2  0x0000000120001b0c in raw_args (argv=3D0x1fffff728)
 >      at /usr/src/bin/cat/cat.c:277
 > #3  0x0000000120002160 in main (argc=3D<optimized out>, =
 argv=3D0x1fffff728)
 >      at /usr/src/bin/cat/cat.c:136
 > (gdb)
 > ----
 >=20
 > Thanks,
 > rin
 >=20


 --Apple-Mail=_45B77F1B-56A3-47D3-8E48-FA6835F21DC7
 Content-Transfer-Encoding: 7bit
 Content-Disposition: attachment;
 	filename=signature.asc
 Content-Type: application/pgp-signature;
 	name=signature.asc
 Content-Description: Message signed with OpenPGP

 -----BEGIN PGP SIGNATURE-----
 Comment: GPGTools - http://gpgtools.org

 iF0EARECAB0WIQS+BJlbqPkO0MDBdsRxESqxbLM7OgUCYJVUCgAKCRBxESqxbLM7
 OsnEAKCXZM7Do/DAKnRM8kwXrzrp+m2awQCdGwvUpjhvd2caWNVoX3pOvWeWq3I=
 =vOiO
 -----END PGP SIGNATURE-----

 --Apple-Mail=_45B77F1B-56A3-47D3-8E48-FA6835F21DC7--

From: Rin Okuyama <rokuyama.rk@gmail.com>
To: Christos Zoulas <christos@zoulas.com>, gnats-bugs@netbsd.org
Cc: toolchain-manager@netbsd.org, gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: toolchain/56153: gdb is broken for alpha
Date: Sat, 8 May 2021 18:00:29 +0900

 On 2021/05/07 23:51, Christos Zoulas wrote:
 > Which means (in theory :-) that the malloca.c allocates with alloca(3) and frees with regular
 > free which gives jemalloc a heartache. The next step is to instrument them malloca.h and malloca.c
 > calls with printfs to see what's happening...

 printf debug shows that malloca() macro is miscompiled:

 external/gpl3/gdb/dist/gnulib/import/malloca.h

 |   57  #if HAVE_ALLOCA
 |   58  # define malloca(N) \
 |   59    ((N) < 4032 - (2 * sa_alignment_max - 1)                                   \
 |   60     ? (void *) (((uintptr_t) (char *) alloca ((N) + 2 * sa_alignment_max - 1) \
 |   61                  + (2 * sa_alignment_max - 1))                                \
 |   62                 & ~(uintptr_t)(2 * sa_alignment_max - 1))                     \
 |   63     : mmalloca (N))
 |   64  #else
 |   65  # define malloca(N) \
 |   66    mmalloca (N)
 |   67  #endif

 freea() determines by sa_alignment_max (= 8) bit whether the buffer is
 allocated by alloca() or mmalloca(). But, both GCC 10 and 9 miscompile
 malloca() macro, which results in sa_alignment_max is not masked out.

 Compiling canonicalize-lgpl.c:__realpath() (only user of malloca() macro)
 with -O0 works around the problem:

 ----
 Index: external/gpl3/gdb/dist/gnulib/import/canonicalize-lgpl.c
 ===================================================================
 RCS file: /home/netbsd/src/external/gpl3/gdb/dist/gnulib/import/canonicalize-lgpl.c,v
 retrieving revision 1.1.1.1
 diff -p -u -r1.1.1.1 canonicalize-lgpl.c
 --- external/gpl3/gdb/dist/gnulib/import/canonicalize-lgpl.c	15 Sep 2020 01:43:50 -0000	1.1.1.1
 +++ external/gpl3/gdb/dist/gnulib/import/canonicalize-lgpl.c	8 May 2021 08:07:54 -0000
 @@ -114,6 +114,13 @@ alloc_failed (void)
      holds the same value as the value returned.  */

   char *
 +#ifdef __alpha__
 +/*
 + * toolchain/56153
 + * GCC 10 and 9 miscompile malloca() macro for alpha.
 + */
 +__attribute__((optimize("O0")))
 +#endif
   __realpath (const char *name, char *resolved)
   {
     char *rpath, *dest, *extra_buf = NULL;
 ----

 However, still, it is a sad surprise for me that GCC cannot compile
 such a simple mask operation...

 Thanks,
 rin

From: "Christos Zoulas" <christos@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56153 CVS commit: src/external/gpl3/gdb/dist/gnulib/import
Date: Sat, 8 May 2021 08:23:47 -0400

 Module Name:	src
 Committed By:	christos
 Date:		Sat May  8 12:23:47 UTC 2021

 Modified Files:
 	src/external/gpl3/gdb/dist/gnulib/import: canonicalize-lgpl.c

 Log Message:
 PR/56153: Rin Okuyama: alpha miscompiles malloca() macro.


 To generate a diff of this commit:
 cvs rdiff -u -r1.1.1.1 -r1.2 \
     src/external/gpl3/gdb/dist/gnulib/import/canonicalize-lgpl.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->analyzed
State-Changed-By: rin@NetBSD.org
State-Changed-When: Sat, 08 May 2021 12:42:10 +0000
State-Changed-Why:
Turned out to be a GCC bug.

Workaround was committed and registered to doc/HACKS by christos.

Let us keep our eyes on other possible fallout's from this GCC bug.
It would be nice if we can find minimal test case and report it to
upstream.


From: "Jason R Thorpe" <thorpej@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56153 CVS commit: src/sys/arch/alpha
Date: Tue, 6 Jul 2021 12:20:52 +0000

 Module Name:	src
 Committed By:	thorpej
 Date:		Tue Jul  6 12:20:52 UTC 2021

 Modified Files:
 	src/sys/arch/alpha/alpha: vm_machdep.c
 	src/sys/arch/alpha/include: param.h

 Log Message:
 - Define STACK_ALIGNBYTES to override the default and ensure that
   stacks are 16-byte aligned, an assumption made by the compiler
   and recommended by the Alpha Architecture Handbook.
 - cpu_lwp_fork(): Ensure 16-byte stack alignment if the caller specified
   one.

 Addresses root casue of PR port-alpha/54307 and PR toolchain/56153.

 Many thanks to rin@ for performing the root cause analysis and testing
 changes.


 To generate a diff of this commit:
 cvs rdiff -u -r1.119 -r1.120 src/sys/arch/alpha/alpha/vm_machdep.c
 cvs rdiff -u -r1.48 -r1.49 src/sys/arch/alpha/include/param.h

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: toolchain-manager->thorpej
Responsible-Changed-By: thorpej@NetBSD.org
Responsible-Changed-When: Tue, 06 Jul 2021 12:44:14 +0000
Responsible-Changed-Why:
I committed the fixes.


State-Changed-From-To: analyzed->feedback
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Tue, 06 Jul 2021 12:44:14 +0000
State-Changed-Why:
Fixes committed; please confirm in a freshly updated tree.


State-Changed-From-To: feedback->closed
State-Changed-By: rin@NetBSD.org
State-Changed-When: Wed, 07 Jul 2021 05:33:33 +0000
State-Changed-Why:
Fixed. No regression for ATF on a fresh built/installed system.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.