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 06-28-2012, 05:38 PM
Anthony Booker
 
Default Crash-utility Digest, Vol 81, Issue 20

Dave,

Thanks for the reply, please excuse the rough formatting, I'll turn the
digest off so future exchanges will be better attributed.

On 06/28/2012 09:00 AM, crash-utility-request@redhat.com wrote:
> What you see is what you get.
>
> It's a somewhat painful process, where each item in the gdb-<version>.patch
> file contains something that needs to be addressed to maintain backwards
> compatibility. Each time I do it, I just walk through each patch in that
> file, and either it applies directly, or it involves some amount of pain,
> given the complexity of gdb.

I can appreciate that it's not an easy task, in my limited experience
with the source for gdb it seems "venerable and eccentric" which must
make rebasing a challenge. From my point of view that challenge is
increased because I don't immediately have a grasp on the purpose of the
patch and therefore how to react to failures to apply some changes. For
instance the version I'm looking at would seem to be a snapshot of
approximate 7.4.0 heritage, which has done away with some of the patch
sites, like rltypedefs.h and cli-cmds.c. The former seems, to me, to be
something I can ignore for now; readline makes things nicer to use but
isn't vital. However cli-cmds seems more fundamental to basic
functionality. All of which is just to say that experience has taught
me that before I dive in and try to understand the mating of two
unfamiliar components, it's worth asking if anyone has a guide book handy.

> But the short answer is, why?

Because the kernel I'm working with, while sharing a lot of the current
x86_64 architecture, doesn't identify itself as such. I've been given
access to gdb that's been hacked on to support userspace debug, but I
want to play with the kernel. I can't immediately share the source I
have, but since it's for internal development only I think my only
problem is I get to update crash. So we can continue to use it until we
can pass on what's useful to whoever's interested in it.

I'm also working on the opposite end, to see if I can get information on
the changes made to gdb and determine whether I can backport that into
7.3.1 which, if my understanding is correct, will also allow me to rig
crash for my use until the official gdb support gets out.

> Dave


--
Crash-utility mailing list
Crash-utility@redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
 
Old 06-28-2012, 06:09 PM
Dave Anderson
 
Default Crash-utility Digest, Vol 81, Issue 20

----- Original Message -----
> Dave,
>
> Thanks for the reply, please excuse the rough formatting, I'll turn the
> digest off so future exchanges will be better attributed.
>
> On 06/28/2012 09:00 AM, crash-utility-request@redhat.com wrote:
> > What you see is what you get.
> >
> > It's a somewhat painful process, where each item in the gdb-<version>.patch
> > file contains something that needs to be addressed to maintain backwards
> > compatibility. Each time I do it, I just walk through each patch in that
> > file, and either it applies directly, or it involves some amount of pain,
> > given the complexity of gdb.
>
> I can appreciate that it's not an easy task, in my limited experience
> with the source for gdb it seems "venerable and eccentric" which must
> make rebasing a challenge. From my point of view that challenge is
> increased because I don't immediately have a grasp on the purpose of the
> patch and therefore how to react to failures to apply some changes. For
> instance the version I'm looking at would seem to be a snapshot of
> approximate 7.4.0 heritage, which has done away with some of the patch
> sites, like rltypedefs.h and cli-cmds.c. The former seems, to me, to be
> something I can ignore for now; readline makes things nicer to use but
> isn't vital. However cli-cmds seems more fundamental to basic
> functionality. All of which is just to say that experience has taught
> me that before I dive in and try to understand the mating of two
> unfamiliar components, it's worth asking if anyone has a guide book
> handy.

Yeah, but no...

The failures seen that required gdb upgrades were varied. For example,
the gdb-7.3.1 update was required when newer kernels starting being built
with gcc-4.6.1, which defaults to using -gdwarf-4, which wasn't supported
in the prior gdb version.

I should also mention that -- without fail -- everytime I update it,
something new comes up that causes a totally unexpected failure of
some sort, leading to yet more patches each time.

So anyway, unless there is a compelling reason, it won't be updated just
for the sake of updating it.

> > But the short answer is, why?
>
> Because the kernel I'm working with, while sharing a lot of the current
> x86_64 architecture, doesn't identify itself as such.

I'm not clear on what you mean by that -- the "kernel" doesn't identify itself
as x86_64, or is it the hardware that doesn't identify itself as x86_64, and
you're running a custom kernel on it?

> I've been given access to gdb that's been hacked on to support userspace debug,
> but I want to play with the kernel. I can't immediately share the source I
> have, but since it's for internal development only I think my only
> problem is I get to update crash. So we can continue to use it until we
> can pass on what's useful to whoever's interested in it.
>
> I'm also working on the opposite end, to see if I can get information on
> the changes made to gdb and determine whether I can backport that into
> 7.3.1 which, if my understanding is correct, will also allow me to rig
> crash for my use until the official gdb support gets out.

Well, good luck with that...

Dave

--
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 02:52 AM.

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