debuginfo does not pick user_regs_struct on x86_64
 

----- Original Message -----
> On RHEL6(x86_64), debuginfo does not pick user_regs_struct on x86_64.
>
> # gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux
> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6)
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law. Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from
> /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
> (gdb) ptype struct user_regs_struct
> No struct type named user_regs_struct.
>
> ---
> x86_64.c | 25 +++++++++++++++++++++++++
> 1 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/x86_64.c b/x86_64.c
> index a782334..853a1aa 100644
> --- a/x86_64.c
> +++ b/x86_64.c
> @@ -332,6 +332,31 @@ x86_64_init(int when)
> MEMBER_OFFSET_INIT(user_regs_struct_ss,
> "user_regs_struct", "ss");
> STRUCT_SIZE_INIT(user_regs_struct, "user_regs_struct");
> + if (!VALID_STRUCT(user_regs_struct)) {
> + /* Use this hardwired version -- sometimes the
> + * debuginfo doesn't pick this up even though
> + * it exists in the kernel; it shouldn't change.
> + */
> + struct x86_64_user_regs_struct {
> + unsigned long long r15, r14, r13, r12, bp, bx;
> + unsigned long long r11, r10, r9, r8, ax, cx, dx;
> + unsigned long long si, di, orig_ax, ip, cs;
> + unsigned long long flags, sp, ss, fs_base;
> + unsigned long long gs_base, ds, es, fs, gs;
> + };
> + ASSIGN_SIZE(user_regs_struct) =
> + sizeof(struct x86_64_user_regs_struct);
> + ASSIGN_OFFSET(user_regs_struct_rip) =
> + offsetof(struct x86_64_user_regs_struct, ip);
> + ASSIGN_OFFSET(user_regs_struct_rsp) =
> + offsetof(struct x86_64_user_regs_struct, sp);
> + ASSIGN_OFFSET(user_regs_struct_eflags) =
> + offsetof(struct x86_64_user_regs_struct, flags);
> + ASSIGN_OFFSET(user_regs_struct_cs) =
> + offsetof(struct x86_64_user_regs_struct, cs);
> + ASSIGN_OFFSET(user_regs_struct_ss) =
> + offsetof(struct x86_64_user_regs_struct, ss);
> + }
> machdep->vmalloc_start = x86_64_vmalloc_start;
> vt->vmalloc_start = machdep->vmalloc_start();
> machdep->init_kernel_pgd();
> --
> 1.7.1

Right -- over the years it has been "found" in some kernel
version's debuginfo data, but certainly not in all kernel
versions. (mostly not)

But anyway, its potential non-existence has been worked
around such that the offset_table entries are not required.

I did test it out on ~150 sample dumpfiles, and while it doesn't
break anything, it doesn't help either -- the "bt -a" output is
identical with or without the patch.

Did you actually have a situation where a backtrace failed
without it -- but then worked OK with your patch?

And was there a reason you used "unsigned long long" declarations?
I understand they are the same, but the kernel uses "unsigned long".
Why the difference?

Dave




--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

debuginfo does not pick user_regs_struct on x86_64
 

