Question for debugging a forked program and reload symbol

Hi

I have a very simple program

#include <stdio.h>

int num = 0;

int main(int argc, char*argv[]){

int pid;

int num;

pid = fork();

printf("%d", pid);

if(pid == 0){ /child/

num = 1;

}else if(pid > 0){ /parent/

num = 2;

}

printf("%d", num);

while(num) {

num ++;

}

return num;

}

I break at num = 1;

B g.c:9

And I run

The program never hits the breakpoint.

And the output from the program is

4862

2

0

However, if I run in terminal

The output is

4813

2

0

1

It looks like the forked portion is not available in lldb.

What’s going on here?

Another question:

If I am debugging an executable, after I modified the source

And re-compile the executable, the next time when I run

Under debugger, gdb will show reload symbol. I didn’t see

The same thing for lldb or any output about updating. Do

I have to reload the executable every time I modify it?

I am using Moutain Lion, lldb-179.5

Thanks,

Yin

Hi

I have a very simple program

#include <stdio.h>
int num = 0;
int main(int argc, char*argv[]){
    int pid;
        int num;
    pid = fork();
    printf("%d", pid);
    if(pid == 0){ /*child*/
        num = 1;
    }else if(pid > 0){ /*parent*/
        num = 2;
    }
    printf("%d", num);
        while(num) {
                num ++;
        }

        return num;
}

I break at num = 1;
B g.c:9

And I run
The program never hits the breakpoint.
And the output from the program is
4862
2
0

However, if I run in terminal
The output is
4813
2
0
1

It looks like the forked portion is not available in lldb.
What’s going on here?

Since fork copies the address space of the parent, the breakpoint trap we put in goes along for the ride, and when the child gets running it hits it. lldb doesn't follow forks at present, so it doesn't know to catch the child's breakpoint hit, and so the child will just die. That's why you didn't see its output.

Another question:
If I am debugging an executable, after I modified the source
And re-compile the executable, the next time when I run
Under debugger, gdb will show reload symbol. I didn’t see
The same thing for lldb or any output about updating. Do
I have to reload the executable every time I modify it?

lldb just reloads the executable if it changes. We don't print a message saying we did this. Maybe we ought to, just to reassure folks we did the right thing?

I am using Moutain Lion, lldb-179.5

That's a pretty old lldb, but I'm pretty sure we've done this correctly for quite some time.

Jim

Hi Jim,

Thank you for the quick reply.
I am try lldb on Maverick to see if any message for
Reloading.

Thanks,

Yin

Yin,

Sorry if I was confusing. Even on the Mavericks lldb we don't put up a message for reloading, we just do the right thing...

What I was saying was I won't guarantee that we did the reloading itself correctly on that older lldb, thought I am pretty sure we do. I just don't have a copy around to test.

If we think we should have a reloading message, somebody should file a bug or just implement it.

Jim

Hi Jim,

I would like to file a bug. Our Affinic Debugger GUI depends
An output to reload message to update source code windows. Without
A hint, our users have to refresh source manually.

Thanks,

Yin

-Mike

In my experience with gdb, this message was usually just noise. I pretty much always KNEW that I had rebuilt the executable, so all the message told me was that gdb didn't drop the ball. That is I guess reassuring, but not really necessary. However, I have no strong objection to it.

To tell the truth, if you actually do depend on this, you should probably implement the message yourself, with or without filing the bug. I'm not sure it is generally useful enough to hope somebody else will put it in for you any time soon.

Jim

Hi Jim,

It is also best for me to implement it by using python api.
Do you know what is the best way to do it?

Thanks,

Yin

I have been doing this sort of thing by having the change cause an event to be sent (so the Target would send a eBroadcastBitModuleChanged event) and then have the driver program listen for an event of this type, and print a message when it gets it. You can look at the handling of eBroadcastBitBreakpointChanged in Target.cpp and Driver.cpp for an example of doing this.

It is not something that can be done at the SB layer, since that doesn’t have a good way to know that this has happened.

Jim