FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Crash Utility

 
 
LinkBack Thread Tools
 
Old 01-01-1970, 01:00 AM
HATAYAMA Daisuke
 
Default libgco fix get notesize calculation

Hello Lei,

Sorry for very late response.

I'm now reviewing your patches.

From: Lei Wen <leiwen@marvell.com>
Subject: [PATCH 1/2] libgcore: fix get notesize calculation
Date: Sat, 11 Feb 2012 22:44:14 -0800

> The logic in the kernel is if regset get method return not zero value,
> which means error in that case, then it should skip this notesize calculation.
> Align this logic in the libgcore with kernel.
>
> Signed-off-by: Lei Wen <leiwen@marvell.com>
> ---
> extensions/libgcore/gcore_coredump.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/extensions/libgcore/gcore_coredump.c b/extensions/libgcore/gcore_coredump.c
> index 8a8855d..e2d9941 100644
> --- a/extensions/libgcore/gcore_coredump.c
> +++ b/extensions/libgcore/gcore_coredump.c
> @@ -454,7 +454,7 @@ fill_thread_core_info(struct elf_thread_core_info *t,
> !regset->active(task_to_context(t->task), regset))
> continue;
> data = (void *)GETBUF(regset->size);
> - if (!regset->get(task_to_context(t->task), regset, regset->size,
> + if (regset->get(task_to_context(t->task), regset, regset->size,
> data))
> continue;
> if (regset->callback)
> --
> 1.7.5.4
>

I borrowed most of logic in gcore from kernel source code for ease of
development and for ease of porting each architecture's implementation
following regset interface.

The interface for get method in gcore command is different from
kernel's. Originally, it returns 0 in a successfull case, and
otherwise returns non-zero values. But in gcore, such get method
returns TRUE in a successfull case, and otherwise FALSE.

I cannot recall why I made this change at that time precisely. But OK,
I'll revert it into the original one. Based on the original motivation
of why I adapted regset interface, it's better to keep it original.

BTW, looking at your 2nd patch, fpa_get() and vfp_get() bahaves
differently w.r.t. the above mentioned one: fpa_get() returns 0 in a
sucessfull case, but vfp_get() TRUE.

Is it OK that I'll modify vfp_get() so that it returns 0 in a
successfull state?

Furthermore, these days I'm beginning with the current design of gcore
command is too large to maintain. I guess most users of this command
requires only a small part of the features currently gcore command
provides. In other words, they are satisfied only with seeing memory
contents and backtrace using gdb. They don't need acurate restoration
of register values. For the other direction, porting kernel source
code directly, such as elf_core_dump() and regset interface, itself
might be too large. I will perhaps rewrite gcore command entirely
compactly. Please keep it mind.

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 01-01-1970, 01:00 AM
HATAYAMA Daisuke
 
Default libgco fix get notesize calculation

From: Lei Wen <leiwen@marvell.com>
Subject: RE: [PATCH 1/2] libgcore: fix get notesize calculation
Date: Wed, 14 Mar 2012 01:46:13 -0700

> Hi HATAYAMA,
>
>> -----Original Message-----
>> From: HATAYAMA Daisuke [mailto:d.hatayama@jp.fujitsu.com]
>> Sent: Wednesday, March 14, 2012 10:45 AM
>> To: Lei Wen
>> Cc: crash-utility@redhat.com
>> Subject: Re: [PATCH 1/2] libgcore: fix get notesize calculation
>>

>>
>> From: Lei Wen <leiwen@marvell.com>
>> Subject: [PATCH 1/2] libgcore: fix get notesize calculation
>> Date: Sat, 11 Feb 2012 22:44:14 -0800
>>

>
> Opps, that is my fault, thanks for correcting.
> I'm ok with the change.
>

I see.

>>
>> Furthermore, these days I'm beginning with the current design of gcore
>> command is too large to maintain. I guess most users of this command
>> requires only a small part of the features currently gcore command
>> provides. In other words, they are satisfied only with seeing memory
>> contents and backtrace using gdb. They don't need acurate restoration
>> of register values. For the other direction, porting kernel source
>> code directly, such as elf_core_dump() and regset interface, itself
>> might be too large. I will perhaps rewrite gcore command entirely
>> compactly. Please keep it mind.
>
> Actually we think it is vital to also keep the register set extract out to analyze the user space application, since combining the registers and assembler code, we could get full view of what is happening when the fatal signal happens, like what the local variable content is then. Just backtrace is not enough...
>
> Could we keep such feature?
>

Yes, I also think there's such requirement. What I want to keep now
are memory part, general registers that are corresponding to
REGSET_GENERAL and core part of NT_PRSTATUS, NT_PRPSINFO and NT_AUXV.

I don't schedule this development and I don't know when I will do
it. So please just keep it mind.

Thanks.
HATAYAMA, Daisuke

--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 03-14-2012, 07:46 AM
Lei Wen
 
Default libgco fix get notesize calculation

Hi HATAYAMA,

> -----Original Message-----
> From: HATAYAMA Daisuke [mailto:d.hatayama@jp.fujitsu.com]
> Sent: Wednesday, March 14, 2012 10:45 AM
> To: Lei Wen
> Cc: crash-utility@redhat.com
> Subject: Re: [PATCH 1/2] libgcore: fix get notesize calculation
>
> Hello Lei,
>
> Sorry for very late response.
>
> I'm now reviewing your patches.

Thanks for reviewing!

>
> From: Lei Wen <leiwen@marvell.com>
> Subject: [PATCH 1/2] libgcore: fix get notesize calculation
> Date: Sat, 11 Feb 2012 22:44:14 -0800
>
> > The logic in the kernel is if regset get method return not zero value,
> > which means error in that case, then it should skip this notesize calculation.
> > Align this logic in the libgcore with kernel.
> >
> > Signed-off-by: Lei Wen <leiwen@marvell.com>
> > ---
> > extensions/libgcore/gcore_coredump.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/extensions/libgcore/gcore_coredump.c
> b/extensions/libgcore/gcore_coredump.c
> > index 8a8855d..e2d9941 100644
> > --- a/extensions/libgcore/gcore_coredump.c
> > +++ b/extensions/libgcore/gcore_coredump.c
> > @@ -454,7 +454,7 @@ fill_thread_core_info(struct elf_thread_core_info *t,
> > !regset->active(task_to_context(t->task), regset))
> > continue;
> > data = (void *)GETBUF(regset->size);
> > - if (!regset->get(task_to_context(t->task), regset, regset->size,
> > + if (regset->get(task_to_context(t->task), regset, regset->size,
> > data))
> > continue;
> > if (regset->callback)
> > --
> > 1.7.5.4
> >
>
> I borrowed most of logic in gcore from kernel source code for ease of
> development and for ease of porting each architecture's implementation
> following regset interface.
>
> The interface for get method in gcore command is different from
> kernel's. Originally, it returns 0 in a successfull case, and
> otherwise returns non-zero values. But in gcore, such get method
> returns TRUE in a successfull case, and otherwise FALSE.
>
> I cannot recall why I made this change at that time precisely. But OK,
> I'll revert it into the original one. Based on the original motivation
> of why I adapted regset interface, it's better to keep it original.
>
> BTW, looking at your 2nd patch, fpa_get() and vfp_get() bahaves
> differently w.r.t. the above mentioned one: fpa_get() returns 0 in a
> sucessfull case, but vfp_get() TRUE.
>
> Is it OK that I'll modify vfp_get() so that it returns 0 in a
> successfull state?

Opps, that is my fault, thanks for correcting.
I'm ok with the change.

>
> Furthermore, these days I'm beginning with the current design of gcore
> command is too large to maintain. I guess most users of this command
> requires only a small part of the features currently gcore command
> provides. In other words, they are satisfied only with seeing memory
> contents and backtrace using gdb. They don't need acurate restoration
> of register values. For the other direction, porting kernel source
> code directly, such as elf_core_dump() and regset interface, itself
> might be too large. I will perhaps rewrite gcore command entirely
> compactly. Please keep it mind.

Actually we think it is vital to also keep the register set extract out to analyze the user space application, since combining the registers and assembler code, we could get full view of what is happening when the fatal signal happens, like what the local variable content is then. Just backtrace is not enough...

Could we keep such feature?

>
> Thanks.
> HATAYAMA, Daisuke

Thanks,
Lei

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

Thread Tools




All times are GMT. The time now is 10:09 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org