----- Original Message -----
> 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, firstname.lastname@example.org 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"
> 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
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...
Crash-utility mailing list