From owner-freebsd-arch@freebsd.org Thu Dec 3 16:57:48 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83197A3F5E0 for ; Thu, 3 Dec 2015 16:57:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5F0DF12C6; Thu, 3 Dec 2015 16:57:48 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 790C5B986; Thu, 3 Dec 2015 11:57:47 -0500 (EST) From: John Baldwin To: Erik Cederstrand Cc: freebsd-arch@freebsd.org, Ed Maste Subject: Re: Removing build metadata, for reproducible kernel builds Date: Thu, 03 Dec 2015 08:51:29 -0800 Message-ID: <1758086.qmdp4H277Z@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: References: <1920964.NJpSim6qZF@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 03 Dec 2015 11:57:47 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Dec 2015 16:57:48 -0000 On Thursday, December 03, 2015 10:28:10 AM Erik Cederstrand wrote: > > > Den 2. dec. 2015 kl. 21.03 skrev John Baldwin : > > > > As I noted in the review, this will break kgdb -n (and possibly crashinfo, > > less certain about that). Keeping the path (which should not vary if you > > build out of the same tree) will be sufficient to let kgdb -n still work > > (though it may need some changes to recognize both formats). > > Would it be feasible to include the relative build path instead of the absolute path? I seem to remember patches floating around for the __FILE__ macro, but I don't know if (k)gdb can work with relative paths. This is what kgdb -n does: /* * No kernel image here. Parse the dump header. The kernel object * directory can be found there and we probably have the kernel * image still in it. The object directory may also have a kernel * with debugging info (called kernel.debug). If we have a debug * kernel, use it. */ snprintf(path, sizeof(path), "%s/info.%d", crashdir, nr); info = fopen(path, "r"); if (info == NULL) { warn("%s", path); return; } while (fgets(path, sizeof(path), info) != NULL) { l = strlen(path); if (l > 0 && path[l - 1] == '\n') path[--l] = '\0'; if (strncmp(path, " ", 4) == 0) { s = strchr(path, ':'); s = (s == NULL) ? path + 4 : s + 1; l = snprintf(path, sizeof(path), "%s/kernel.debug", s); if (stat(path, &st) == -1 || !S_ISREG(st.st_mode)) { path[l - 6] = '\0'; if (stat(path, &st) == -1 || !S_ISREG(st.st_mode)) break; } kernel = strdup(path); break; } } fclose(info); It basically pulls the path from the 'version' string in the /var/crash/info.X line, appends 'kernel.debug' to it and sees if there is a file with that pathname. If so, it uses it. This means it doesn't find a kernel in some /boot/foo, it looks in the build directory. crashinfo instead finds all the 'kernel' files under /boot, extracts the version string using gdb from each kernel, and does a string compare with the version string in info.X. For this reason, crashinfo will still work if each string is unique. However, with the proposal, kernels built with different kernel configs from the same tree would have the same version string, thus being indistinguishable. A more robust solution than the string compares would be build-id, but that requires a newer linker which we don't have. -- John Baldwin