From mboxrd@z Thu Jan 1 00:00:00 1970 From: Don Slutz Subject: Re: [PATCH v5 11/17] xenctx: Add -d (--dump-as-stack) option to dump memory at daddr as a stack. Date: Thu, 27 Mar 2014 13:05:26 -0400 Message-ID: <53345A56.8090003@terremark.com> References: <1395342425-16260-1-git-send-email-dslutz@verizon.com> <1395342425-16260-12-git-send-email-dslutz@verizon.com> <1395413823.19839.127.camel@kazak.uk.xensource.com> <53304DAB.20807@terremark.com> <1395935916.22909.170.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1395935916.22909.170.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell , Don Slutz Cc: Stefano Stabellini , George Dunlap , Don Slutz , Ian Jackson , xen-devel@lists.xen.org, Jan Beulich List-Id: xen-devel@lists.xenproject.org On 03/27/14 11:58, Ian Campbell wrote: > On Mon, 2014-03-24 at 11:22 -0400, Don Slutz wrote: >> On 03/21/14 10:57, Ian Campbell wrote: >>> It's starting to seem like print_mem and print_stack should be called >>> from main instead of here. In other words actually have multiple modes >>> instead of tuffing things in as special cases here. >> The issue is that ctx (vcpu_guest_context_any_t) does not exist >> in main and is needed by map_page() (called from these). >> >> dump_ctx() is the routine that gets this and guest_word_size, >> guest_protected_mode, and ctxt_word_size. >> >> And so yes, this part of dump_ctx() could be moved to main >> and/or ctx could be made global. >> >> Let me know if I should rework all this. > It does sound like some refactoring might be in order. Lets get this > series put to bed first though. Ok. > >>>> , >>>> @@ -1110,6 +1121,11 @@ int main(int argc, char **argv) >>>> xenctx.do_memory = 1; >>>> do_default = 0; >>>> break; >>>> + case 'd': >>>> + xenctx.stk_addr = strtoull(optarg, NULL, 0); >>> You can reuse mem_addr here, can't you? >>> >>> >>> >> Nope. If both -d and -m are specified, then both are done. > Is that useful? > > Maybe. I did use it to show the difference between 16 bit and 32 bit output (also v8 stuff). Not clear I would ever use both. -Don Slutz