[PATCH] Parse 64 bit VMCOREINFO on 32 bit userland
Bernhard Walle
bwalle at suse.de
Thu Nov 27 10:00:34 EST 2008
This bug fixes the problem that on a 32 bit userland makedumpfile (as common
on the PPC platform) the parsing of the 64 bit VMCOREINFO fails with:
# makedumpfile -c /home/sachin/dump/vmcore vmcore.filtered
read_vmcoreinfo_symbol: Invalid data in /tmp/vmcoreinfowVoyJK:
SYMBOL(mem_section)=c000000000bb4400
We just need to assume that the symbols are always 'unsigned long long' (64 bit)
instead of 'unsigned long' (native pointer size on Linux platforms).
Signed-off-by: Bernhard Walle <bwalle at suse.de>
---
makedumpfile.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -13,7 +13,6 @@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*/
-#include <stdlib.h>
#include "makedumpfile.h"
struct symbol_table symbol_table;
@@ -2274,7 +2273,7 @@ read_vmcoreinfo_basic_info(void)
unsigned long
read_vmcoreinfo_symbol(char *str_symbol)
{
- unsigned long symbol = NOT_FOUND_SYMBOL;
+ unsigned long long symbol = NOT_FOUND_SYMBOL;
char buf[BUFSIZE_FGETS], *endp;
unsigned int i;
@@ -2291,8 +2290,8 @@ read_vmcoreinfo_symbol(char *str_symbol)
if (buf[i - 1] == '\n')
buf[i - 1] = '\0';
if (strncmp(buf, str_symbol, strlen(str_symbol)) == 0) {
- symbol = strtoul(buf + strlen(str_symbol), &endp, 16);
- if ((!symbol || symbol == ULONG_MAX)
+ symbol = strtoull(buf + strlen(str_symbol), &endp, 16);
+ if ((!symbol || symbol == ULONGLONG_MAX)
|| strlen(endp) != 0) {
ERRMSG("Invalid data in %s: %s",
info->name_vmcoreinfo, buf);
More information about the kexec
mailing list