| 1 |
On Saturday, April 25, 2015 7:42:30 PM covici@××××××××××.com wrote: |
| 2 |
> > (gdb) list mount.c:123 |
| 3 |
> > 118 else |
| 4 |
> > 119 fputc(*p, stdout); |
| 5 |
> > 120 } |
| 6 |
> > 121 } |
| 7 |
> > 122 |
| 8 |
> > 123 static void print_all(struct libmnt_context *cxt, char *pattern, int |
| 9 |
show_label) |
| 10 |
> > 124 { |
| 11 |
> > 125 struct libmnt_table *tb; |
| 12 |
> > 126 struct libmnt_iter *itr = NULL; |
| 13 |
> > 127 struct libmnt_fs *fs; |
| 14 |
> > (gdb) |
| 15 |
> > |
| 16 |
> > |
| 17 |
> > This seems to me to be very buggy behavior, but I'd like to get opinions |
| 18 |
from |
| 19 |
> > people who really know gdb, which I don't. |
| 20 |
> |
| 21 |
> I think it wants to put you on the first real statement of the function. |
| 22 |
> |
| 23 |
|
| 24 |
Yes. Also, if you compiled with any optimizations compile again with none. |
| 25 |
That way the compiler will try to generate code that matches the order of your |
| 26 |
C statements. It doesn't guarantees that this won't happen but with |
| 27 |
optimizations if you try to step through the source it'll definitely be jumping |
| 28 |
back and forth. The first statement here is line 126 but it may be optimized |
| 29 |
away or out of order. Also for source code debugging it'll be much easier to |
| 30 |
use a graphical frontend (ddd,kdbg,kdevelop,etc). |
| 31 |
|
| 32 |
-- |
| 33 |
Fernando Rodriguez |
Archives