1
#include <iostream>
#include <vector>

using namespace std; 
int in;

bool isPrime(int n) {
    for (int i = 3; i <= n; i ++) {
        if (n%i != 0) {
            return false;
        }
    }
    return true;
}

vector<int>* generateVector(int n) {
    vector<int> v;
    for (int i = 2; i < 20; i ++) {
        if (i == n) {
            continue;
        }

        if (isPrime(i+n)) {
            v.push_back(i);
        }
    }
}

int main()
{
    while(1) {
        cin >> in;
        vector<int>* nVectors[21];
        for (int i = 1; i <= 20; i ++) {
            nVectors[i] = generateVector(i);
        } <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
    }
}

This some c++ code. And i would like to make a break point just after the for loop(the arrow show the position). I have found one way to solve it through adding a statement after it then make break point in this statement. But adding a statement without a meaning make not feeling good. So is there a better solution?

I am using GDB for debugging.

PS: I have already known how to set breakpoint in gdb. My intent is to break after the for loop ends, and display what in nVectors. Thanks.

Sorry for all. It's not the issue about the gdb or debugging skill, but there is a bug in my code. So when i print nVectors, nothing was printed. After fixing it, every method you provides works fine. Thanks.

Frank Cheng
  • 5,928
  • 9
  • 52
  • 80
  • 3
    Did you try to set breakpoint on "}" closing the function? – Alex F Dec 15 '11 at 07:17
  • I have tried, but failed. It will directly run to the "}" in the main. – Frank Cheng Dec 15 '11 at 07:30
  • 1
    The bug is that generateVector doesn't return anything (or you might run the risk of returning the address of a local variable), both of which can be caught at compile-time by enabling compiler warnings. - Since nVectors contains pointers to garbage, I don't see how inspecting what it contains can help. – visitor Dec 15 '11 at 10:46
  • Yes,you are right. I almost feel shame of it. But i am a java programmer, and try to learn some cpp programming skills. So some java discipline affects me a lot. – Frank Cheng Dec 16 '11 at 01:43

7 Answers7

2

You can use a assembly break point, just need to understand the assembly code of for loop.

gdb <your_bin>
layout split
break *0x80488ad              #assmebly code will look like 
                              #0x80488ad     jmp    0x8048874 <main+18>
Community
  • 1
  • 1
Kamath
  • 4,461
  • 5
  • 33
  • 60
1

gdb has a command to add break points

there are a couple of ways, but I think the one that might help you is :

(gdb) break filename:linenumber

so for example I want to break at line 10 in main.c

break main.c:10

you might want try a tutorial http://www.yolinux.com/TUTORIALS/GDB-Commands.html

loosebazooka
  • 2,363
  • 1
  • 21
  • 32
1

Nope there has to be some statement for the debugger to be able to set breakpoint.

v01d
  • 1,457
  • 1
  • 11
  • 22
  • I think maybe you are right. I have asked somebody before, he also give me this answer and advise me to add a dumb code after the loop for debugging. – Frank Cheng Dec 15 '11 at 07:35
1

I don't think there is a way to directly do what you want but you can still do it. Set a breakpoint on the last statement of the loop. When the debugger breaks switch the disassembly view and scroll down until you find where you want to place the real breakpoint. This will effective set a breakpoint at a specific address rather than on a line number in a source file.

Captain Obvlious
  • 19,754
  • 5
  • 44
  • 74
0

You can specify the source file and line of the end of the loop, like so, on the gdb command line:

b file.c:123

If you want to go right after the for loop, you'll want to actually set the break for the line of the closing bracket of the while() loop, I believe. But you can try both and see what gives the desired result.

Dan Fego
  • 13,644
  • 6
  • 48
  • 59
0

Try to use until command. It is useful to avoid single stepping through a loop. Also from gdb manual:

until always stops your program if it attempts to exit the current stack frame.

ks1322
  • 33,961
  • 14
  • 109
  • 164
0

If it was me, I'd set an assembly breakpoint, like the others said. But if you don't want to get into that, there's a simpler way: Since you know the loop count (20), and it is not very big, you can set a breakpoint on the last statement inside the loop (in your case, the only statement inside the loop), with the condition

if (i == 19)

Alternatively, you can set an ignore count:

ignore bnum 19

where bnum is the breakpoint number. This is probably faster, but in your case the difference will be negligible.

See Breakpoints, watchpoints, and catchpoints in the gdb documentation for more information.

TonyK
  • 16,761
  • 4
  • 37
  • 72