[Crash-utility] Crash-utility Digest, Vol 81, Issue 20

[Dave Anderson]

----- 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 at 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