NetBSD Problem Report #50128

From gson@gson.org  Wed Aug  5 12:46:31 2015
Return-Path: <gson@gson.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 380DDA5864
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  5 Aug 2015 12:46:31 +0000 (UTC)
Message-Id: <20150805124622.E1D71745854@guava.gson.org>
Date: Wed,  5 Aug 2015 15:46:22 +0300 (EEST)
From: gson@gson.org (Andreas Gustafsson)
Reply-To: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@gnats.NetBSD.org
Subject: amd64 debug build lacks kernel debug symbols
X-Send-Pr-Version: 3.95

>Number:         50128
>Category:       port-amd64
>Synopsis:       amd64 debug build lacks kernel debug symbols
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-amd64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Aug 05 12:50:00 +0000 2015
>Last-Modified:  Sat Sep 05 23:15:00 +0000 2015
>Originator:     Andreas Gustafsson
>Release:        NetBSD-current, source date 2015.08.03.11.24.17
>Organization:

>Environment:
System: NetBSD
Architecture: x86_64
Machine: amd64
>Description:

When I build a -current/i386 release using "build.sh -V MKDEBUG=yes
-V COPTS=-g release", the resulting release includes debug symbols for
both userland (as separate .debug files in the debug.tgz set) and the
kernel (within /netbsd itself).

I have used this build procedure as part of the kernel
debugging setup documented in the wiki at
https://wiki.netbsd.org/kernel_debugging_with_qemu/ .
Now that PR 49276 is fixed (go mrg!), I figured I'd try
it with the amd64 port instead of i386, but when I do that,
I end up with a kernel with no debug symbols.

>How-To-Repeat:

The following recipes do not require a particular host architecture
(or even a NetBSD host for that matter), but you do need plenty of
space in /tmp, misc/py-anita >= 1.38 and emulators/qemu from pkgsrc,
and some patience.

Working debug symbols on i386:

$ cd /usr/src
$ ./build.sh -j 4 -V MKDEBUG=YES -V COPTS="-g -fdebug-prefix-map=$(pwd)=/usr/src" -O /tmp/obj.i386 -m i386 -U release sourcesets
$ anita --workdir /tmp/work.i386 --disk-size 4G --memory-size 256M \
     --sets kern-GENERIC,modules,base,etc,comp,debug,games,man,misc,tests,text,syssrc,src,sharesrc,gnusrc \
     interact /tmp/obj.i386/releasedir/i386/
login: root
# gdb /netbsd
(gdb) l sys_sync
655     }
656     
657     /* ARGSUSED */
658     int
659     sys_sync(struct lwp *l, const void *v, register_t *retval)
660     {
661             do_sys_sync(l);
662             return (0);
663     }
664     
(gdb) <quit qemu using ctrl-a c q enter>

No debug symbols on amd64:

$ ./build.sh -j 4 -V MKDEBUG=YES -V COPTS="-g -fdebug-prefix-map=$(pwd)=/usr/src" -O /tmp/obj.amd64 -m amd64 -U release sourcesets
$ anita --workdir work.amd64 --disk-size 6G --memory-size 256M \
     --sets kern-GENERIC,modules,base,etc,comp,debug,games,man,misc,tests,text,syssrc,src,sharesrc,gnusrc \
     interact /tmp/obj.amd64/releasedir/amd64/
login: root
# gdb /netbsd
(gdb) l sys_sync
<note lack of output here>
(gdb) <quit qemu using ctrl-a c q enter>

>Fix:

Please.

>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-amd64/50128: amd64 debug build lacks kernel debug symbols
Date: Wed, 5 Aug 2015 15:01:07 +0200

 On Wed, Aug 05, 2015 at 12:50:00PM +0000, Andreas Gustafsson wrote:
 > When I build a -current/i386 release using "build.sh -V MKDEBUG=yes
 > -V COPTS=-g release", the resulting release includes debug symbols for
 > both userland (as separate .debug files in the debug.tgz set) and the
 > kernel (within /netbsd itself).
 > 
 > I have used this build procedure as part of the kernel
 > debugging setup documented in the wiki at
 > https://wiki.netbsd.org/kernel_debugging_with_qemu/ .
 > Now that PR 49276 is fixed (go mrg!), I figured I'd try
 > it with the amd64 port instead of i386, but when I do that,
 > I end up with a kernel with no debug symbols.

 Triggering this off COPTS is dangerous, it conflicts with:

 makeoptions     COPTS="-O2 -fno-omit-frame-pointer"

 in the amd64 GENERIC config.

 One could argue that -fno-omit-frame-pointer should go into CPUFLAGS
 instead and -O2 into DEFCOPTS.

 But maybe you should just set CONFIGOPTS="-D DEBUG=-g" ?

 Martin

From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc: port-amd64-maintainer@netbsd.org,
    gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org
Subject: Re: port-amd64/50128: amd64 debug build lacks kernel debug symbols
Date: Wed, 5 Aug 2015 21:22:19 +0300

 Martin Husemann wrote:
 >  One could argue that -fno-omit-frame-pointer should go into CPUFLAGS
 >  instead and -O2 into DEFCOPTS.
 >  
 >  But maybe you should just set CONFIGOPTS="-D DEBUG=-g" ?

 I just tried that, but it seems to make things worse, not better:

   ./build.sh -j 4 -V MKDEBUG=YES -V COPTS="-g -fdebug-prefix-map=$(pwd)=/usr/src" -V CONFIGOPTS="-D DEBUG=-g" -O /tmp/obj.amd64 -m amd64 -U release sourcesets
   [...]
   # gdb /netbsd
   [...]
   Reading symbols from /netbsd...(no debugging symbols found)...done.
   [...]
   (gdb) l sys_sync
   No symbol table is loaded.  Use the "file" command.
   (gdb)

 -- 
 Andreas Gustafsson, gson@gson.org

