This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Unwinding stack past main() when it has another name
On Thu, Jun 16, 2005 at 05:42:56PM +1000, Hamish Rodda wrote:
> On Thu, 16 Jun 2005 02:36 am, Daniel Jacobowitz wrote:
> > On Thu, Jun 16, 2005 at 01:12:54AM +1000, Hamish Rodda wrote:
> > > Yep... here's a snippet:
> > >
> > > #21 0x00002aaaacab22fa in QApplication::exec () at
> > > kernel/qapplication.cpp:2522
> > > #22 0x00002aaaaabd0a84 in kdemain (argc=<value optimized out>,
> > > argv=0x7fffffbd8ce8) at /opt/kde4/src/kdebase/kate/app/kwritemain.cpp:696
> > > #23 0x00002aaaaf227d95 in __libc_start_main () from /lib/libc.so.6
> > > #24 0x00000000004007ea in _start () at ../sysdeps/x86_64/elf/start.S:113
> > >
> > > In gdb 6.3 on amd64, this trace would be follwed by approx 800 - 1000
> > > useless "frames".
> > >
> > > I don't exactly know why or how the kdemain() function works, but I know
> > > it has something to do with kdeinit... there's some comments in the
> > > source in the kde svn repository, under kdelibs/kinit/*
> >
> > Presumably main() tail called to kdemain. Does the backtrace stop OK
> > at _start? If so, is there really a problem?
>
> Yes, so no, there's not a problem with gdb cvs... the logic to detect the
> start must have changed from 6.3 though. So, as long as the logic stays the
> same that's fine, it was more out of curiosity.
The fact that we stop at _start is a feature, so hopefully you can rely
on that in the future.
For some non-C languages we get the name of the main function from
debug information, but for C it's always main() - even in your case,
it's still main(). The fact that your compiler has optimized main off
of the call stack is a bit unfortunate though.
--
Daniel Jacobowitz
CodeSourcery, LLC