----- 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@xxxxxxxxxx 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility