[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command '
From: |
HATAYAMA Daisuke |
Subject: |
Re: [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump guest's memory |
Date: |
Fri, 16 Mar 2012 12:23:15 +0900 ( ) |
From: Wen Congyang <address@hidden>
Subject: [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump
guest's memory
Date: Wed, 14 Mar 2012 10:11:35 +0800
> +/*
> + * QEMU dump
> + *
> + * Copyright Fujitsu, Corp. 2011
> + *
Now 2012.
> + /*
> + * calculate phdr_num
> + *
> + * the type of phdr->num is uint16_t, so we should avoid overflow
e_phnum is correct.
> + */
> + s->phdr_num = 1; /* PT_NOTE */
> + if (s->list.num < (1 << 16) - 2) {
s->list.num < UINT16_MAX is better.
> + s->phdr_num += s->list.num;
> + s->have_section = false;
> + } else {
> + s->have_section = true;
> + s->phdr_num = PN_XNUM;
> +
> + /* the type of shdr->sh_info is uint32_t, so we should avoid
> overflow */
> + if (s->list.num > (1ULL << 32) - 2) {
s->list.num < UINT32_MAX is better.
> + s->sh_info = 0xffffffff;
UINT32_MAX is better. Is it rough around here?
> + } else {
> + s->sh_info += s->list.num;
> + }
> + }
Now orders of processings in positive and negative cases for e_phnum
and sh_info are different. It's better to make them sorted in the same
order.
if (phdr_num not overflow?) {
not overflow case;
} else {
overflow case;
if (sh_info not overflow?) {
not overflow case;
} else {
overflow case;
}
}
is better.
Thanks.
HATAYAMA, Daisuke
- [Qemu-devel] [RFC][PATCH 09/14 v9] target-i386: add API to get dump info, (continued)
- [Qemu-devel] [RFC][PATCH 09/14 v9] target-i386: add API to get dump info, Wen Congyang, 2012/03/13
- [Qemu-devel] [RFC][PATCH 10/14 v9] make gdb_id() generally avialable, Wen Congyang, 2012/03/13
- [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump guest's memory, Wen Congyang, 2012/03/13
- Re: [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump guest's memory, Luiz Capitulino, 2012/03/14
- Re: [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump guest's memory, Wen Congyang, 2012/03/14
- Re: [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump guest's memory, Luiz Capitulino, 2012/03/15
- Re: [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump guest's memory, Wen Congyang, 2012/03/16
- Re: [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump guest's memory, Wen Congyang, 2012/03/18
- Re: [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump guest's memory, Wen Congyang, 2012/03/19
- Re: [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump guest's memory, Luiz Capitulino, 2012/03/19
- Re: [Qemu-devel] [RFC][PATCH 11/14 v9] introduce a new monitor command 'dump' to dump guest's memory,
HATAYAMA Daisuke <=
- [Qemu-devel] [RFC][PATCH 12/14 v9] support to cancel the current dumping, Wen Congyang, 2012/03/13
- [Qemu-devel] [RFC][PATCH 13/14 v9] support to query dumping status, Wen Congyang, 2012/03/13
- [Qemu-devel] [RFC][PATCH 14/14 v9] allow user to dump a fraction of the memory, Wen Congyang, 2012/03/13
- Re: [Qemu-devel] [RFC][PATCH 00/14 v9] introducing a new, dedicated memory dump mechanism, Luiz Capitulino, 2012/03/14