public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Backtrace from kernel to user space in coredump
@ 2010-06-12 13:06 Michael Eager
  2010-06-12 15:19 ` Frédéric RISS
  2010-06-14  7:23 ` Hui Zhu
  0 siblings, 2 replies; 5+ messages in thread
From: Michael Eager @ 2010-06-12 13:06 UTC (permalink / raw)
  To: gdb

Hi --

I want to be able to generate a backtrace in a
core dump from a uClinux kernel routine (say,
do_trap() or do_page_fault()) to the user-space
routine which caused the trap.  The kernel function
is called with a pt_regs struct which contains the
user regs.

One way I thought to do this is to set the $PC and
$SP to the value saved in pt_regs and do a "bt".
If I try to set the $PC, gdb complains that there
is no process, since there are no routines to modify
a core file.

I can modify gdb to save the registers returned from
reading the core file and add routines allow modifying
these saved register values.

Are there better ways to do this?   How have other
people handled traces back from kernel to user space?


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Backtrace from kernel to user space in coredump
  2010-06-12 13:06 Backtrace from kernel to user space in coredump Michael Eager
@ 2010-06-12 15:19 ` Frédéric RISS
  2010-06-12 16:16   ` Paul Koning
  2010-06-14  7:23 ` Hui Zhu
  1 sibling, 1 reply; 5+ messages in thread
From: Frédéric RISS @ 2010-06-12 15:19 UTC (permalink / raw)
  To: Michael Eager; +Cc: gdb

Le samedi 12 juin 2010 à 06:06 -0700, Michael Eager a écrit :
> Are there better ways to do this?   How have other
> people handled traces back from kernel to user space?

It's more heavyweight than just setting the registers, but it's quite
easy to add specific unwinders for syscalls, exceptions, interrupts...
And this works very nicely (well, the real difficulty is to have GDB
load the debug information for the appropriate userspace task, but
that's maybe not an issue in your case).

Fred


^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Backtrace from kernel to user space in coredump
  2010-06-12 15:19 ` Frédéric RISS
@ 2010-06-12 16:16   ` Paul Koning
  2010-06-14  3:18     ` Michael Eager
  0 siblings, 1 reply; 5+ messages in thread
From: Paul Koning @ 2010-06-12 16:16 UTC (permalink / raw)
  To: Frédéric RISS, Michael Eager; +Cc: gdb

I've done just what you describe for MIPS, by adding a bunch of code to the prologue analyzers.  The user space symbols are a bit of a hassle, not so much for the program itself (add-symbol-file is easy enough for that) but because of the shared libraries (if you have those -- in my case it was NetBSD so that did matter).

	paul

> -----Original Message-----
> From: gdb-owner@sourceware.org [mailto:gdb-owner@sourceware.org] On
> Behalf Of Frédéric RISS
> Sent: Saturday, June 12, 2010 11:19 AM
> To: Michael Eager
> Cc: gdb@sourceware.org
> Subject: Re: Backtrace from kernel to user space in coredump
> 
> Le samedi 12 juin 2010 à 06:06 -0700, Michael Eager a écrit :
> > Are there better ways to do this?   How have other
> > people handled traces back from kernel to user space?
> 
> It's more heavyweight than just setting the registers, but it's quite
> easy to add specific unwinders for syscalls, exceptions, interrupts...
> And this works very nicely (well, the real difficulty is to have GDB
> load the debug information for the appropriate userspace task, but
> that's maybe not an issue in your case).
> 
> Fred
> 


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Backtrace from kernel to user space in coredump
  2010-06-12 16:16   ` Paul Koning
@ 2010-06-14  3:18     ` Michael Eager
  0 siblings, 0 replies; 5+ messages in thread
From: Michael Eager @ 2010-06-14  3:18 UTC (permalink / raw)
  To: Paul Koning; +Cc: gdb

Paul Koning wrote:
> I've done just what you describe for MIPS, by adding a bunch of code to the
> prologue analyzers.  The user space symbols are a bit of a hassle, not so
> much for the program itself (add-symbol-file is easy enough for that) but
> because of the shared libraries (if you have those -- in my case it was
> NetBSD so that did matter).

Is this in the gdb repo or elsewhere?  I looked a the prologue
code for MIPS and it looks pretty vanilla.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Backtrace from kernel to user space in coredump
  2010-06-12 13:06 Backtrace from kernel to user space in coredump Michael Eager
  2010-06-12 15:19 ` Frédéric RISS
@ 2010-06-14  7:23 ` Hui Zhu
  1 sibling, 0 replies; 5+ messages in thread
From: Hui Zhu @ 2010-06-14  7:23 UTC (permalink / raw)
  To: Michael Eager; +Cc: gdb

http://sourceware.org/ml/gdb-patches/2010-02/msg00533.html

I make this patch for other thing.  It can save the memory and reg
operation command's value and send it to GDB as the inferior's value.
Then you can do backtrace.

I think maybe you can put the reg and sp memory 's value to GDB.  Then
you can do backtrace.

Thanks,
Hui

On Sat, Jun 12, 2010 at 21:06, Michael Eager <eager@eagerm.com> wrote:
> Hi --
>
> I want to be able to generate a backtrace in a
> core dump from a uClinux kernel routine (say,
> do_trap() or do_page_fault()) to the user-space
> routine which caused the trap.  The kernel function
> is called with a pt_regs struct which contains the
> user regs.
>
> One way I thought to do this is to set the $PC and
> $SP to the value saved in pt_regs and do a "bt".
> If I try to set the $PC, gdb complains that there
> is no process, since there are no routines to modify
> a core file.
>
> I can modify gdb to save the registers returned from
> reading the core file and add routines allow modifying
> these saved register values.
>
> Are there better ways to do this?   How have other
> people handled traces back from kernel to user space?
>
>
> --
> Michael Eager    eager@eagercon.com
> 1960 Park Blvd., Palo Alto, CA 94306  650-325-8077
>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-06-14  7:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-12 13:06 Backtrace from kernel to user space in coredump Michael Eager
2010-06-12 15:19 ` Frédéric RISS
2010-06-12 16:16   ` Paul Koning
2010-06-14  3:18     ` Michael Eager
2010-06-14  7:23 ` Hui Zhu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).