Date: Tue, 10 Mar 1998 13:18:32 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: freebsd-current@FreeBSD.ORG Cc: dyson@iquest.net Subject: problems stripping kernels Message-ID: <199803102018.NAA16119@panzer.plutotech.com>
next in thread | raw e-mail | index | archive | help
[ I sent this to -current, but it doesn't seem to have gone through. So,
I'm resending it. Sorry if this is a duplicate. ]
Howdy,
I've noticed a problem stripping kernels since John's changes on
Saturday went in. (and it wasn't fixed by version 1.46 of ufs_readwrite.c
yesterday)
Basically, I config my kernels with -g, and then use strip -d to
strip off the debugging symbols (after saving a copy of the kernel with
debugging symbols, of course). The problem is that kernels I strip on a
machine using a kernel built after Saturday's changes don't boot. They
just hang forever with the little spinning cursor. Kernels stripped on the
same machine running a kernel from before Saturday's changes work just
fine.
From what I can tell, there are three bytes different between the
two kernels:
$ ls -la kernel*
-rwxr-xr-x 1 ken wheel 1409956 Mar 10 09:50 kernel*
-rwx------ 1 ken wheel 1409956 Mar 10 09:53 kernel.debug*
$ cmp -l kernel kernel.debug
17 140 20
18 266 133
19 67 1
I have reproduced this behavior on another machine, so it isn't a
hardware glitch. I am running CAM, but neither Justin nor I think this
could be an Adaptec/CAM bug. If it were, it would manifest itself in other
ways besides this.
Has anyone else seen this? It could be that for other folks, the
corruption happens in a less critical place in the kernel binary.
So, here's how to reproduce:
- running a kernel from after John's changes on Saturday, build a kernel
on your machine with debugging symbols (config -g)
- copy the debugging kernel to another file
- strip one of the copies of the kernel
- boot another kernel from before John's changes on Saturday, and strip
the other copy of the kernel
- cmp -l kernel1 kernel2
For me, the difference occurs in a place that makes it impossible
for the kernel to boot.
If anyone wants the config file, more details, etc., just let me
know. I'm not absolutely positive that John's changes on Saturday caused
this, but it does seem like that may be the case. (And lest anyone think
I'm not grateful for the progress, see my NFS success story from
yesterday...:)
Thanks,
Ken
--
Kenneth Merry
ken@plutotech.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199803102018.NAA16119>