Hi Bernhard,
Bernhard Walle wrote:
> 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).
I agree with this patch basically. But I have not tested kdump on PPC64
platform (PPC32 also) and I don't know it well. So may I ask a question ?
For PPC64 kdump, is it common thing that makedumpfile runs on PPC32 ?
In other words, do you use PPC32 kernel as 2nd-kernel for PPC64 kdump ?
> Signed-off-by: Bernhard Walle <[EMAIL PROTECTED]>
>
> ---
> 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>
This is not related to this purpose, but this is reasonable and will
be merged as the other patch ;-)
> #include "makedumpfile.h"
>
> struct symbol_table symbol_table;
> @@ -2274,7 +2273,7 @@ read_vmcoreinfo_basic_info(void)
> 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 +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);
>
Thanks
Ken'ichi Ohmichi
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
