Unwinding stack past main() when it has another name

Unwinding stack past main() when it has another name

[Hamish Rodda]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

Hi,

I'm just curious if there's a better solution for a problem I've come up 
against recently.  I have been using gdb 6.3 and finding that all of my kde 
program backtraces contain hundreds of irrelevant and corrupt-looking frames. 
Upgrading to cvs fixed most of the problem (the corrupt looking frames), but 
some frames still remain before the main function, which in kde programs is 
called kdemain().

Is there something the kde sources can do to have gdb recognise kdemain() as 
the replacement main() function, and thus prevent gdb from unwinding past it?

Thanks,
Hamish.

PS. please cc me on replies as I am not subscribed.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unwinding stack past main() when it has another name

[Daniel Jacobowitz]

On Wed, Jun 15, 2005 at 10:46:37PM +1000, Hamish Rodda wrote:
> Hi,
> 
> I'm just curious if there's a better solution for a problem I've come up 
> against recently.  I have been using gdb 6.3 and finding that all of my kde 
> program backtraces contain hundreds of irrelevant and corrupt-looking frames. 
> Upgrading to cvs fixed most of the problem (the corrupt looking frames), but 
> some frames still remain before the main function, which in kde programs is 
> called kdemain().
> 
> Is there something the kde sources can do to have gdb recognise kdemain() as 
> the replacement main() function, and thus prevent gdb from unwinding past it?

Is there really no main() on the backtrace?  There's no easy way in C
to mark another function as main or as not-backtraceable.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Unwinding stack past main() when it has another name

[Hamish Rodda]