At 03/01/2011 11:58 PM, Dave Anderson Write:
>
>
> ----- Original Message -----
>> On RHEL6(x86_64), debuginfo does not pick user_regs_struct on x86_64.
>>
>> # gdb /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux
>> GNU gdb (GDB) Red Hat Enterprise Linux (7.1-29.el6)
>> Copyright (C) 2010 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law. Type "show
>> copying"
>> and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> Reading symbols from
>> /usr/lib/debug/lib/modules/2.6.32-71.el6.x86_64/vmlinux...done.
>> (gdb) ptype struct user_regs_struct
>> No struct type named user_regs_struct.
>>
>> ---
>> x86_64.c | 25 +++++++++++++++++++++++++
>> 1 files changed, 25 insertions(+), 0 deletions(-)
>>
>> diff --git a/x86_64.c b/x86_64.c
>> index a782334..853a1aa 100644
>> --- a/x86_64.c
>> +++ b/x86_64.c
>> @@ -332,6 +332,31 @@ x86_64_init(int when)
>> MEMBER_OFFSET_INIT(user_regs_struct_ss,
>> "user_regs_struct", "ss");
>> STRUCT_SIZE_INIT(user_regs_struct, "user_regs_struct");
>> + if (!VALID_STRUCT(user_regs_struct)) {
>> + /* Use this hardwired version -- sometimes the
>> + * debuginfo doesn't pick this up even though
>> + * it exists in the kernel; it shouldn't change.
>> + */
>> + struct x86_64_user_regs_struct {
>> + unsigned long long r15, r14, r13, r12, bp, bx;
>> + unsigned long long r11, r10, r9, r8, ax, cx, dx;
>> + unsigned long long si, di, orig_ax, ip, cs;
>> + unsigned long long flags, sp, ss, fs_base;
>> + unsigned long long gs_base, ds, es, fs, gs;
>> + };
>> + ASSIGN_SIZE(user_regs_struct) =
>> + sizeof(struct x86_64_user_regs_struct);
>> + ASSIGN_OFFSET(user_regs_struct_rip) =
>> + offsetof(struct x86_64_user_regs_struct, ip);
>> + ASSIGN_OFFSET(user_regs_struct_rsp) =
>> + offsetof(struct x86_64_user_regs_struct, sp);
>> + ASSIGN_OFFSET(user_regs_struct_eflags) =
>> + offsetof(struct x86_64_user_regs_struct, flags);
>> + ASSIGN_OFFSET(user_regs_struct_cs) =
>> + offsetof(struct x86_64_user_regs_struct, cs);
>> + ASSIGN_OFFSET(user_regs_struct_ss) =
>> + offsetof(struct x86_64_user_regs_struct, ss);
>> + }
>> machdep->vmalloc_start = x86_64_vmalloc_start;
>> vt->vmalloc_start = machdep->vmalloc_start();
>> machdep->init_kernel_pgd();
>> --
>> 1.7.1
>
> Right -- over the years it has been "found" in some kernel
> version's debuginfo data, but certainly not in all kernel
> versions. (mostly not)
>
> But anyway, its potential non-existence has been worked
> around such that the offset_table entries are not required.
>
> I did test it out on ~150 sample dumpfiles, and while it doesn't
> break anything, it doesn't help either -- the "bt -a" output is
> identical with or without the patch.

The command "bt -a" can work fine without the patch now, because we
have checked it in get_netdump_regs_x86_64().

We have a new hardware to do dump, and use makedumpfile to generate
vmcore. Our hardware can work when the OS is out of controll(for
example: dead loop). When we use crash to analyze the vmcore, bt can
not work, because there is no panic task.

