Skip to contentSkip to conversation

Follow debuginfo link of vmlinux file

PATCH In review Bernhard Walle 4 participants 12 messages May 1, 2007 – May 29, 2007

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Follow debuginfo link of vmlinux file

This patch implements support for following the debug information link in the .gnu_debuginfo section if the specified binary contains one. That makes it possible to call makedumpfile with -x /boot/vmlinux-<version> on distributions that ship extra -debuginfo packages for the kernel.

See GDB documentation, section 15.2 "Debugging Information in Separate Files" for information about then contents of the .gnu_debuginfo section, the algorithm used to find the debuginfo file and the CRC checksum implementation.

---
 makedumpfile.c |  296 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 makedumpfile.h |    8 +
 2 files changed, 302 insertions(+), 2 deletions(-)
makedumpfile.c +296 -0
@@ -339,17 +339,313 @@ open_config_file(struct DumpInfo *info, 
 	return TRUE;
 }
 
+unsigned long
+gnu_debuglink_crc32 (unsigned long crc, unsigned char *buf, size_t len)
+{
+	static const unsigned long crc32_table[256] = {
+		0x00000000, 0x77073096, 0xee0e612c, 0x990951ba, 0x076dc419,
+		0x706af48f, 0xe963a535, 0x9e6495a3, 0x0edb8832, 0x79dcb8a4,
+		0xe0d5e91e, 0x97d2d988, 0x09b64c2b, 0x7eb17cbd, 0xe7b82d07,
+		0x90bf1d91, 0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
+		0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7, 0x136c9856,
+		0x646ba8c0, 0xfd62f97a, 0x8a65c9ec, 0x14015c4f, 0x63066cd9,
+		0xfa0f3d63, 0x8d080df5, 0x3b6e20c8, 0x4c69105e, 0xd56041e4,
+		0xa2677172, 0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
+		0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940, 0x32d86ce3,
+		0x45df5c75, 0xdcd60dcf, 0xabd13d59, 0x26d930ac, 0x51de003a,
+		0xc8d75180, 0xbfd06116, 0x21b4f4b5, 0x56b3c423, 0xcfba9599,
+		0xb8bda50f, 0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
+		0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d, 0x76dc4190,
+		0x01db7106, 0x98d220bc, 0xefd5102a, 0x71b18589, 0x06b6b51f,
+		0x9fbfe4a5, 0xe8b8d433, 0x7807c9a2, 0x0f00f934, 0x9609a88e,
+		0xe10e9818, 0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
+		0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e, 0x6c0695ed,
+		0x1b01a57b, 0x8208f4c1, 0xf50fc457, 0x65b0d9c6, 0x12b7e950,
+		0x8bbeb8ea, 0xfcb9887c, 0x62dd1ddf, 0x15da2d49, 0x8cd37cf3,
+		0xfbd44c65, 0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
+		0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb, 0x4369e96a,
+		0x346ed9fc, 0xad678846, 0xda60b8d0, 0x44042d73, 0x33031de5,
+		0xaa0a4c5f, 0xdd0d7cc9, 0x5005713c, 0x270241aa, 0xbe0b1010,
+		0xc90c2086, 0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
+		0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4, 0x59b33d17,
+		0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad, 0xedb88320, 0x9abfb3b6,
+		0x03b6e20c, 0x74b1d29a, 0xead54739, 0x9dd277af, 0x04db2615,
+		0x73dc1683, 0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
+		0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1, 0xf00f9344,
+		0x8708a3d2, 0x1e01f268, 0x6906c2fe, 0xf762575d, 0x806567cb,
+		0x196c3671, 0x6e6b06e7, 0xfed41b76, 0x89d32be0, 0x10da7a5a,
+		0x67dd4acc, 0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
+		0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252, 0xd1bb67f1,
+		0xa6bc5767, 0x3fb506dd, 0x48b2364b, 0xd80d2bda, 0xaf0a1b4c,
+		0x36034af6, 0x41047a60, 0xdf60efc3, 0xa867df55, 0x316e8eef,
+		0x4669be79, 0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
+		0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f, 0xc5ba3bbe,
+		0xb2bd0b28, 0x2bb45a92, 0x5cb36a04, 0xc2d7ffa7, 0xb5d0cf31,
+		0x2cd99e8b, 0x5bdeae1d, 0x9b64c2b0, 0xec63f226, 0x756aa39c,
+		0x026d930a, 0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
+		0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38, 0x92d28e9b,
+		0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21, 0x86d3d2d4, 0xf1d4e242,
+		0x68ddb3f8, 0x1fda836e, 0x81be16cd, 0xf6b9265b, 0x6fb077e1,
+		0x18b74777, 0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
+		0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45, 0xa00ae278,
+		0xd70dd2ee, 0x4e048354, 0x3903b3c2, 0xa7672661, 0xd06016f7,
+		0x4969474d, 0x3e6e77db, 0xaed16a4a, 0xd9d65adc, 0x40df0b66,
+		0x37d83bf0, 0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
+		0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6, 0xbad03605,
+		0xcdd70693, 0x54de5729, 0x23d967bf, 0xb3667a2e, 0xc4614ab8,
+		0x5d681b02, 0x2a6f2b94, 0xb40bbe37, 0xc30c8ea1, 0x5a05df1b,
+		0x2d02ef8d
+	};
+	unsigned char *end;
+
+	crc = ~crc & 0xffffffff;
+	for (end = buf + len; buf < end; ++buf)
+		crc = crc32_table[(crc ^ *buf) & 0xff] ^ (crc >> 8);
+	return ~crc & 0xffffffff;
+}
+
+int
+get_debuginfo_link(char *debuginfo_name, size_t len, uint32_t *crc)
+{
+	Elf 		*elfd = NULL;
+	Elf_Scn 	*scn = NULL;
+	Elf_Data 	*data;
+	GElf_Shdr 	shdr;
+	size_t 		shstrndx;
+	int 		n;
+	int 		found = FALSE;
+	char 		*debuglink_data = NULL;
+	int 		debuglink_data_size = 0;
+	int 		offset;
+
+	if (lseek(dwarf_info.vmlinux_fd, 0, SEEK_SET) == SEEK_FAILED) {
+		ERRMSG("Can't seek the kernel file(%s). %s\n",
+				dwarf_info.vmlinux_name, strerror(errno));
+		return -1;
+	}
+
+	elfd = elf_begin(dwarf_info.vmlinux_fd, ELF_C_READ, NULL);
+	if (!elfd) {
+		ERRMSG("Can't get first elf header of %s.\n",
+		    dwarf_info.vmlinux_name);
+	}
+
+	if (elf_getshstrndx(elfd, &shstrndx) < 0) {
+		ERRMSG("Can't get the section index of the string table.\n");
+		goto out;
+	}
+
+	/* search a .gnu_debuglink section in all sections */
+	while ((scn = elf_nextscn(elfd, scn)) != NULL) {
+		char *name;
+
+		if (gelf_getshdr(scn, &shdr) == NULL) {
+			ERRMSG("Can't get section header.\n");
+			goto out;
+		}
+		name = elf_strptr(elfd, shstrndx, shdr.sh_name);
+
+		if (strcmp(name, ".gnu_debuglink") == 0) {
+			found = 1;
+			break;
+		}
+	}
+
+	if (!found)
+		goto out;
+
+	/* we got it :-) */
+
+	/* merge the data to one big buffer (if ever necessary ...) */
+	data = NULL; n = 0;
+	while (n < shdr.sh_size && (data = elf_getdata(scn, data)) != NULL) {
+
+		/* merge */
+		debuglink_data = (char *)realloc(debuglink_data,
+				debuglink_data_size + data->d_size);
+		if (!debuglink_data) {
+			ERRMSG("Unable to (re-)allocate memory in get_debuginfo_link()\n");
+			goto out;
+		}
+		memmove(debuglink_data + debuglink_data_size, data->d_buf, data->d_size);
+		debuglink_data_size += data->d_size;
+	}
+
+	/* now get the elements */
+	strncpy(debuginfo_name, debuglink_data, len);
+	debuginfo_name[len-1] = 0;
+
+	/* move to the CRC: "a four-byte CRC checksum, stored in the same
+	 * endianness used for the executable file itself.  The checksum is
+	 * computed on the debugging information file's full contents by the
+	 * function given below, passing zero as the CRC argument." */
+	offset = strlen(debuglink_data) + 1;
+	offset += 3;
+	offset &= ~3;
+
+	memcpy(crc, debuglink_data + offset, 4);
+
+out:
+	free(debuglink_data);
+	if (elfd)
+		elf_end(elfd);
+	return found ? 0 : -1;
+}
+
+
+void
+get_full_path(const char *executable, char *path, size_t len)
+{
+	if (executable[0] == '/') {
+		/* already a full path ... */
+		strncpy(path, executable, len);
+		path[len-1] = 0;
+	} else {
+		size_t tmp;
+
+		getcwd(path, len);
+		path[len-1] = 0;
+
+		tmp = strlen(path);
+		strncat(path + tmp, executable, len - tmp);
+		path[len-1] = 0;
+	}
+}
+
+int
+dirname(const char *filename, char *dirname, size_t len)
+{
+	char *c;
+	int  n;
+
+	/* find the last '/' */
+	c = strrchr(filename, '/');
+	if (!c)
+		return -1;
+
+	/* preserve the trailing slash */
+	n = c - filename + 1;
+
+	/* check for enough size */
+	if (len <= n)
+		return -1;
+
+	strncpy(dirname, filename, n);
+	dirname[n] = 0;
+
+	return 0;
+}
+
+
+static int
+do_open_and_check_crc(const char *binary, uint32_t crc)
+{
+	int 		fd;
+	unsigned char 	buffer[BUFFER_SIZE];
+	int 		ret;
+	unsigned long	calc_crc = 0;
+
+	fd = open(binary, O_RDONLY);
+	if (fd < 0)
+		return fd;
+
+	while ((ret = read(fd, buffer, BUFFER_SIZE)) > 0) {
+		calc_crc = gnu_debuglink_crc32(calc_crc, buffer, ret);
+	}
+
+	if (calc_crc != crc) {
+		close(fd);
+		return -1;
+	}
+
+	/* back to the beginning */
+	lseek(fd, SEEK_SET, 0);
+
+	return fd;
+}
+
+int
+open_debuginfo_binary(const char 	*kernel_full_path,
+		      const char 	*debuginfo_name,
+		      uint32_t 		crc)
+{
+	int 	fd, ret;
+	char 	dir[PATH_MAX], tmp[PATH_MAX];
+
+	/* 1st: EXECDIR/DEBUGFILE */
+	ret = dirname(kernel_full_path, dir, PATH_MAX);
+	if (ret < 0) {
+		ERRMSG("Couldn't retrieve directory name for '%s'\n",
+				kernel_full_path);
+		return -1;
+	}
+	strcpy(tmp, dir);
+	strncat(tmp, debuginfo_name, PATH_MAX);
+	tmp[PATH_MAX-1] = 0;
+
+	fd = do_open_and_check_crc(tmp, crc);
+	if (fd >= 0)
+		return fd;
+
+	/* 2nd: EXECDIR/.debug/DEBUGFILE */
+	strcpy(tmp, dir);
+	strncat(tmp, ".debug/", PATH_MAX);
+	strncat(tmp, debuginfo_name, PATH_MAX);
+	tmp[PATH_MAX-1] = 0;
+
+	fd = do_open_and_check_crc(tmp, crc);
+	if (fd >= 0)
+		return fd;
+
+	/* 3rd: GLOBALDEBUGDIR/EXECDIR/DEBUGFILE */
+	strcpy(tmp, GLOBALDEBUGDIR);
+	strncat(tmp, dir, PATH_MAX);
+	strncat(tmp, debuginfo_name, PATH_MAX);
+	tmp[PATH_MAX-1] = 0;
+
+	fd = do_open_and_check_crc(tmp, crc);
+	if (fd >= 0)
+		return fd;
+
+	ERRMSG("Cound't find %s\n", debuginfo_name);
+
+	return -1;
+}
+
 int
 open_kernel_file()
 {
 	int fd;
+	static char debuginfo_name[PATH_MAX];
+	uint32_t crc;
+	int ret;
 
 	if ((fd = open(dwarf_info.vmlinux_name, O_RDONLY)) < 0) {
 		ERRMSG("Can't open the kernel file(%s). %s\n",
 		    dwarf_info.vmlinux_name, strerror(errno));
 		return FALSE;
 	}
+
+	/* (temporarily) set the fd */
 	dwarf_info.vmlinux_fd = fd;
+
+	/* check whether it contains a debuginfo link */
+	ret = get_debuginfo_link(debuginfo_name, PATH_MAX, &crc);
+	if (ret == 0) {
+		char kernel_full_path[PATH_MAX];
+		int debuginfo_fd;
+
+		/* make a full path because the debuginfo mechanism needs this */
+		get_full_path(dwarf_info.vmlinux_name, kernel_full_path, PATH_MAX);
+
+		debuginfo_fd = open_debuginfo_binary(kernel_full_path, debuginfo_name, crc);
+		if (debuginfo_fd < 0)
+			return FALSE;
+
+		dwarf_info.vmlinux_fd = debuginfo_fd;
+		dwarf_info.vmlinux_name = debuginfo_name;
+	}
+
 	return TRUE;
 }
 
