* RFC: improve build-id mismatch error reporting
@ 2011-09-13 7:54 Timo Juhani Lindfors
2011-09-13 8:38 ` Mark Wielaard
0 siblings, 1 reply; 6+ messages in thread
From: Timo Juhani Lindfors @ 2011-09-13 7:54 UTC (permalink / raw)
To: systemtap
Hi,
currently if Debian users upgrade their kernel but forget to reboot they
get a pretty cryptic error message from systemtap:
> ERROR: Build-id mismatch: "kernel" vs. "vmlinux-2.6.32-5-amd64" byte 0 (0x5e vs 0xff)
> Pass 5: run failed. Try again with another '--vp 00001' option.
I want to improve that. I think ideally it should say
> ERROR: Debug symbols don't match running kernel. You are running
> "Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011"
> but the symbols are for
> "Linux version 2.6.32-5-amd64 (Debian 2.6.32-35squeeze2) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Sep 9 20:23:16 UTC 2011"
but the problem is that I don't know how to get this information from
kernel space. So far I can get it with
$ strings /usr/lib/debug/boot/vmlinux-2.6.32-5-amd64 | grep "^Linux version"
Linux version 2.6.32-5-amd64 (Debian 2.6.32-35squeeze2) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Fri Sep 9 20:23:16 UTC 2011
$ cat /proc/version
Linux version 2.6.32-5-amd64 (Debian 2.6.32-35) (dannf@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Tue Jun 14 09:42:28 UTC 2011
which is not very clean. The "2.6.32-35" part is available in
/usr/src/linux-headers-3.0.0-1-amd64/include/generated/compile.h:
/* This file is auto generated, version 1 */
/* SMP */
#define UTS_MACHINE "x86_64"
#define UTS_VERSION "#1 SMP Sat Aug 27 16:21:11 UTC 2012"
#define LINUX_COMPILE_DISTRIBUTION "Debian"
#define LINUX_COMPILE_DISTRIBUTION_OFFICIAL_BUILD
#define LINUX_COMPILE_DISTRIBUTION_UPLOADER "ben@decadent.org.uk"
#define LINUX_COMPILE_DISTRIBUTION_VERSION "3.0.0-3"
#define LINUX_COMPILE_BY "unknown"
#define LINUX_COMPILE_HOST "Debian"
#define LINUX_COMPILER "gcc version 4.5.3 (Debian 4.5.3-8) "
and gets embedded in the kernel as part of the linux_proc_banner
variable due to a debian specific patch to version.c. Unfortunately that
variable is not exported.
Fortunately utsname()->version is available to us. It does not have the
version number but instead the build date but now that I think of it
this might be even better: people might recompile their custom kernels
and forget to update the version number. I came up with
--- a/translate.cxx
+++ b/translate.cxx
@@ -1210,6 +1210,7 @@
// just in case modversions didn't.
o->newline() << "{";
o->newline(1) << "const char* release = UTS_RELEASE;";
+ o->newline() << "const char* version = UTS_VERSION;";
// NB: This UTS_RELEASE compile-time macro directly checks only that
// the compile-time kbuild tree matches the compile-time debuginfo/etc.
@@ -1230,6 +1231,12 @@
o->newline() << "rc = -EINVAL;";
o->newline(-1) << "}";
+ o->newline() << "if (strcmp (utsname()->version, version)) {";
+ o->newline(1) << "_stp_error (\"module version mismatch (%s vs %s)\", "
+ << "version, utsname()->version);";
+ o->newline() << "rc = -EINVAL;";
+ o->newline(-1) << "}";
+
// perform buildid-based checking if able
o->newline() << "if (_stp_module_check()) rc = -EINVAL;";
@@ -5878,6 +5885,7 @@
s.op->newline() << "#include <linux/utsname.h>";
s.op->newline() << "#include <linux/version.h>";
// s.op->newline() << "#include <linux/compile.h>";
+ s.op->newline() << "#include <generated/compile.h>";
s.op->newline() << "#include \"loc2c-runtime.h\" ";
s.op->newline() << "#include \"access_process_vm.h\" ";
which gives output line
ERROR: module version mismatch (#1 SMP Sat Aug 27 16:21:11 UTC 2012 vs #1 SMP Sat Aug 27 16:21:11 UTC 2011)
What do you think?
-Timo
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: improve build-id mismatch error reporting
2011-09-13 7:54 RFC: improve build-id mismatch error reporting Timo Juhani Lindfors
@ 2011-09-13 8:38 ` Mark Wielaard
2011-09-20 11:30 ` Timo Juhani Lindfors
0 siblings, 1 reply; 6+ messages in thread
From: Mark Wielaard @ 2011-09-13 8:38 UTC (permalink / raw)
To: Timo Juhani Lindfors; +Cc: systemtap
Hi Timo,
On Tue, 2011-09-13 at 10:54 +0300, Timo Juhani Lindfors wrote:
> Fortunately utsname()->version is available to us. It does not have the
> version number but instead the build date but now that I think of it
> this might be even better: people might recompile their custom kernels
> and forget to update the version number. I came up with
>
> --- a/translate.cxx
> +++ b/translate.cxx
> @@ -1210,6 +1210,7 @@
> // just in case modversions didn't.
> o->newline() << "{";
> o->newline(1) << "const char* release = UTS_RELEASE;";
> + o->newline() << "const char* version = UTS_VERSION;";
>
> // NB: This UTS_RELEASE compile-time macro directly checks only that
> // the compile-time kbuild tree matches the compile-time debuginfo/etc.
> @@ -1230,6 +1231,12 @@
> o->newline() << "rc = -EINVAL;";
> o->newline(-1) << "}";
>
> + o->newline() << "if (strcmp (utsname()->version, version)) {";
> + o->newline(1) << "_stp_error (\"module version mismatch (%s vs %s)\", "
> + << "version, utsname()->version);";
> + o->newline() << "rc = -EINVAL;";
> + o->newline(-1) << "}";
> +
> // perform buildid-based checking if able
> o->newline() << "if (_stp_module_check()) rc = -EINVAL;";
>
> @@ -5878,6 +5885,7 @@
> s.op->newline() << "#include <linux/utsname.h>";
> s.op->newline() << "#include <linux/version.h>";
> // s.op->newline() << "#include <linux/compile.h>";
> + s.op->newline() << "#include <generated/compile.h>";
> s.op->newline() << "#include \"loc2c-runtime.h\" ";
> s.op->newline() << "#include \"access_process_vm.h\" ";
>
> which gives output line
>
> ERROR: module version mismatch (#1 SMP Sat Aug 27 16:21:11 UTC 2012 vs #1 SMP Sat Aug 27 16:21:11 UTC 2011)
>
> What do you think?
I like the idea!
We should also include release/UTS_RELEASE in the output, it isn't the
package version, but at least gives a hint of the kernel version
involved.
Only issue is that as the patch already implies, in the past this header
was under include/linux/compile.h instead of
include/generated/compile.h. We might need a runtime/autoconf check for
that.
Thanks,
Mark
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: improve build-id mismatch error reporting
2011-09-13 8:38 ` Mark Wielaard
@ 2011-09-20 11:30 ` Timo Juhani Lindfors
2011-09-20 12:52 ` Frank Ch. Eigler
0 siblings, 1 reply; 6+ messages in thread
From: Timo Juhani Lindfors @ 2011-09-20 11:30 UTC (permalink / raw)
To: Mark Wielaard; +Cc: systemtap
Mark Wielaard <mjw@redhat.com> writes:
> We should also include release/UTS_RELEASE in the output, it isn't the
> package version, but at least gives a hint of the kernel version
> involved.
The code compares UTS_RELEASE first and only then looks at
UTS_VERSION. Do you still think it makes sense to print UTS_RELEASE in
the UTS_VERSION mismatch case? (as in that case UTS_RELEASE matched
correctly).
> Only issue is that as the patch already implies, in the past this header
> was under include/linux/compile.h instead of
> include/generated/compile.h. We might need a runtime/autoconf check for
> that.
Autoconf test won't work since kernel versions can change after
systemtap has been built?
I looked around a bit but I'm not quite sure how to test this runtime.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: improve build-id mismatch error reporting
2011-09-20 11:30 ` Timo Juhani Lindfors
@ 2011-09-20 12:52 ` Frank Ch. Eigler
2011-09-21 9:17 ` Timo Juhani Lindfors
0 siblings, 1 reply; 6+ messages in thread
From: Frank Ch. Eigler @ 2011-09-20 12:52 UTC (permalink / raw)
To: Timo Juhani Lindfors; +Cc: Mark Wielaard, systemtap
Timo Juhani Lindfors <timo.lindfors@iki.fi> writes:
> [...]
> The code compares UTS_RELEASE first and only then looks at
> UTS_VERSION. Do you still think it makes sense to print UTS_RELEASE in
> the UTS_VERSION mismatch case? (as in that case UTS_RELEASE matched
> correctly).
Yes, probably, to give user more hints.
> Autoconf test won't work since kernel versions can change after
> systemtap has been built?
> I looked around a bit but I'm not quite sure how to test this runtime.
Aha, but we have a run-time autoconf scheme (cribbed originally from
some vmware makefiles). See buildrun.cxx, runtime/autoconf-*.
- FChE
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: RFC: improve build-id mismatch error reporting
2011-09-20 12:52 ` Frank Ch. Eigler
@ 2011-09-21 9:17 ` Timo Juhani Lindfors
2011-09-21 9:19 ` [PATCH] Tell the user if UTS_VERSION does not match running kernel Timo Juhani Lindfors
0 siblings, 1 reply; 6+ messages in thread
From: Timo Juhani Lindfors @ 2011-09-21 9:17 UTC (permalink / raw)
To: systemtap
fche@redhat.com (Frank Ch. Eigler) writes:
> Yes, probably, to give user more hints.
ok.
> Aha, but we have a run-time autoconf scheme (cribbed originally from
> some vmware makefiles). See buildrun.cxx, runtime/autoconf-*.
Thanks for the pointer. I'll git send-email an updated patch as a reply
to this email.
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH] Tell the user if UTS_VERSION does not match running kernel
2011-09-21 9:17 ` Timo Juhani Lindfors
@ 2011-09-21 9:19 ` Timo Juhani Lindfors
0 siblings, 0 replies; 6+ messages in thread
From: Timo Juhani Lindfors @ 2011-09-21 9:19 UTC (permalink / raw)
To: systemtap; +Cc: Timo Juhani Lindfors
The test is done before looking at build-id since build-id error
messages like
ERROR: Build-id mismatch: "kernel" vs. "vmlinux-2.6.32-5-amd64" byte 0 (0x5e vs 0xff)
Pass 5: run failed. Try again with another '--vp 00001' option.
are not very user-friendly.
---
buildrun.cxx | 1 +
runtime/autoconf-generated-compile.c | 4 ++++
translate.cxx | 17 +++++++++++++++++
3 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 runtime/autoconf-generated-compile.c
diff --git a/buildrun.cxx b/buildrun.cxx
index 0435403..f3dcda5 100644
--- a/buildrun.cxx
+++ b/buildrun.cxx
@@ -214,6 +214,7 @@ compile_pass (systemtap_session& s)
o << "$(STAPCONF_HEADER):" << endl;
o << "\t@echo -n > $@" << endl;
output_autoconf(s, o, "autoconf-hrtimer-rel.c", "STAPCONF_HRTIMER_REL", NULL);
+ output_autoconf(s, o, "autoconf-generated-compile.c", "STAPCONF_GENERATED_COMPILE", NULL);
output_autoconf(s, o, "autoconf-hrtimer-getset-expires.c", "STAPCONF_HRTIMER_GETSET_EXPIRES", NULL);
output_autoconf(s, o, "autoconf-inode-private.c", "STAPCONF_INODE_PRIVATE", NULL);
output_autoconf(s, o, "autoconf-constant-tsc.c", "STAPCONF_CONSTANT_TSC", NULL);
diff --git a/runtime/autoconf-generated-compile.c b/runtime/autoconf-generated-compile.c
new file mode 100644
index 0000000..abf0765
--- /dev/null
+++ b/runtime/autoconf-generated-compile.c
@@ -0,0 +1,4 @@
+#include <generated/compile.h>
+
+char* x = UTS_VERSION;
+
diff --git a/translate.cxx b/translate.cxx
index 8dc0995..0aff9d1 100644
--- a/translate.cxx
+++ b/translate.cxx
@@ -1162,6 +1162,9 @@ c_unparser::emit_module_init ()
// just in case modversions didn't.
o->newline() << "{";
o->newline(1) << "const char* release = UTS_RELEASE;";
+ o->newline() << "#ifdef STAPCONF_GENERATED_COMPILE";
+ o->newline() << "const char* version = UTS_VERSION;";
+ o->newline() << "#endif";
// NB: This UTS_RELEASE compile-time macro directly checks only that
// the compile-time kbuild tree matches the compile-time debuginfo/etc.
@@ -1182,6 +1185,17 @@ c_unparser::emit_module_init ()
o->newline() << "rc = -EINVAL;";
o->newline(-1) << "}";
+ o->newline() << "#ifdef STAPCONF_GENERATED_COMPILE";
+ o->newline() << "if (strcmp (utsname()->version, version)) {";
+ o->newline(1) << "_stp_error (\"module version mismatch (%s vs %s), release %s\", "
+ << "version, "
+ << "utsname()->version, "
+ << "release"
+ << ");";
+ o->newline() << "rc = -EINVAL;";
+ o->newline(-1) << "}";
+ o->newline() << "#endif";
+
// perform buildid-based checking if able
o->newline() << "if (_stp_module_check()) rc = -EINVAL;";
@@ -5813,6 +5827,9 @@ translate_pass (systemtap_session& s)
s.op->newline() << "#include <linux/utsname.h>";
s.op->newline() << "#include <linux/version.h>";
// s.op->newline() << "#include <linux/compile.h>";
+ s.op->newline() << "#ifdef STAPCONF_GENERATED_COMPILE";
+ s.op->newline() << "#include <generated/compile.h>";
+ s.op->newline() << "#endif";
s.op->newline() << "#include \"loc2c-runtime.h\" ";
s.op->newline() << "#include \"access_process_vm.h\" ";
--
1.7.2.5
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-09-21 9:19 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-13 7:54 RFC: improve build-id mismatch error reporting Timo Juhani Lindfors
2011-09-13 8:38 ` Mark Wielaard
2011-09-20 11:30 ` Timo Juhani Lindfors
2011-09-20 12:52 ` Frank Ch. Eigler
2011-09-21 9:17 ` Timo Juhani Lindfors
2011-09-21 9:19 ` [PATCH] Tell the user if UTS_VERSION does not match running kernel Timo Juhani Lindfors
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).