From: matthew green <mrg@eterna.com.au>
To: Andreas Gustafsson <gson@gson.org>
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: re: port-amd64/50128: amd64 debug build lacks kernel debug symbols
Date: Thu, 06 Aug 2015 04:42:27 +1000

 feed gdb the netbsd.gdb in the kernel build dir.

From: Andreas Gustafsson <gson@gson.org>
To: matthew green <mrg@eterna.com.au>
Cc: port-amd64-maintainer@netbsd.org,
    gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org,
    gnats-bugs@NetBSD.org
Subject: re: port-amd64/50128: amd64 debug build lacks kernel debug symbols
Date: Wed, 5 Aug 2015 22:22:37 +0300

 matthew green wrote:
 > feed gdb the netbsd.gdb in the kernel build dir.

 What I'm trying to do is to build a release that contains everything
 necessary to symbolically debug itself, including its own kernel (or
 to remotely debug the kernel of an identical system).  Unless the
 netbsd.gdb in the kernel build directory gets included in one of the
 release sets and installed by sysinst, it doesn't help.
 -- 
 Andreas Gustafsson, gson@gson.org

From: matthew green <mrg@eterna.com.au>
To: Andreas Gustafsson <gson@gson.org>
Cc: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org
Subject: re: port-amd64/50128: amd64 debug build lacks kernel debug symbols
Date: Thu, 06 Aug 2015 07:05:57 +1000

 Andreas Gustafsson writes:
 > matthew green wrote:
 > > feed gdb the netbsd.gdb in the kernel build dir.
 > 
 > What I'm trying to do is to build a release that contains everything
 > necessary to symbolically debug itself, including its own kernel (or
 > to remotely debug the kernel of an identical system).  Unless the
 > netbsd.gdb in the kernel build directory gets included in one of the
 > release sets and installed by sysinst, it doesn't help.

 yeah - that's a problem.  we don't want to have debug info in the
 actual kernel itself, so perhaps we should also have a way to have
 this file installed into /usr/libdata/debug/netbsd.debug, with a
 patch to the Makefile.kern.inc generate it in the obj dir, but i'm
 not sure how works for updating or sysinst choosing a kernel from
 a list..

 we could also just distribute the full netbsd.gdb for each build,
 and have the user manually deal with that, as a first step.


 .mrg.

From: matthew green <mrg@eterna.com.au>
To: port-amd64-maintainer@netbsd.org, gnats-admin@netbsd.org,
    netbsd-bugs@netbsd.org, gnats-bugs@NetBSD.org,
    Andreas Gustafsson <gson@gson.org>
Cc: 
Subject: re: port-amd64/50128: amd64 debug build lacks kernel debug symbols
Date: Thu, 06 Aug 2015 09:55:16 +1000

 > yeah - that's a problem.  we don't want to have debug info in the
 > actual kernel itself, so perhaps we should also have a way to have
 > this file installed into /usr/libdata/debug/netbsd.debug, with a
 > patch to the Makefile.kern.inc generate it in the obj dir, but i'm
 > not sure how works for updating or sysinst choosing a kernel from
 > a list..

 actually, we could do this.

 say the kernel list is GERNERIC and INSTALL.  when we link a
 kernel, we include the kernel configuration name in the
 debug info file.  so, we'd end up with:

 	/usr/libdata/debug/netbsd.GENERIC.debug
 	/usr/libdata/debug/netbsd.INSTALL.debug

 files in the installation, and using the --add-gnu-debuglink
 option to objcopy when creating the "netbsd" file file (the
 rule that currently copies it out of netbsd.gdb.)

 this would work great, with some major caveat.  the build
 currently creates sets before kernels, so we'd have to push
 the set creation phase *after* kernels phase.

 which is sort of annoying, in that we have to now build all
 the kernels to build "distribution sets", which is the
 currently fastest way to obtain a fresh set of just userland.

 hmmm.


 .mrg

From: Martin Husemann <martin@duskware.de>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@NetBSD.org
Subject: Re: port-amd64/50128: amd64 debug build lacks kernel debug symbols
Date: Thu, 6 Aug 2015 08:46:33 +0200

 We should drop netbsd-GENERIC.symbols.gz and netbsd-INSTALL.symbols.gz,
 and replace them with netbsd.gdb.gz - or turn them into .tgz including
 both.

 Martin

From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-amd64/50128: amd64 debug build lacks kernel debug symbols
Date: Sat, 5 Sep 2015 23:13:41 +0000

 On Thu, Aug 06, 2015 at 12:00:03AM +0000, matthew green wrote:
  >  this would work great, with some major caveat.  the build
  >  currently creates sets before kernels, so we'd have to push
  >  the set creation phase *after* kernels phase.
  >  
  >  which is sort of annoying, in that we have to now build all
  >  the kernels to build "distribution sets", which is the
  >  currently fastest way to obtain a fresh set of just userland.

 I don't think kernel build bits should go into sets, at least the way
 the kernel vs. userland build structure is currently constituted.

 When/if we get modules built with kernels (maybe uebayashi is working
 in that direction?) we'll need to distribute them with kernels; so
 maybe we should have a second group of kernel sets?

 -- 
 David A. Holland
 dholland@netbsd.org

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.