makedumpfile.h +6 -2
@@ -29,6 +29,7 @@
 #include <libelf.h>
 #include <dwarf.h>
 #include <byteswap.h>
+#include <limits.h>
 #include "diskdump_mod.h"
 
 /*
@@ -297,8 +298,6 @@ do { \
 #define FALSE		(0)
 #define MAX(a,b)	((a) > (b) ? (a) : (b))
 #define MIN(a,b)	((a) < (b) ? (a) : (b))
-#define LONG_MAX	((long)(~0UL>>1))
-#define ULONG_MAX	(~0UL)
 #define ULONGLONG_MAX	(~0ULL)
 #define DEFAULT_ORDER	(4)
 #define TIMEOUT_STDIN	(600)
@@ -658,3 +657,8 @@ struct dwarf_info {
 
 extern struct dwarf_info	dwarf_info;
 
+/* other constants */
+#define SEEK_FAILED	((off_t)-1)
+#define GLOBALDEBUGDIR  "/usr/lib/debug"
+#define BUFFER_SIZE	20505
+

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#1 lore raw

Hi Bernhard,

Quoted 4 lines · Bernhard Walle

This patch implements support for following the debug information link in the .gnu_debuginfo section if the specified binary contains one. That makes it possible to call makedumpfile with -x /boot/vmlinux-<version> on distributions that ship extra -debuginfo packages for the kernel.