We have provide the value of register in the vmcore(the format is elf_prstatus,
it is same with normal kdump's vmcore). So I write the code to use the register
from notes in the vmcore when we do not find panic task. So we should know
these offsets. We can check it where we use, but I think it's better to check
and init it in x86_64_init().

>
> Did you actually have a situation where a backtrace failed
> without it -- but then worked OK with your patch?
>
> And was there a reason you used "unsigned long long" declarations?
> I understand they are the same, but the kernel uses "unsigned long".
> Why the difference?

Does this case exist: we build crash on x86 box and use it to analyze the
vmcore which is generate in x86_64 box? If it does not exist, I think
we should use "unsigend long", the same with the kernel.

>
> Dave
>
>
>
>
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

debuginfo does not pick user_regs_struct on x86_64
 

----- Original Message -----
> >
> > Right -- over the years it has been "found" in some kernel
> > version's debuginfo data, but certainly not in all kernel
> > versions. (mostly not)
> >
> > But anyway, its potential non-existence has been worked
> > around such that the offset_table entries are not required.
> >
> > I did test it out on ~150 sample dumpfiles, and while it doesn't
> > break anything, it doesn't help either -- the "bt -a" output is
> > identical with or without the patch.
>
> The command "bt -a" can work fine without the patch now, because we
> have checked it in get_netdump_regs_x86_64().
>
> We have a new hardware to do dump, and use makedumpfile to generate
> vmcore. Our hardware can work when the OS is out of controll(for
> example: dead loop). When we use crash to analyze the vmcore, bt can
> not work, because there is no panic task.
>
> We have provide the value of register in the vmcore(the format is elf_prstatus,
> it is same with normal kdump's vmcore). So I write the code to use the register
> from notes in the vmcore when we do not find panic task. So we should know
> these offsets. We can check it where we use, but I think it's better to check
> and init it in x86_64_init().

Interesting -- so you essentially have an alternative dumping method
whose format simulates a kdump.

> >
> > Did you actually have a situation where a backtrace failed
> > without it -- but then worked OK with your patch?
> >
> > And was there a reason you used "unsigned long long" declarations?
> > I understand they are the same, but the kernel uses "unsigned long".
> > Why the difference?
>
> Does this case exist: we build crash on x86 box and use it to analyze the
> vmcore which is generate in x86_64 box? If it does not exist, I think
> we should use "unsigend long", the same with the kernel.

No, that cannot be done. You can build an x86 binary on an x86_64 machine
with "make target=X86", but not the other way around.

I'll revert them to "unsigned long" declarations, and queue the patch
for crash-5.1.3.

Thanks,
Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

debuginfo does not pick user_regs_struct on x86_64
 

----- Original Message -----
> >
> > Right -- over the years it has been "found" in some kernel
> > version's debuginfo data, but certainly not in all kernel
> > versions. (mostly not)
> >
> > But anyway, its potential non-existence has been worked
> > around such that the offset_table entries are not required.
> >
> > I did test it out on ~150 sample dumpfiles, and while it doesn't
> > break anything, it doesn't help either -- the "bt -a" output is
> > identical with or without the patch.
>
> The command "bt -a" can work fine without the patch now, because we
> have checked it in get_netdump_regs_x86_64().
>
> We have a new hardware to do dump, and use makedumpfile to generate
> vmcore. Our hardware can work when the OS is out of controll(for
> example: dead loop). When we use crash to analyze the vmcore, bt can
> not work, because there is no panic task.
>
> We have provide the value of register in the vmcore(the format is elf_prstatus,
> it is same with normal kdump's vmcore). So I write the code to use the register
> from notes in the vmcore when we do not find panic task. So we should know
> these offsets. We can check it where we use, but I think it's better to check
> and init it in x86_64_init().

Interesting -- so you essentially have an alternative dumping method
whose format simulates a kdump.

> >
> > Did you actually have a situation where a backtrace failed
> > without it -- but then worked OK with your patch?
> >
> > And was there a reason you used "unsigned long long" declarations?
> > I understand they are the same, but the kernel uses "unsigned long".
> > Why the difference?
>
> Does this case exist: we build crash on x86 box and use it to analyze the
> vmcore which is generate in x86_64 box? If it does not exist, I think
> we should use "unsigend long", the same with the kernel.

No, that cannot be done. You can build an x86 binary on an x86_64 machine
with "make target=X86", but not the other way around.

I'll revert them to "unsigned long" declarations, and queue the patch
for crash-5.1.3.

Thanks,
Dave

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility

debuginfo does not pick user_regs_struct on x86_64
 

At 03/02/2011 09:59 PM, Dave Anderson Write:
>
>
> ----- Original Message -----
>>>
>>> Right -- over the years it has been "found" in some kernel
>>> version's debuginfo data, but certainly not in all kernel
>>> versions. (mostly not)
>>>
>>> But anyway, its potential non-existence has been worked
>>> around such that the offset_table entries are not required.
>>>
>>> I did test it out on ~150 sample dumpfiles, and while it doesn't
>>> break anything, it doesn't help either -- the "bt -a" output is
>>> identical with or without the patch.
>>
>> The command "bt -a" can work fine without the patch now, because we
>> have checked it in get_netdump_regs_x86_64().
>>
>> We have a new hardware to do dump, and use makedumpfile to generate
>> vmcore. Our hardware can work when the OS is out of controll(for
>> example: dead loop). When we use crash to analyze the vmcore, bt can
>> not work, because there is no panic task.
>>
>> We have provide the value of register in the vmcore(the format is elf_prstatus,
>> it is same with normal kdump's vmcore). So I write the code to use the register
>> from notes in the vmcore when we do not find panic task. So we should know
>> these offsets. We can check it where we use, but I think it's better to check
>> and init it in x86_64_init().
>
> Interesting -- so you essentially have an alternative dumping method
> whose format simulates a kdump.
>
>>>
>>> Did you actually have a situation where a backtrace failed
>>> without it -- but then worked OK with your patch?
>>>
>>> And was there a reason you used "unsigned long long" declarations?
>>> I understand they are the same, but the kernel uses "unsigned long".
>>> Why the difference?
>>
>> Does this case exist: we build crash on x86 box and use it to analyze the
>> vmcore which is generate in x86_64 box? If it does not exist, I think
>> we should use "unsigend long", the same with the kernel.
>
> No, that cannot be done. You can build an x86 binary on an x86_64 machine
> with "make target=X86", but not the other way around.
>
> I'll revert them to "unsigned long" declarations, and queue the patch
> for crash-5.1.3.

Thanks.

>
> Thanks,
> Dave
>

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility