> On Tue, Oct 17, 2006 at 03:37:16PM -0400, Dave Anderson wrote:
> >
> > This patch below looks to only be necessary in dumpfiles, but it seems
> > like, given that the x86_64 user_regs_struct is unavailable in 2.6
> > vmlinux files, that the initializations in get_netdump_regs_x86_64()
> > would never get done -- because VALID_STRUCT(user_regs_struct) would
> > fail, right?
> >
> > @@ -1562,8 +1566,10 @@ get_netdump_regs_x86_64(struct bt_info *
> > if (is_task_active(bt->task))
> > bt->flags |= BT_DUMPFILE_SEARCH;
> >
> > - if ((NETDUMP_DUMPFILE() || KDUMP_DUMPFILE()) &&
> > - VALID_STRUCT(user_regs_struct) && (bt->task == tt->panic_task)) {
> > + if (((NETDUMP_DUMPFILE() || KDUMP_DUMPFILE()) &&
> > + VALID_STRUCT(user_regs_struct) && (bt->task == tt->panic_task)) ||
> > + (KDUMP_DUMPFILE() && has_unwind_info && (bt->flags &
> > + BT_DUMPFILE_SEARCH))) {
>
> I add this last check to workaround the user_regs_struct not getting
> initialized problem. Thats why I omit the VALID_STRUCT() check, and let it
> pass if we have the unwind_info.
> This should be a temporary arrangement till we fix the user_regs_struct
> problem. The idea here is to read the register states for all the active
> tasks from the NT_PRSTATUS section of the dumpfile for kdump(in the case
> where we have the has_unwind_info set). The other case for kdump where we
> do not have the unwind_info stays as it is.
>
My mistake -- I got lost in the "if" statement and missed the || logic.
Sorry for the confusion...
> But again, this is temporary till we fix the user_regs_struct issue :)
But again, since it's not a crash issue, we can't "fix" it. Anyway,
this is fine, given that it's very unlikely these offsets will
ever change. If they do, we deal with it at that time.
>
> >
> > There does seem to be some unnecessary "kernel-port" left-overs that
> > should be pruned. Like the __get_user_nocheck(), __get_user_size()
> > and __get_user_asm() definitions are superfluous, since they're only
> > needed by __get_user(), which is not used.
>
> Actually __get_user is a TBD.
OK, but __get_user(), if we ever need it, appears to be used to
read either the dwarf CFI data, or the kernel stack contents?
So it can be substituted with the GET_STACK_DATA() macro to
pull stuff from the local copy of the kernel stack -- or just a
direct access if it's reading the copy of the dwarf data.
In any case, it shouldn't be a problem crafting a __get_user()
implementation, and all the other __get_xxx functions can be
removed since there's no way they could ever apply when
operating in user (crash) space.
Thanks,
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