Isn't it good to specify the debuginfo file directly instead of your patch ? I confirmed that makedumpfile without your patch can run by specifying the debuginfo file directly.

makedumpfile needs only .debug_info section and doesn't need other sections, so it needs only the debuginfo file. I will add the following comment to the manual for "Debugging Information in Separate Files". Please let me know your opinion.

-------------------------------------------------------------------------------
-x VMLINUX
Specify the first kernel’s VMLINUX with debug information to analyze the first kernel’s memory usage.
+ If there is a file containing debug information and separated from
+ VMLINUX, the file should be specified instead of VMLINUX.
The page size of the first kernel and the second kernel should match.
Example:
# makedumpfile -d 31 -x vmlinux /proc/vmcore dumpfile
-------------------------------------------------------------------------------

Thanks
Ken'ichi Ohmichi

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#2 lore raw
Quoted 9 lines · Ken'ichi Ohmichi
Quoted 4 lines · Bernhard Walle

This patch implements support for following the debug information link in the .gnu_debuginfo section if the specified binary contains one. That makes it possible to call makedumpfile with -x /boot/vmlinux-<version> on distributions that ship extra -debuginfo packages for the kernel.

Isn't it good to specify the debuginfo file directly instead of your patch ? I confirmed that makedumpfile without your patch can run by specifying the debuginfo file directly.

But it needs program headers, right? Very new versions of the binutils don't add the program headers to the debug info file any more (currently only in binutils CVS), so we need gnu_debuglink support anyway. Of course my patch cannot handle this yet. I'll test this after we have the binutils version in our distribution which will be very soon ;-(.

Thanks,
Bernhard

Signature · 9 lines
SUSE LINUX Products GmbH          Tel. +49 (911) 74053-0
Maxfeldstr. 5                     GF: Markus Rex
90409 Nürnberg, Germany           HRB 16746 (AG Nürnberg)
OpenPGP DDAF6454: F61F 34CC 09CA FB82 C9F6  BA4B 8865 3696 DDAF 6454

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec
#3 lore raw
Quoted 7 lines · Bernhard Walle
Quoted 6 lines · Ken'ichi Ohmichi
Quoted 4 lines · Bernhard Walle

This patch implements support for following the debug information link in the .gnu_debuginfo section if the specified binary contains one. That makes it possible to call makedumpfile with -x /boot/vmlinux-<version> on distributions that ship extra -debuginfo packages for the kernel.

Quoted 5 lines
Quoted 3 lines

Isn't it good to specify the debuginfo file directly instead of your patch ? I confirmed that makedumpfile without your patch can run by specifying the debuginfo file directly.

But it needs program headers, right?

After reading the source code again I don't think so.

While I like the idea of following the .gnu_debuglink more I can also accept your decision that the user has to specify the debug info file manually.

Thanks,
Bernhard

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#4 lore raw
In reply to Ken'ichi Ohmichi
Quoted 21 lines · Ken'ichi Ohmichi

Hi Bernhard,

Quoted 4 lines · Bernhard Walle

This patch implements support for following the debug information link in the .gnu_debuginfo section if the specified binary contains one. That makes it possible to call makedumpfile with -x /boot/vmlinux-<version> on distributions that ship extra -debuginfo packages for the kernel.

Isn't it good to specify the debuginfo file directly instead of your patch ? I confirmed that makedumpfile without your patch can run by specifying the debuginfo file directly.

makedumpfile needs only .debug_info section and doesn't need other sections, so it needs only the debuginfo file. I will add the following comment to the manual for "Debugging Information in Separate Files". Please let me know your opinion.

-------------------------------------------------------------------------------
-x VMLINUX
Specify the first kernel’s VMLINUX with debug information to analyze the first kernel’s memory usage.

Review

Quoted 2 lines
(quoted diff) +2 -0
+             If there is a file containing debug information and separated from
+             VMLINUX, the file should be specified instead of VMLINUX.

This behavior seems to be different from that of crash. If a vmlinux does not contain debug_info and a separate vmlinux-<version>.debug is present, the 'crash' would try to look up for the accompanying debug file.

The way 'crash' looks up for the accompanying debug file seems ambiguous and not documented. The purpose of makedumpfile is to create an output file for 'crash' to consume. I hope 'crash' and 'makedumpfile' can use same semantics to specify the vmlinux and its accompanying debug file.

Thanks,
- jay

Quoted 7 lines

The page size of the first kernel and the second kernel should match.
Example:
# makedumpfile -d 31 -x vmlinux /proc/vmcore dumpfile
-------------------------------------------------------------------------------

Quoted 7 lines

Thanks
Ken'ichi Ohmichi

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#5 lore raw
Quoted 33 lines · Jay Lan
Quoted 22 lines · Ken'ichi Ohmichi

Hi Bernhard,

Quoted 4 lines · Bernhard Walle

This patch implements support for following the debug information link in the .gnu_debuginfo section if the specified binary contains one. That makes it possible to call makedumpfile with -x /boot/vmlinux-<version> on distributions that ship extra -debuginfo packages for the kernel.

Isn't it good to specify the debuginfo file directly instead of your patch ? I confirmed that makedumpfile without your patch can run by specifying the debuginfo file directly.

makedumpfile needs only .debug_info section and doesn't need other sections, so it needs only the debuginfo file. I will add the following comment to the manual for "Debugging Information in Separate Files". Please let me know your opinion.

-------------------------------------------------------------------------------
-x VMLINUX
Specify the first kernel’s VMLINUX with debug information to analyze the first kernel’s memory usage.

Review

Quoted 2 lines
(quoted diff) +2 -0
+             If there is a file containing debug information and separated from
+             VMLINUX, the file should be specified instead of VMLINUX.

This behavior seems to be different from that of crash. If a vmlinux does not contain debug_info and a separate vmlinux-<version>.debug is present, the 'crash' would try to look up for the accompanying debug file.

Quoted 5 lines

The way 'crash' looks up for the accompanying debug file seems ambiguous and not documented. The purpose of makedumpfile is to create an output file for 'crash' to consume. I hope 'crash' and 'makedumpfile' can use same semantics to specify the vmlinux and its accompanying debug file.

The crash utility hides the details of there being a separate debug file in the same way the gdb does when working with a binary executable that has a separate debuginfo file. It tries *not* to be ambiguous, i.e., the point is to stay true to the "crash vmlinux vmcore" model.

Not only that, crash needs stuff such as the kernel's static data, which is located only in the stripped vmlinux file. That's apparently not the case with makedumpfile.

That being said, does any other distro besides RHEL3 actually use the split vmlinux/vmlinux.debug format? Thankfully Red Hat came to its senses in RHEL4 and beyond...

Dave

Quoted 21 lines

Thanks,
- jay

Quoted 14 lines

The page size of the first kernel and the second kernel should match.
Example:
# makedumpfile -d 31 -x vmlinux /proc/vmcore dumpfile
-------------------------------------------------------------------------------

Thanks
Ken'ichi Ohmichi

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#6 lore raw

Hello,

Quoted 4 lines · Dave Anderson

The crash utility hides the details of there being a separate debug file in the same way the gdb does when working with a binary executable that has a separate debuginfo file. It tries *not* to be ambiguous, i.e., the point is to stay true to the "crash vmlinux vmcore" model.

It's documented in the GDB documentation:
http://sourceware.org/gdb/current/onlinedocs/gdb_16.html#SEC154

Quoted 3 lines

That being said, does any other distro besides RHEL3 actually use the split vmlinux/vmlinux.debug format? Thankfully Red Hat came to its senses in RHEL4 and beyond...

SUSE uses the split out debug information, starting from SLES 10 (also openSUSE). It makes sense on architectures that don't need a separate, bootable kernel image (like x86_64 and i586) but can boot the ELF file directly such as PPC and IA64.

Thanks,
Bernhard

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#7 lore raw
Quoted 10 lines · Bernhard Walle

Hello,

Quoted 4 lines · Dave Anderson

The crash utility hides the details of there being a separate debug file in the same way the gdb does when working with a binary executable that has a separate debuginfo file. It tries *not* to be ambiguous, i.e., the point is to stay true to the "crash vmlinux vmcore" model.

It's documented in the GDB documentation:
http://sourceware.org/gdb/current/onlinedocs/gdb_16.html#SEC154

Thanks for the pointer, Bernhard. I installed kernel-debuginfo rpm but crash still failed to find the debug information... I had to copy the kernel-<version>.debug to /boot for it to work.

So, i think it is a good idea for makedumpfile to follow the same convension as crash and gdb, Ken'ichi?

Thanks,
- jay

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#8 lore raw

Hello,

Quoted 7 lines · Jay Lan
Quoted 6 lines · Bernhard Walle
Quoted 4 lines · Dave Anderson

The crash utility hides the details of there being a separate debug file in the same way the gdb does when working with a binary executable that has a separate debuginfo file. It tries *not* to be ambiguous, i.e., the point is to stay true to the "crash vmlinux vmcore" model.

Quoted 6 lines
Quoted 2 lines

It's documented in the GDB documentation:
http://sourceware.org/gdb/current/onlinedocs/gdb_16.html#SEC154

Thanks for the pointer, Bernhard. I installed kernel-debuginfo rpm but crash still failed to find the debug information... I had to copy the kernel-<version>.debug to /boot for it to work.

On SLES? I never had problems. Maybe didn't you specify the full path? I.e. not

cd /boot
crash vmlinux-<version>

but

cd /
crash /boot/vmlinux-<version>

Thanks,
Bernhard

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#9 lore raw
In reply to Jay Lan

Hi Jay,

Sorry for the late response.

Quoted 12 lines · Jay Lan
Quoted 10 lines · Bernhard Walle

Hello,

Quoted 4 lines · Dave Anderson

The crash utility hides the details of there being a separate debug file in the same way the gdb does when working with a binary executable that has a separate debuginfo file. It tries *not* to be ambiguous, i.e., the point is to stay true to the "crash vmlinux vmcore" model.

It's documented in the GDB documentation:
http://sourceware.org/gdb/current/onlinedocs/gdb_16.html#SEC154

Quoted 6 lines

Thanks for the pointer, Bernhard. I installed kernel-debuginfo rpm but crash still failed to find the debug information... I had to copy the kernel-<version>.debug to /boot for it to work.

So, i think it is a good idea for makedumpfile to follow the same convension as crash and gdb, Ken'ichi?

No, I don't think it is worthy that a kernel file is specified *only* for getting the path to a debuginfo file. It is smart to specify a debuginfo file directly. The crash utility needs both a kernel file and a debuginfo file, but makedumpfile needs only a debuginfo file as I said.

BTW, I recommend using a makedumpfile's CONFIGFILE instead of a debuginfo file. If a system has a CONFIGFILE, makedumpfile can run without a debuginfo file. It is smaller than a debuginfo file, and it is easy to distribute it to each system.
I don't think each system should have a debuginfo file, because the file is big and a user may analyze a dumpfile on a remote analysis system.

Thanks
Ken'ichi Ohmichi

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#10 lore raw
Quoted 28 lines · Ken'ichi Ohmichi

Hi Jay,

Sorry for the late response.

Quoted 8 lines · Jay Lan
Quoted 7 lines · Bernhard Walle

Hello,

Quoted 4 lines · Dave Anderson

The crash utility hides the details of there being a separate debug file in the same way the gdb does when working with a binary executable that has a separate debuginfo file. It tries *not* to be ambiguous, i.e., the point is to stay true to the "crash vmlinux vmcore" model.

Quoted 8 lines
Quoted 2 lines

It's documented in the GDB documentation:
http://sourceware.org/gdb/current/onlinedocs/gdb_16.html#SEC154

Thanks for the pointer, Bernhard. I installed kernel-debuginfo rpm but crash still failed to find the debug information... I had to copy the kernel-<version>.debug to /boot for it to work.

So, i think it is a good idea for makedumpfile to follow the same convension as crash and gdb, Ken'ichi?

No, I don't think it is worthy that a kernel file is specified *only* for getting the path to a debuginfo file. It is smart to specify a debuginfo file directly. The crash utility needs both a kernel file and a debuginfo file, but makedumpfile needs only a debuginfo file as I said.

Quoted 7 lines

BTW, I recommend using a makedumpfile's CONFIGFILE instead of a debuginfo file. If a system has a CONFIGFILE, makedumpfile can run without a debuginfo file. It is smaller than a debuginfo file, and it is easy to distribute it to each system.
I don't think each system should have a debuginfo file, because the file is big and a user may analyze a dumpfile on a remote analysis system.

Ohmichi San,

Any way to make kernel debugging easier is great news!!! However...

If i run makedumpfile -x option to produce a dumpfile as below:

 # makedumpfile -c -d 31 -x VMLINUX VMCORE DUMPFILE

The size of these files are:
16468 -rw------- 1 jlan wheel 16983716 2007-05-29 10:23 DUMPFILE

1719048 -r-------- 1 jlan wheel 1760303684 2007-05-24 11:35 VMCORE
55488 -rwxr-xr-x 1 jlan wheel 56819470 2007-05-24 11:33 VMLINUX

and crash was able to read and analyze the DUMPFILE together with the VMLINUX.

Now when i used makedumpfile -g option to generate a CONFIGFILE:

 # makedumpfile -g CONFIGFILE -x VMLINUX

the size of CONFIGFILE is only 696 bytes. Besides, makedumpfile failed to generate a DUMPFILE using the CONFIGFILE:

 # makedumpfile -c -d 31 -i CONFIGFILE VMCORE DUMPFILE
 CONFIGFILE and VMCORE don't match.

makedumpfile Failed.

I think the CONFIGFILE is too small to be good?

What did i miss here?

Thanks,
- jay

Quoted 4 lines

Thanks
Ken'ichi Ohmichi

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

#11 lore raw
Quoted 10 lines · Jay Lan

If i run makedumpfile -x option to produce a dumpfile as below:

 # makedumpfile -c -d 31 -x VMLINUX VMCORE DUMPFILE

The size of these files are:
16468 -rw------- 1 jlan wheel 16983716 2007-05-29 10:23 DUMPFILE

1719048 -r-------- 1 jlan wheel 1760303684 2007-05-24 11:35 VMCORE
55488 -rwxr-xr-x 1 jlan wheel 56819470 2007-05-24 11:33 VMLINUX

Quoted 8 lines

and crash was able to read and analyze the DUMPFILE together with the VMLINUX.

Now when i used makedumpfile -g option to generate a CONFIGFILE:

 # makedumpfile -g CONFIGFILE -x VMLINUX

the size of CONFIGFILE is only 696 bytes.

And what's the problem? Did you look at the config file? It's not a .config.

Quoted 7 lines

Besides, makedumpfile failed to generate a DUMPFILE using the CONFIGFILE:

 # makedumpfile -c -d 31 -i CONFIGFILE VMCORE DUMPFILE
 CONFIGFILE and VMCORE don't match.

makedumpfile Failed.

Try to replace the VERSION field of the config file by the version of the kernel. I have here the behaviour that the VERSION is filled with the version of the running kernel, not of the kernel for which the config file is generated. I'm looking into this.

Thanks,
Bernhard

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec