`??` in stack trace below thread_startup

I am trying to understand what happens when a thread is scheduled again.

I have traced the execution at mips_threadstart which jumps to thread_startup. This is documented in switchframe_init function.

However, what happens when thread_startup finishes ? In gdb i see, ?? in stack trace at #2 below.

(gdb) bt

#0 loudthread (junk=junk@entry=0x0, num=num@entry=7) at …/…/test/threadtest.c:67

#1 0x8001a5ec in thread_startup (entrypoint=0x80018090 <loudthread>, data1=0x0, data2=7) at …/…/thread/thread.c:781

#2 0x00000000 in ?? ()

Backtrace stopped: frame did not save the PC


Also, i see some values are optimized out even in the debug build. Especially cur in thread_switch :

(gdb) n
thread_switch (newstate=newstate@entry=S_SLEEP, wc=wc@entry=0x8002fbe0, lk=lk@entry=0x8002fc08) at …/…/thread/thread.c:597
597 if (curcpu->c_isidle) {
603 thread_checkstack(cur);
606 spinlock_acquire(&curcpu->c_runqueue_lock);
609 if (newstate == S_READY && threadlist_isempty(&curcpu->c_runqueue)) {
616 switch (newstate) {
623 cur->t_wchan_name = wc->wc_name;
(gdb) l
618 panic(“Illegal S_RUN in thread_switch\n”);
619 case S_READY:
620 thread_make_runnable(cur, true /have lock/);
621 break;
622 case S_SLEEP:
623 cur->t_wchan_name = wc->wc_name;
624 /*
625 * Add the thread to the list in the wait channel, and
626 * unlock same. To avoid a race with someone else
627 * calling wchan_wake*, we must keep the wchan’s
(gdb) n
632 threadlist_addtail(&wc->wc_threads, cur);
(gdb) p cur
$64 = <optimized out>

Why is cur => optimized out ?