[-- Attachment #1: Type: text/plain, Size: 1587 bytes --]

On Thu, 16 Jun 2005 12:16 am, Daniel Jacobowitz wrote:
> On Wed, Jun 15, 2005 at 10:46:37PM +1000, Hamish Rodda wrote:
> > Hi,
> >
> > I'm just curious if there's a better solution for a problem I've come up
> > against recently.  I have been using gdb 6.3 and finding that all of my
> > kde program backtraces contain hundreds of irrelevant and corrupt-looking
> > frames. Upgrading to cvs fixed most of the problem (the corrupt looking
> > frames), but some frames still remain before the main function, which in
> > kde programs is called kdemain().
> >
> > Is there something the kde sources can do to have gdb recognise kdemain()
> > as the replacement main() function, and thus prevent gdb from unwinding
> > past it?
>
> Is there really no main() on the backtrace?  There's no easy way in C
> to mark another function as main or as not-backtraceable.

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/*

Cheers,
Hamish.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unwinding stack past main() when it has another name

[Daniel Jacobowitz]

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?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Unwinding stack past main() when it has another name

[Hamish Rodda]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

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.

Thanks,
Hamish.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Unwinding stack past main() when it has another name

[Daniel Jacobowitz]

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

Re: Unwinding stack past main() when it has another name

[Steven Johnson]

Daniel Jacobowitz wrote:

>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()
>  
>
This isnt always the case for embedded targets.  There is no RULE that C 
programs must have a main() function.  It may be that most do by 
convention, but they dont have to.  In fact, main() can be a pain for 
small embedded targets because it wants a return value and arguments, 
which mean nothing for a program that isnt "launched" by a user on 
demand, but the C compiler detects the special function name main() and 
objects if it doesnt have the standard format.  Programs dont even need 
to have an entry point called _start.  It all depends on how you set up 
your link map.

Steven Johnson

Re: Unwinding stack past main() when it has another name

[Daniel Jacobowitz]

On Fri, Jun 17, 2005 at 08:22:13AM -1100, Steven Johnson wrote:
> Daniel Jacobowitz wrote:
> 
> >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()
> > 
> >
> This isnt always the case for embedded targets.  There is no RULE that C 
> programs must have a main() function.  It may be that most do by 
> convention, but they dont have to.  In fact, main() can be a pain for 
> small embedded targets because it wants a return value and arguments, 
> which mean nothing for a program that isnt "launched" by a user on 
> demand, but the C compiler detects the special function name main() and 
> objects if it doesnt have the standard format.  Programs dont even need 
> to have an entry point called _start.  It all depends on how you set up 
> your link map.

In fact you're wrong: there is a rule that C programs must have a
main() function.  It's in the language standard.

The fact that many embedded toolchains allow you to do things
differently is outside the boundaries of the language standard, and if
you don't have a main() your backtraces will stop at your entry point,
determined from the ELF file.  GDB'll do the best it can.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Unwinding stack past main() when it has another name

[Steven Johnson]

Daniel Jacobowitz wrote:

>On Fri, Jun 17, 2005 at 08:22:13AM -1100, Steven Johnson wrote:
>  
>
>>Daniel Jacobowitz wrote:
>>
>>    
>>
>>>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()
>>>
>>>
>>>      
>>>
>>This isnt always the case for embedded targets.  There is no RULE that C 
>>programs must have a main() function.  It may be that most do by 
>>convention, but they dont have to.  In fact, main() can be a pain for 
>>small embedded targets because it wants a return value and arguments, 
>>which mean nothing for a program that isnt "launched" by a user on 
>>demand, but the C compiler detects the special function name main() and 
>>objects if it doesnt have the standard format.  Programs dont even need 
>>to have an entry point called _start.  It all depends on how you set up 
>>your link map.
>>    
>>
>
>In fact you're wrong: there is a rule that C programs must have a
>main() function.  It's in the language standard.
>  
>
I stand corrected.  It is in fact in the standard as you say.  I have 
just been so exposed to code (written by many people) where the first C 
function that runs isnt called "main" it seemed to be a convention 
rather than a rule.  But as you say, many tool chains, gcc included 
allow for a program to not have a "main" function if you get in and 
modify the startup code and link map, which you often do for embedded 
targets, and doing so is not "standard" C.

>The fact that many embedded toolchains allow you to do things
>differently is outside the boundaries of the language standard, and if
>you don't have a main() your backtraces will stop at your entry point,
>determined from the ELF file.  GDB'll do the best it can.
>
>  
>
I wasnt suggesting GDB was broken in this regard, I was simply pointing 
out that not all (what Ive always considered to be) "C" programs have a 
main() function.

Steven

Re: Unwinding stack past main() when it has another name

[Mark Kettenis]

   Date: Fri, 17 Jun 2005 08:22:13 -1100
   From: Steven Johnson <sjohnson@sakuraindustries.com>

   Daniel Jacobowitz wrote:

   >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()
   >  
   >
   This isnt always the case for embedded targets.  There is no RULE that C 
   programs must have a main() function.

Oh there is.  But of course you don't have to play by that rule.  But
if you don't play by that rule you're very likely want to see the
complete backtrace up to the entry point of your program anyway.

Mark

Re: Unwinding stack past main() when it has another name

[Richard Earnshaw]

On Thu, 2005-06-16 at 23:05, Daniel Jacobowitz wrote:
> On Fri, Jun 17, 2005 at 08:22:13AM -1100, Steven Johnson wrote:
> > Daniel Jacobowitz wrote:
> > >For some non-C languages we get the name of the main function from
> > >debug information, but for C it's always main()
> > > 
> > >
> > This isnt always the case for embedded targets.  There is no RULE that C 
> > programs must have a main() function.  It may be that most do by 
> > convention, but they dont have to.  In fact, main() can be a pain for 
> > small embedded targets because it wants a return value and arguments, 
> > which mean nothing for a program that isnt "launched" by a user on 
> > demand, but the C compiler detects the special function name main() and 
> > objects if it doesnt have the standard format.  Programs dont even need 
> > to have an entry point called _start.  It all depends on how you set up 
> > your link map.
> 
> In fact you're wrong: there is a rule that C programs must have a
> main() function.  It's in the language standard.

You are both right, and both wrong.  In fact the standard says that two
things are permitted.

In a hosted environment the entry point to the application shall be
'main'.  In a free-standing environment there is no constraint on the
entry point -- there may even be multiple entry points.

R.

Re: Unwinding stack past main() when it has another name

[Eli Zaretskii]

> From: Richard Earnshaw <rearnsha@gcc.gnu.org>
> Cc: Steven Johnson <sjohnson@sakuraindustries.com>, gdb@sources.redhat.com
> Date: Fri, 17 Jun 2005 12:20:41 +0100
> 
> > > This isnt always the case for embedded targets.  There is no RULE that C 
> > > programs must have a main() function.  It may be that most do by 
> > > convention, but they dont have to.  In fact, main() can be a pain for 
> > > small embedded targets because it wants a return value and arguments, 
> > > which mean nothing for a program that isnt "launched" by a user on 
> > > demand, but the C compiler detects the special function name main() and 
> > > objects if it doesnt have the standard format.  Programs dont even need 
> > > to have an entry point called _start.  It all depends on how you set up 
> > > your link map.
> > 
> > In fact you're wrong: there is a rule that C programs must have a
> > main() function.  It's in the language standard.
> 
> You are both right, and both wrong.  In fact the standard says that two
> things are permitted.
> 
> In a hosted environment the entry point to the application shall be
> 'main'.  In a free-standing environment there is no constraint on the
> entry point -- there may even be multiple entry points.

I added a footnote in the manual about this.