NetBSD Problem Report #56268

From  Tue Jun 22 02:49:39 2021
Return-Path: <>
Received: from ( [])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "", Issuer " CA" (not verified))
	by (Postfix) with ESMTPS id 3CF3E1A921F
	for <>; Tue, 22 Jun 2021 02:49:39 +0000 (UTC)
Message-Id: <>
Date: Tue, 22 Jun 2021 02:49:38 +0000 (UTC)
Subject: GDB backtrace fails for core dump on m68k
X-Send-Pr-Version: www-1.0

>Number:         56268
>Category:       toolchain
>Synopsis:       GDB backtrace fails for core dump on m68k
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    toolchain-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 22 02:50:00 +0000 2021
>Last-Modified:  Sun Jun 26 08:30:01 +0000 2022
>Originator:     Rin Okuyama
>Release:        9.99.85
Department of Physics, Meiji University
NetBSD a1200 9.99.85 NetBSD 9.99.85 (A1200_WSCONS) #14: Wed Jun 16 07:44:49 JST 2021  rin@latipes:/sys/arch/amiga/compile/A1200_WSCONS amiga
For m68k, GDB fails to backtrace for core dump:

$ cat
^\[1]   Quit (core dumped)      cat
$ gdb cat cat.core
GNU gdb (GDB)
Type "apropos word" to search for commands related to "word"...
Reading symbols from cat...
Reading symbols from /usr/libdata/debug//bin/cat.debug...
[New process 176]
Core was generated by `cat'.
Program terminated with signal SIGQUIT, Quit.
#0  0x0e06c482 in ?? ()
(gdb) bt
#0  0x0e06c482 in ?? ()
#1  0x00003476 in ?? ()
#2  0x00000000 in ?? ()

Whereas this one works just fine:

$ gdb cat
GNU gdb (GDB)
Type "apropos word" to search for commands related to "word"...
Reading symbols from cat...
Reading symbols from /usr/libdata/debug//bin/cat.debug...
(gdb) r
Starting program: /bin/cat
^\[New process 1129]

Thread 2 received signal SIGQUIT, Quit.
[Switching to process 1129]
0x0e062482 in read () from /lib/
(gdb) bt
#0  0x0e062482 in read () from /lib/
#1  0x00003476 in raw_cat (rfd=0) at /usr/src/bin/cat/cat.c:313
#2  0x00003608 in raw_args (argv=0xfefffa18) at /usr/src/bin/cat/cat.c:277
#3  0x000039ae in main (argc=<optimized out>, argv=0xfefffa18)
    at /usr/src/bin/cat/cat.c:136

This is *NOT* a recent regression; all of GDB 11, 8.3, 8.0.1, 7.12 fail in
the same manner.

Also, I tried kernels and userlands from netbsd-9 and -8, but in vain.
Described above.

From: "Rin Okuyama" <>
Subject: PR/56268 CVS commit: src/external/gpl3/gdb/dist/gdb
Date: Sun, 26 Jun 2022 08:28:07 +0000

 Module Name:	src
 Committed By:	rin
 Date:		Sun Jun 26 08:28:07 UTC 2022

 Modified Files:
 	src/external/gpl3/gdb/dist/gdb: solib-svr4.c

 Log Message:
 PR toolchain/56268

 For NetBSD/m68k, program header is erroneously readable from core dump,
 although a page containing it is missing. This spoils relocation for
 the main executable, and debugging with core dumps becomes impossible,
 as described in the PR.

 In order to avoid this failure, add consistency check for program header;
 for NetBSD, 1st entry of program header refers program header itself. If
 this is not the case, we should be reading random garbage from core dump.

 Yes, this is a kind of the hackest hack. But, unable to debug with core
 dump is critical. Therefore, I commit this workaround temporarily until
 the real cause is found and fixed.

 Note that this is not a recent regression for GDB nor kernel, as
 mentioned in the PR. These from netbsd-8 and -9 fail in the same way
 without this hack.

 To generate a diff of this commit:
 cvs rdiff -u -r1.1.1.9 -r1.2 src/external/gpl3/gdb/dist/gdb/solib-svr4.c

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

NetBSD Home
NetBSD PR Database Search

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