This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Fastboot] Re: Query: Kdump: Core Image ELF Format


Vivek Goyal <vgoyal@in.ibm.com> writes:

> On Tue, 2005-03-08 at 11:00 -0700, Eric W. Biederman wrote: 
> That sounds good. But we loose the advantage of doing limited debugging
> with gdb. Crash (or other analysis tools) will still take considerable
> amount of time before before they are fully ready and tested.
> 
> How about giving user the flexibility to choose. What I mean is
> introducing a command line option in kexec-tools to choose between ELF32
> and ELF64 headers. For the users who are not using PAE systems, they can
> very well go with ELF32 headers and do the debugging using gdb.
> 
> This also requires, setting the kernel virtual addresses while preparing
> the headers. KVA for linearly mapped region is known in advance and can
> be filled at header creation time and gdb can directly operate upon this
> region.

I have no problems decorating the ELF header you are generating
in user space with virtual addresses assuming we can reliably
get that information.  And before a kernel crashes looks like a reasonable
time to ask that question.  I don't currently see where you could
derive that information.

Beyond that I prefer a little command line tool that will do the
ELF64 to ELF32 conversion and possibly add in the kva mapping to
make the core dump usable with gdb.  Doing it in a separate tool
means it is the developer who is doing the analysis who cares
not the user who is capturing the system core dump.

But I do agree that it a use case worth solving.

Eric


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]