Re: [Crash-utility] [PATCH 1/1] xendump: Use off_t not long for 32bit code

----- Original Message ----- > On Wed, Jun 11, 2014 at 01:28:27PM -0400, Don Slutz wrote: > > This enables crash to handle xen dumps that are larger then 4G > > in size in 32bit mode. > > > > Signed-off-by: Don Slutz <dslutz(a)verizon.com&gt; > > --- > > This is the same as was sent as an attachment. Just a clean top post. > > > > x86.c | 10 ++++----- > > x86_64.c | 10 ++++----- > > xendump.c | 74 > > +++++++++++++++++++++++++++++++++------------------------------ > > xendump.h | 6 +++--- > > 4 files changed, 52 insertions(+), 48 deletions(-) > > > > diff --git a/x86.c b/x86.c > > index 833a11b..608bb88 100644 > > --- a/x86.c > > +++ b/x86.c > > @@ -4897,7 +4897,7 @@ x86_xendump_p2m_create(struct xendump_data *xd) > > "MEMBER_OFFSET(vcpu_guest_context, ctrlreg): %ld\n", > > ctrlreg_offset); > > > > - offset = (off_t)xd->xc_core.header.xch_ctxt_offset + > > + offset = xd->xc_core.header.xch_ctxt_offset + > > (off_t)ctrlreg_offset; > > Good job. However, as I can see this fix requires explicit type > conversions in many places. I am almost sure that next time when > somebody improve the code then he/she will forget about this needed > type conversions. So maybe it is worth creating new struct which > will have xch_ctxt_offset as off_t instead of unsigned long and > do this conversion once somewhere. > > Daniel Hi Daniel, I'm confused -- isn't that exactly what Don has done? I.e., changing the type of the xen_core_header's xch_ctxt_offset, xch_index_offset and xch_pages_offset members from unsigned long to off_t. It does require explicit type conversions when assigning them from the obsoleted xenctrl.h xc_core_header structures where they were/are unsigned ints, and when assigning them from shdr.sh_offset values, but for the most part, the patch mostly removes the (off_t) casts.

I don't have any sample 32-bit Xen ELF coredumps larger than 4GB,

and our support organization has never filed any bugs reporting this issue. (Could it require later versions of the dom0 kernel or other Xen sources?) Anyway, the patch seems safe enough, and

doesn't break any of my other sample x86 and x86_64 Xen dumpfiles.