public inbox for gentoo-user@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-user] [~amd64] Confusing behavior from gdb
@ 2015-04-25 23:31 walt
  2015-04-25 23:42 ` covici
  0 siblings, 1 reply; 3+ messages in thread
From: walt @ 2015-04-25 23:31 UTC (permalink / raw
  To: gentoo-user

I'm ready to swear on a stack of Knuth volumes that gdb has lost its mind.

But, I'm willing to consider the remote possibility that I don't know how
to use gdb ;)   (Because I really don't.)

This is my annotated copy/paste from a single gdb session:

#gdb /bin/mount
GNU gdb (Gentoo 7.9 vanilla) 7.9

<GNU boilerplate snipped>

(gdb) start
Temporary breakpoint 1 at 0x403000: file /var/tmp/portage/sys-apps/util-linux-2.26.1-r1/work/util-linux-2.26.1/sys-utils/mount.c, line 789.
Starting program: /bin/mount 

Temporary breakpoint 1, main (argc=1, argv=0x7ffc3508e108)
    at /var/tmp/portage/sys-apps/util-linux-2.26.1-r1/work/util-linux-2.26.1/sys-utils/mount.c:789
789	{
(gdb) list mount.c:1020

<I picked line 1020 because I know from previous gdb sessions that it
 calls the print_all function, which is the one I really want to debug>

1015		    !mnt_context_get_target(cxt) &&
1016		    !argc &&
1017		    !all) {
1018			if (oper || mnt_context_get_options(cxt))
1019				usage(stderr);
1020			print_all(cxt, types, show_labels);
1021			goto done;
1022		}
1023	
1024		/* Non-root users are allowed to use -t to print_all(),



<I want to debug the function named print_all, so I set a breakpoint there>

(gdb) break print_all
Breakpoint 2 at 0x4037fd: file /var/tmp/portage/sys-apps/util-linux-2.26.1-r1/work/util-linux-2.26.1/sys-utils/mount.c, line 130.



<Okay, this is where gdb does something crazy.  Note that (see the line above)
 gdb set the breakpoint at mount.c:130, but in fact print_all is defined at
 mount.c:123, seven lines earlier>

(gdb) list mount.c:123
118			else
119				fputc(*p, stdout);
120		}
121	}
122	
123	static void print_all(struct libmnt_context *cxt, char *pattern, int show_label)
124	{
125		struct libmnt_table *tb;
126		struct libmnt_iter *itr = NULL;
127		struct libmnt_fs *fs;
(gdb) 


This seems to me to be very buggy behavior, but I'd like to get opinions from
people who really know gdb, which I don't.

And thanks for reading this far :)



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

* Re: [gentoo-user] [~amd64] Confusing behavior from gdb
  2015-04-25 23:31 [gentoo-user] [~amd64] Confusing behavior from gdb walt
@ 2015-04-25 23:42 ` covici
  2015-04-26  2:52   ` Fernando Rodriguez
  0 siblings, 1 reply; 3+ messages in thread
From: covici @ 2015-04-25 23:42 UTC (permalink / raw
  To: gentoo-user

walt <w41ter@gmail.com> wrote:

> I'm ready to swear on a stack of Knuth volumes that gdb has lost its mind.
> 
> But, I'm willing to consider the remote possibility that I don't know how
> to use gdb ;)   (Because I really don't.)
> 
> This is my annotated copy/paste from a single gdb session:
> 
> #gdb /bin/mount
> GNU gdb (Gentoo 7.9 vanilla) 7.9
> 
> <GNU boilerplate snipped>
> 
> (gdb) start
> Temporary breakpoint 1 at 0x403000: file /var/tmp/portage/sys-apps/util-linux-2.26.1-r1/work/util-linux-2.26.1/sys-utils/mount.c, line 789.
> Starting program: /bin/mount 
> 
> Temporary breakpoint 1, main (argc=1, argv=0x7ffc3508e108)
>     at /var/tmp/portage/sys-apps/util-linux-2.26.1-r1/work/util-linux-2.26.1/sys-utils/mount.c:789
> 789	{
> (gdb) list mount.c:1020
> 
> <I picked line 1020 because I know from previous gdb sessions that it
>  calls the print_all function, which is the one I really want to debug>
> 
> 1015		    !mnt_context_get_target(cxt) &&
> 1016		    !argc &&
> 1017		    !all) {
> 1018			if (oper || mnt_context_get_options(cxt))
> 1019				usage(stderr);
> 1020			print_all(cxt, types, show_labels);
> 1021			goto done;
> 1022		}
> 1023	
> 1024		/* Non-root users are allowed to use -t to print_all(),
> 
> 
> 
> <I want to debug the function named print_all, so I set a breakpoint there>
> 
> (gdb) break print_all
> Breakpoint 2 at 0x4037fd: file /var/tmp/portage/sys-apps/util-linux-2.26.1-r1/work/util-linux-2.26.1/sys-utils/mount.c, line 130.
> 
> 
> 
> <Okay, this is where gdb does something crazy.  Note that (see the line above)
>  gdb set the breakpoint at mount.c:130, but in fact print_all is defined at
>  mount.c:123, seven lines earlier>
> 
> (gdb) list mount.c:123
> 118			else
> 119				fputc(*p, stdout);
> 120		}
> 121	}
> 122	
> 123	static void print_all(struct libmnt_context *cxt, char *pattern, int show_label)
> 124	{
> 125		struct libmnt_table *tb;
> 126		struct libmnt_iter *itr = NULL;
> 127		struct libmnt_fs *fs;
> (gdb) 
> 
> 
> This seems to me to be very buggy behavior, but I'd like to get opinions from
> people who really know gdb, which I don't.

I think it wants to put you on the first real statement of the function.

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com


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

* Re: [gentoo-user] [~amd64] Confusing behavior from gdb
  2015-04-25 23:42 ` covici
@ 2015-04-26  2:52   ` Fernando Rodriguez
  0 siblings, 0 replies; 3+ messages in thread
From: Fernando Rodriguez @ 2015-04-26  2:52 UTC (permalink / raw
  To: gentoo-user

On Saturday, April 25, 2015 7:42:30 PM covici@ccs.covici.com wrote:
> > (gdb) list mount.c:123
> > 118			else
> > 119				fputc(*p, stdout);
> > 120		}
> > 121	}
> > 122	
> > 123	static void print_all(struct libmnt_context *cxt, char *pattern, int 
show_label)
> > 124	{
> > 125		struct libmnt_table *tb;
> > 126		struct libmnt_iter *itr = NULL;
> > 127		struct libmnt_fs *fs;
> > (gdb) 
> > 
> > 
> > This seems to me to be very buggy behavior, but I'd like to get opinions 
from
> > people who really know gdb, which I don't.
> 
> I think it wants to put you on the first real statement of the function.
> 

Yes. Also, if you compiled with any optimizations compile again with none. 
That way the compiler will try to generate code that matches the order of your 
C statements. It doesn't guarantees that this won't happen but with 
optimizations if you try to step through the source it'll definitely be jumping 
back and forth. The first statement here is line 126 but it may be optimized 
away or out of order. Also for source code debugging it'll be much easier to 
use a graphical frontend (ddd,kdbg,kdevelop,etc).

-- 
Fernando Rodriguez


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

end of thread, other threads:[~2015-04-26  2:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-04-25 23:31 [gentoo-user] [~amd64] Confusing behavior from gdb walt
2015-04-25 23:42 ` covici
2015-04-26  2:52   ` Fernando Rodriguez

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox