public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* Unwinding past main
@ 2004-11-02 23:29 Randolph Chung
  2004-11-02 23:33 ` Randolph Chung
  2004-11-03  0:14 ` Joel Brobecker
  0 siblings, 2 replies; 4+ messages in thread
From: Randolph Chung @ 2004-11-02 23:29 UTC (permalink / raw)
  To: gdb

I'm seeing a stack unwinding problem on hppa. Seems like this should be
applicable to other targets too -- how do you solve this problem?

Take a simple test program:
====
int foo(void) { return 1; }
int main(void) { return foo(); }
====

gcc does some tail call optimizations on this (when compiled with -O2),
so that the generated code looks like:

00010518 <foo>:
   10518:       e8 40 c0 00     bv r0(rp)
   1051c:       34 1c 00 02     ldi 1,ret0

00010520 <main>:
   10520:       6b c2 3f d9     stw rp,-14(,sp)
   10524:       37 de 00 80     ldo 40(sp),sp
   10528:       4b c2 3f 59     ldw -54(,sp),rp
   1052c:       e8 1f 1f cd     b,l 10518 <foo>,r0
   10530:       37 de 3f 81     ldo -40(sp),sp
   10534:       08 00 02 40     nop

doing a backtrace from foo results in an infinite loop :) I see some
code in gcc that tries to determine when we are in the main() function,
and stops the backtrace. But here, foo() returns directly to the caller
of main() (__libc_start_main on a glibc system), so we try to continue
to unwind through glibc and hit some asm bits that cannot be unwound
properly.

what is the "proper" way to handle this?

thanks,
randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

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

* Re: Unwinding past main
  2004-11-02 23:29 Unwinding past main Randolph Chung
@ 2004-11-02 23:33 ` Randolph Chung
  2004-11-03  0:14 ` Joel Brobecker
  1 sibling, 0 replies; 4+ messages in thread
From: Randolph Chung @ 2004-11-02 23:33 UTC (permalink / raw)
  To: gdb

> doing a backtrace from foo results in an infinite loop :) I see some
> code in gcc that tries to determine when we are in the main() function,
          ^^^ should be "gdb"
> and stops the backtrace. But here, foo() returns directly to the caller

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

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

* Re: Unwinding past main
  2004-11-02 23:29 Unwinding past main Randolph Chung
  2004-11-02 23:33 ` Randolph Chung
@ 2004-11-03  0:14 ` Joel Brobecker
  2004-11-03  0:48   ` Randolph Chung
  1 sibling, 1 reply; 4+ messages in thread
From: Joel Brobecker @ 2004-11-03  0:14 UTC (permalink / raw)
  To: Randolph Chung; +Cc: gdb

> I'm seeing a stack unwinding problem on hppa. Seems like this should be
> applicable to other targets too -- how do you solve this problem?

Funny you would see that. I am just looking at the same sort of
problem, but on IA64. I have an infinite loop when unwinding the
call stack from a thread. I don't understand all the conditions
yet (I am completely new to IA64, and it's quite complex for me).

So you are right in saying that this can happen on other targets too.
In my case, the "main" is the NPTL thread start routine, and we try
to unwind past it. In some cases, we are lucky, because we end up
with 2 identical frames which cause an error, but in some others,
the frame base changes slightly from frame to frame and we loop...

-- 
Joel

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

* Re: Unwinding past main
  2004-11-03  0:14 ` Joel Brobecker
@ 2004-11-03  0:48   ` Randolph Chung
  0 siblings, 0 replies; 4+ messages in thread
From: Randolph Chung @ 2004-11-03  0:48 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb

> Funny you would see that. I am just looking at the same sort of
> problem, but on IA64. I have an infinite loop when unwinding the
> call stack from a thread. I don't understand all the conditions
> yet (I am completely new to IA64, and it's quite complex for me).

oh, it used to do this on hppa too... we unwind to the clone call and
then it gets all confused.

> So you are right in saying that this can happen on other targets too.
> In my case, the "main" is the NPTL thread start routine, and we try
> to unwind past it. In some cases, we are lucky, because we end up
> with 2 identical frames which cause an error, but in some others,
> the frame base changes slightly from frame to frame and we loop...

yup. that's what i see too in this case.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

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

end of thread, other threads:[~2004-11-03  0:48 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-02 23:29 Unwinding past main Randolph Chung
2004-11-02 23:33 ` Randolph Chung
2004-11-03  0:14 ` Joel Brobecker
2004-11-03  0:48   ` Randolph Chung

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).