Hi, One difficulty is that user's data may be swaped out. Thanks Itsuro Oda On Thu, 4 Dec 2008 16:13:11 -0500 (EST) Dave Anderson <anderson@xxxxxxxxxx> wrote: > > ----- "James Bradshaw" <jbradsha@xxxxxxxxxxxxx> wrote: > > > Right. To be able to examine user space, you'd have to build an elf > > core file by processing the desired task structure in the kdump file, > > find all the user pages, etc.--essentially what elf_core_dump() does > > in a running kernel. Then you could use gdb offline or the embedded > > gdb. > > Yep, that would be pretty cool... "gdb offline" that is. > > I still don't think it makes sense to do anything on the user core > file from the embedded gdb, given it's been wired/hacked to work solely > as a crash utility slave. > > I envision a command that would work something like, for example, > for PID 24677: > > crash> core 24677 > core.24677 created > crash> > > where 24677 is the PID. As a template for gathering the core data, > the "vm -p" command shows you where all of the user pages are, and > the "bt" kernel entry point gives you the "last-known" register set. > Seems like it could work... > > > I understand your desire not to burden crash with user space stuff, > > although the extensions facility seems to provide a mechanism for > > cleanly excluding such functionality from the standard configuration. > > Just a thought. > > Absolutely -- that's precisely what it's there for. > > But for that matter, after it's working nicely as an extension, > and if it can be cleanly, reliably and maintainably (word?) moved > into the base sources, I'm all for it. > > Thanks, > Dave > > -- > Crash-utility mailing list > Crash-utility@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/crash-utility -- Itsuro ODA <oda@xxxxxxxxxxxxx> -- Crash-utility mailing list Crash-utility@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/crash-utility
