next/step after main() function's return

next/step after main() function's return

[Edjunior Barbosa Machado]

Hello,

when issuing a next or step after main() function's return statement, gdb drops to __libc_start_main() from libc on x86 (or generic_start_main() on ppc and so on, depending on the arch if I'm not mistaken). Is it considered a bug or it's just the expected behavior?

Thanks,
-- 
Edjunior

Re: next/step after main() function's return

[Joel Brobecker]

> when issuing a next or step after main() function's return statement,
> gdb drops to __libc_start_main() from libc on x86 (or
> generic_start_main() on ppc and so on, depending on the arch if I'm
> not mistaken). Is it considered a bug or it's just the expected
> behavior?

I'd say that this is expected behavior. `main' is called by
__libc_start_main, so "next"-ing out of main will land in that function.

-- 
Joel

Re: next/step after main() function's return

[Jan Kratochvil]

On Tue, 28 Dec 2010 06:20:55 +0100, Joel Brobecker wrote:
> > when issuing a next or step after main() function's return statement,
> > gdb drops to __libc_start_main() from libc on x86 (or
> > generic_start_main() on ppc and so on, depending on the arch if I'm
> > not mistaken). Is it considered a bug or it's just the expected
> > behavior?
> 
> I'd say that this is expected behavior. `main' is called by
> __libc_start_main, so "next"-ing out of main will land in that function.

With default `set backtrace past-main off' the user may expect it to behave
differently.  Still the atexit functions could be "next"ed so GDB would have
to identify somehow their calls.


Regards,
Jan

Re: next/step after main() function's return

[Michael Snyder]

Jan Kratochvil wrote:
> On Tue, 28 Dec 2010 06:20:55 +0100, Joel Brobecker wrote:
>>> when issuing a next or step after main() function's return statement,
>>> gdb drops to __libc_start_main() from libc on x86 (or
>>> generic_start_main() on ppc and so on, depending on the arch if I'm
>>> not mistaken). Is it considered a bug or it's just the expected
>>> behavior?
>> I'd say that this is expected behavior. `main' is called by
>> __libc_start_main, so "next"-ing out of main will land in that function.
> 
> With default `set backtrace past-main off' the user may expect it to behave
> differently.  Still the atexit functions could be "next"ed so GDB would have
> to identify somehow their calls.

I'm guessing this happens because libc_start_main is compiled with -g.

Otherwise, gdb would continue executing "in the woods" until exit.

Re: next/step after main() function's return

[Joel Brobecker]

> I'm guessing this happens because libc_start_main is compiled with -g.
> Otherwise, gdb would continue executing "in the woods" until exit.

Actually, off-by-one error :-). __libc_start_main is not compiled with
debugging info, but main is.  When you do a "next" in main, GDB takes
the debugging info, and computes the address range that we need to
step out of.  So, when main returns back to __libc_start_main, we're
done, and tell the user where we are.  What you are describing, however,
happens once we land inside __libc_start_main, since there is no line
info to help us compute the next/step range.

-- 
Joel

Re: next/step after main() function's return

[Jan Kratochvil]

On Wed, 29 Dec 2010 03:26:09 +0100, Joel Brobecker wrote:
> > I'm guessing this happens because libc_start_main is compiled with -g.
> > Otherwise, gdb would continue executing "in the woods" until exit.
> 
> Actually, off-by-one error :-). __libc_start_main is not compiled with
> debugging info,

It can be, depending on the OS:

7	  return 0;
(gdb) next
8	}
(gdb) next
__libc_start_main (main=0x4004c4 <main>, argc=1, ubp_av=0x7fffffffdf08, init=<value optimized out>, fini=<value optimized out>, rtld_fini=<value optimized out>, stack_end=0x7fffffffdef8) at libc-start.c:258
258	  exit (result);
(gdb) list
253	#else
254	  /* Nothing fancy, just call the function.  */
255	  result = main (argc, argv, __environ MAIN_AUXVEC_PARAM);
256	#endif
257	
258	  exit (result);
259	}
(gdb) info source
Current source file is libc-start.c
Compilation directory is /usr/src/debug/glibc-2.12-232-gdbb0472/csu
Located in /usr/src/debug/glibc-2.12-232-gdbb0472/csu/libc-start.c
Contains 259 lines.
Source language is c.
Compiled with DWARF 2 debugging format.
Does not include preprocessor macro info.
(gdb) _

fedora-release-14-1.noarch
glibc-debuginfo-2.12.90-21.x86_64


Regards,
Jan

Re: next/step after main() function's return

[Joel Brobecker]

> It can be, depending on the OS:
[...]
> fedora-release-14-1.noarch
> glibc-debuginfo-2.12.90-21.x86_64

Indeed! Does glic come with debug info by default on Fedora?

-- 
Joel

Re: next/step after main() function's return

[Jan Kratochvil]

On Wed, 29 Dec 2010 03:49:40 +0100, Joel Brobecker wrote:
> > It can be, depending on the OS:
> [...]
> > fedora-release-14-1.noarch
> > glibc-debuginfo-2.12.90-21.x86_64
> 
> Indeed! Does glic come with debug info by default on Fedora?

Not in a default installation but `debuginfo-install glibc' will provide it.
In fact `debuginfo-install any package' will always provide also glibc due to
the obvious package dependencies.

Also in Fedora GDB there is a rpm-specific patch
	http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=blob_plain;f=gdb-6.6-buildid-locate-rpm.patch;hb=master
on top of
	[patch 1/2] build id
	http://sourceware.org/ml/gdb-patches/2010-11/msg00353.html
providing a suggestion:
	gdb-7.2-26.fc14.x86_64
	$ echo 'main(){}' | gcc -x c -; gdb -q ./a.out -ex start
	Temporary breakpoint 1, 0x0000000000400478 in main ()
	Missing separate debuginfos, use: debuginfo-install glibc-2.12.90-21.x86_64
	(gdb) _
and therefore I guess users may have it commonly installed.


Thanks,
Jan

Re: next/step after main() function's return

[Michael Snyder]

Joel Brobecker wrote:
>> I'm guessing this happens because libc_start_main is compiled with -g.
>> Otherwise, gdb would continue executing "in the woods" until exit.
> 
> Actually, off-by-one error :-). __libc_start_main is not compiled with
> debugging info, but main is.  When you do a "next" in main, GDB takes
> the debugging info, and computes the address range that we need to
> step out of.  So, when main returns back to __libc_start_main, we're
> done, and tell the user where we are.  What you are describing, however,
> happens once we land inside __libc_start_main, since there is no line
> info to help us compute the next/step range.
> 

Hmm, yes, and that's when I would expect us to keep stepping, looking
for a line range, until eventually we exit.

Re: next/step after main() function's return

[Michael Snyder]

Edjunior Barbosa Machado wrote:
> Hello,
> 
> when issuing a next or step after main() function's return statement, gdb drops to __libc_start_main() from libc on x86 (or generic_start_main() on ppc and so on, depending on the arch if I'm not mistaken). Is it considered a bug or it's just the expected behavior?


Does the "ending-run.exp" test case pass or fail on this system?

Re: next/step after main() function's return

[Edjunior Barbosa Machado]

On 12/28/2010 09:05 PM, Michael Snyder wrote:
> Does the "ending-run.exp" test case pass or fail on this system?
>

I had the same results from gdb upstream on both systems (i686 running Debian squeeze/sid and ppc64 running RHEL5.4):

# of expected passes		19
# of unsupported tests		1

with UNSUPPORTED: gdb.base/ending-run.exp: continue after exit

Thanks,
-- 
Edjunior