From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 21 06:32:47 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10B7DDB for ; Fri, 21 Nov 2014 06:32:47 +0000 (UTC) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFD5DD86 for ; Fri, 21 Nov 2014 06:32:46 +0000 (UTC) Received: by mail-yh0-f51.google.com with SMTP id a41so2064905yho.38 for ; Thu, 20 Nov 2014 22:32:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lmvbE7YIC0yRvqhzbhRoO0E+MHG3je1Jln7qnxD6zQo=; b=EHSaqWctDWt0gkc6AeXgQZ87OCVxmYlJ+DS7iZwPFgNuknaTeVLN0WrkOz7DSbKAFY iqlVCvueb/293oV1ZXBMcGCnjLZd3nVbU9Zr+2d0IFtXim4+dOFg16wgiBZXykCHUdNM HInYehbvPRJXTnozPKZKMBGXN2SxSaX87aKQlAuwTWbiekPELKmzDoDYsQXOv5msZsi3 iSms/UVSIhFwQhZRHINgDK5jtbQlGpzzA+dSIek5laLPGFbhtA1Mdl40/6Q0ZW93YQvC jxXz/9p9mYFX8LM64n2yCl10w5+Hdfbx7+euLoRbZqrFoT+Ac3roWRfzKMzdjqYxvIsa Mryw== MIME-Version: 1.0 X-Received: by 10.236.203.114 with SMTP id e78mr1101853yho.47.1416551566007; Thu, 20 Nov 2014 22:32:46 -0800 (PST) Sender: kmacybsd@gmail.com Received: by 10.170.82.197 with HTTP; Thu, 20 Nov 2014 22:32:45 -0800 (PST) In-Reply-To: References: Date: Thu, 20 Nov 2014 22:32:45 -0800 X-Google-Sender-Auth: cs18iFji-jZAQ270NKWQRtBzp8o Message-ID: Subject: Re: Debugging the ZDB debugger. From: "K. Macy" To: Zaphod Beeblebrox Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 06:32:47 -0000 Clang is very good at minimizing the live range of variables. As of that point in the function dl is no longer needed (by zdb), so if it is still available it will be in a non-callee save register. Whether or not it's still valid is more or less up to chance. You can often infer the value from disassembling and looking at the registers. However, you're not looking at some user's kernel core dump that you can't ask him to reproduce. You can ensure that every variable used, regardless of its liveness, is allocated a location on the stack by compiling with -O0. I believe -O2 is actually set somewhere in the .mk files, so naively you need to set CFLAGS=-O0 and add in explicitly whatever flags it's passed that it needs. I'd be surprised if there isn't a much cleaner way to do it but I'm not familiar with build magic. -K On Thu, Nov 20, 2014 at 10:25 PM, Zaphod Beeblebrox wrote: > Ok... that advice got me somewhere... now my stack is: > > (gdb) bt > #0 0x00000000004098a9 in dump_dir (os=0x80d302000) > at > /usr/src/cddl/usr.sbin/zdb/../../../cddl/contrib/opensolaris/cmd/zdb/zdb.c:1464 > #1 0x0000000000406222 in main (argc=0, argv=) > at > /usr/src/cddl/usr.sbin/zdb/../../../cddl/contrib/opensolaris/cmd/zdb/zdb.c:3604 > > and we got here on a segmentation fault. Now ... I'm a little confused: > > (gdb) frame 0 > #0 0x00000000004098a9 in dump_dir (os=0x80d302000) > at > /usr/src/cddl/usr.sbin/zdb/../../../cddl/contrib/opensolaris/cmd/zdb/zdb.c:1464 > 1464 zdb_nicenum(dl->dl_phys->dl_used, bytes); > (gdb) p dl > No symbol "dl" in current context. > (gdb) p *dl > No symbol "dl" in current context. > > I thought for a second that I was using gdb wrong (it's been awhile), but: > > (gdb) frame 1 > #1 0x0000000000406222 in main (argc=0, argv=) > at > /usr/src/cddl/usr.sbin/zdb/../../../cddl/contrib/opensolaris/cmd/zdb/zdb.c:3604 > 3604 dump_dir(os); > (gdb) p os > $3 = (objset_t *) 0x80d302000 > > ... my first thought was "is the stack trashed"? ... but shouldn't gdb know > what 'dl' is regardless of the process state? > > Then I realized that line 1464 isn't in dump_dir() ... it's in dump_dead() > > help?