Itsuro ODA wrote: > > > Hmm, anyway, crash is used by analysts who understand what he do. > I think strict checking is not necessary. > You're right -- I agree -- let's just go with the "xen-syms" check. > > > But -- perhaps the simplest way is the better way, and your check > > for the first 8 bytes in the "xen-syms" namelist name is sufficient > > for now. > > Yes. > > > However, we should also have a "--hyper" command line argument to > > force a hypervisor session in case everything else fails. But let's add --hyper to "long_options" just in case... > > > Sorry. x86_64.c is broken now. I will fix. > No problem. One thing re: x86_64 -- unlike x86, please create your own xen-specific backtrace function to plug into the machdep->back_trace function pointer. I'm pretty sure you won't be able to make the current version work for xen! > > > 2. I don't see why it's necessary to bother with the > > additional BT_XEN_HYPER_MODE flag? It seems > > its usage could be replaced with XEN_HYPER_MODE(), > > which you also use in lkcd_x86_trace.c. > > > > I want to use XEN_HYPER_MODE() too, but > unfortunatly find_trace() uses local valiable "pc" !! > Ah -- that's right, I remember running into the same thing... How about doing an #undef XEN_HYPER_MODE in lkcd_x86_trace.h, and then creating a XEN_HYPER_MODE() function in lkcd_x86_trace.c? > > > But on the whole, the patch looks pretty clean, > > and as long as the "binary-file-type-determination" can > > be resolved cleanly, it looking pretty good. > > > > Thanks, > > Dave > > I will be updating http://people.redhat.com with an updated version before long, but I will leave 4.0-3.8 around if you still need it. It can be accessed by: http://people.redhat.com/anderson/crash-4.0-3.8.tar.gz Thanks, Dave -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility