Re: [Crash-utility] 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(a)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