[Crash-utility] Re:[RFC] Crash patch for DWARF CFI based unwind support

[Dave Anderson]

> 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