* Unwinding stack past main() when it has another name @ 2005-06-15 12:46 Hamish Rodda 2005-06-15 14:16 ` Daniel Jacobowitz 0 siblings, 1 reply; 12+ messages in thread From: Hamish Rodda @ 2005-06-15 12:46 UTC (permalink / raw) To: gdb [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-15 12:46 Unwinding stack past main() when it has another name Hamish Rodda @ 2005-06-15 14:16 ` Daniel Jacobowitz 2005-06-15 15:14 ` Hamish Rodda 0 siblings, 1 reply; 12+ messages in thread From: Daniel Jacobowitz @ 2005-06-15 14:16 UTC (permalink / raw) To: Hamish Rodda; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-15 14:16 ` Daniel Jacobowitz @ 2005-06-15 15:14 ` Hamish Rodda 2005-06-15 16:37 ` Daniel Jacobowitz 0 siblings, 1 reply; 12+ messages in thread From: Hamish Rodda @ 2005-06-15 15:14 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-15 15:14 ` Hamish Rodda @ 2005-06-15 16:37 ` Daniel Jacobowitz 2005-06-16 7:42 ` Hamish Rodda 0 siblings, 1 reply; 12+ messages in thread From: Daniel Jacobowitz @ 2005-06-15 16:37 UTC (permalink / raw) To: Hamish Rodda; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-15 16:37 ` Daniel Jacobowitz @ 2005-06-16 7:42 ` Hamish Rodda 2005-06-16 13:23 ` Daniel Jacobowitz 0 siblings, 1 reply; 12+ messages in thread From: Hamish Rodda @ 2005-06-16 7:42 UTC (permalink / raw) To: gdb [-- 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 --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-16 7:42 ` Hamish Rodda @ 2005-06-16 13:23 ` Daniel Jacobowitz 2005-06-16 21:22 ` Steven Johnson 0 siblings, 1 reply; 12+ messages in thread From: Daniel Jacobowitz @ 2005-06-16 13:23 UTC (permalink / raw) To: Hamish Rodda; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-16 13:23 ` Daniel Jacobowitz @ 2005-06-16 21:22 ` Steven Johnson 2005-06-16 22:05 ` Daniel Jacobowitz 2005-06-16 23:36 ` Mark Kettenis 0 siblings, 2 replies; 12+ messages in thread From: Steven Johnson @ 2005-06-16 21:22 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-16 21:22 ` Steven Johnson @ 2005-06-16 22:05 ` Daniel Jacobowitz 2005-06-16 22:46 ` Steven Johnson 2005-06-17 11:21 ` Richard Earnshaw 2005-06-16 23:36 ` Mark Kettenis 1 sibling, 2 replies; 12+ messages in thread From: Daniel Jacobowitz @ 2005-06-16 22:05 UTC (permalink / raw) To: Steven Johnson; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-16 22:05 ` Daniel Jacobowitz @ 2005-06-16 22:46 ` Steven Johnson 2005-06-17 11:21 ` Richard Earnshaw 1 sibling, 0 replies; 12+ messages in thread From: Steven Johnson @ 2005-06-16 22:46 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-16 22:05 ` Daniel Jacobowitz 2005-06-16 22:46 ` Steven Johnson @ 2005-06-17 11:21 ` Richard Earnshaw 2005-06-18 13:13 ` Eli Zaretskii 1 sibling, 1 reply; 12+ messages in thread From: Richard Earnshaw @ 2005-06-17 11:21 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Steven Johnson, gdb 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-17 11:21 ` Richard Earnshaw @ 2005-06-18 13:13 ` Eli Zaretskii 0 siblings, 0 replies; 12+ messages in thread From: Eli Zaretskii @ 2005-06-18 13:13 UTC (permalink / raw) To: Richard Earnshaw; +Cc: drow, sjohnson, gdb > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Unwinding stack past main() when it has another name 2005-06-16 21:22 ` Steven Johnson 2005-06-16 22:05 ` Daniel Jacobowitz @ 2005-06-16 23:36 ` Mark Kettenis 1 sibling, 0 replies; 12+ messages in thread From: Mark Kettenis @ 2005-06-16 23:36 UTC (permalink / raw) To: sjohnson; +Cc: drow, gdb 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2005-06-18 13:13 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-06-15 12:46 Unwinding stack past main() when it has another name Hamish Rodda 2005-06-15 14:16 ` Daniel Jacobowitz 2005-06-15 15:14 ` Hamish Rodda 2005-06-15 16:37 ` Daniel Jacobowitz 2005-06-16 7:42 ` Hamish Rodda 2005-06-16 13:23 ` Daniel Jacobowitz 2005-06-16 21:22 ` Steven Johnson 2005-06-16 22:05 ` Daniel Jacobowitz 2005-06-16 22:46 ` Steven Johnson 2005-06-17 11:21 ` Richard Earnshaw 2005-06-18 13:13 ` Eli Zaretskii 2005-06-16 23:36 ` Mark Kettenis
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).