Re: backtrace from random $fp $pc

[Andrew Cagney <ac131313 at cygnus dot com>]

Love wrote:
> 
> In a project I'm writing on we have a custom thread package. It
> context-switches on select and do stack mangling when.
> 
> Now there is to way to do backtrace:ing on diffrent threads.
> 
> I have a patch (on 4.18) that enable us to do that
> <http://www.stacken.kth.se/projekt/arla/gdb-4.18-backfrom.diff> by
> choosning the right $fp and $sp. Se below for example (the exemple uses
> wrong $pc). As you see I use a sequence to find fp/pc.

The thing to do is study how one of the *thread* modules have been
implemented.  If you can teach GDB how to find the per thread
information then it can automatically handle the threads.

> Now that question is, how should thread support really work for random
> thread-packages ? We have the idea that the thread package would provide a
> magic variable to a function that gdb sets and the thead package call each
> time it does a thread-releated operation that gdb needs to know.

At present, GDB is largely passive.  It lets the target run.  When the
target stops GDB is told, among other things, ``hey this is a new
thread''.  GDB then typically lets the target run again.
(The thread experts can ROTFL at this description :-)

> A many related question: What is tfind, since that seam to be releated to
> backtrace:ing (but on remote targets ?) would that be possible to use for
> the same things that my patch does ?

Without reading the manual/source, I don't know.

For the backtrace command, in theory, it is possible to set ``$fp'' and
as a side effect change the stack that GDB is displaying.  ($fp is not
what the VAX hackers might think - it's a badly named gdb internal
variable that provides a handle onto the frame.  It may or may not
correspond to a real register).

	enjoy,
		Andrew

> 
> Love
> 
> (gdb) lwp_ps
> Runnable[0]
>  name: IO MANAGER
>   eventlist:
>   fp: 0x806aac4
>   pc: 0x806aac4
>  name: producer
>   eventlist: 8048b00
>   fp: 0x8083b40
>   pc: 0x8083b40
> Runnable[1]
> [...]
> (gdb) help backfrom
> Print backtrace of FRAMEPOINTER and PROGRAMCOUNTER.
> 
> (gdb) backfrom 0x8083b40 0x8083b40
> #0  0x8083b40 in ?? ()
> #1  0x8049e2f in LWP_MwaitProcess (wcount=1, evlist=0x8083b70)
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/lwp.c:567
> #2  0x8049eaf in LWP_WaitProcess (event=0x8048b00)
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/lwp.c:585
> #3  0x8048b12 in Producer (foo=0x0)
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/testlwp.c:76
> #4  0x804a00c in Create_Process_Part2 ()
>     at /afs/e.kth.se/home/staff/lha/src/cvs/arla-foo/lwp/lwp.c:629
> #5  0xfffefdfc in ?? ()
> #6  0x8051980 in ?? ()