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 <[EMAIL PROTECTED]>

---
 makedumpfile.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/makedumpfile.c
+++ b/makedumpfile.c
@@ -2271,10 +2271,10 @@ read_vmcoreinfo_basic_info(void)
        return TRUE;
 }
 
-unsigned long
+unsigned long 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 +2291,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);

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

Reply via email to