No source available for "main() " but there is

Technical questions regarding the xTIMEcomposer, xSOFTip Explorer and Programming with XMOS.
User avatar
aclassifier
Respected Member
Posts: 319
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

No source available for "main() " but there is

Postby aclassifier » Fri Jul 07, 2017 5:10 pm

When I say in the debug GUI that Debugger | Stop on startup at: main the error message No source available for "main() pops up. I haven't figured out how to debug then.

Even if I have only one file in the project and it's called main.exe (it's a test thing) that certainly contains the main function. However, If I untick the Stop at startup etc. and set some breakpoint the main.xe source and the debug functions panel appears.

It's been like this for a long time, also xTIMEcomposer 14.3.0.

Is it me or some other factor? Is there a work-around?
User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm
Contact:

Postby Bianco » Sat Jul 08, 2017 10:26 am

Yeah you can't break on a main function with par because it is more or less a function that doesn't exist anymore after compilation, it's more like telling your system configuration to the compiler.

Code: Select all

int main (void)
{
   return 0;
}


This should break I think.
User avatar
aclassifier
Respected Member
Posts: 319
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Sat Jul 08, 2017 8:19 pm

I am not certain if I understand this. Look at this code:

Code: Select all

void My_Server (chanend c_in, chanend c_out, int my_value) { // (1) No source available for "_start() " if Debugger | Stop on startup at: My_Server
    // I did have code in here when the above message was issued
}

void My_PingPong (chanend c_in_out) {
}

void My_Client (chanend c_out, chanend c_in, chanend c_out_in) {
}

int my_function (int param) { // (2) No source available for "_start() " if Debugger | Stop on startup at: My_Server
    return (param * param); // Unresolved breakpoint
}

int main(void) { // No source available for "main() " if Debugger | Stop on startup at: main
                 // However double-click on the line and make breakpoint WORKS!
    chan c_over;
    chan c_back;
    chan c_pingpong;
    int my_value = my_function(2);
    par {
        My_Server   (c_over, c_back, my_value);
        My_PingPong (c_pingpong);
        My_Client   (c_over, c_back, c_pingpong);
    }
    return 0;
}
When I try (1) with code in the body or (2) the debugger in both situations complains there is no source. This could be because the task / function are anonymously built or done in-line. But both my_function and especially My_Server are not undefined for me, I have defined them. This is not like a compiler having optimised away a line and then it's not defined, like in my_function. The debugger could have resolved them(?)

In both my_function and My_Process I also get this dialogue box from the debugger, it says "_start() " in both cases, after this next line:
No source available for "_start() "

Dialogue box:
Error stopping at My_Server
Reason: Target request failed: Function "My_Server" not defined
Continue?

HOWEVER, if I double-click on "main" the breakpoint shows and the debugger stops like I in my head have believed it should have in the first case! The Debugger | Stop on startup at: and this double-click are not symmetrical(!?) Also double-clicking in "main" is the only means to get the debug functions available. Else it just runs.

Unless somebody comes up with an explanation that I will remember the next time I come across this then I think that the xTIMEcomposer should perhaps be tidied a little here. Having worked with xTIMEcomposer for some years now I from time to time still think this strange. So I thought to bring it up here. But please put me straight if I am far out here, that this is all logical.

Related matter: The Debugger | Stop on startup at: dialogue comes up with default unticked and "main" greyed out. Perhaps it should come up with nothing in that field as default.
User avatar
Bianco
XCore Expert
Posts: 754
Joined: Thu Dec 10, 2009 6:56 pm
Contact:

Postby Bianco » Sun Jul 09, 2017 8:44 am

Aren't you running into the same problem as discussed here: viewtopic.php?f=26&t=5003 ?
User avatar
aclassifier
Respected Member
Posts: 319
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Sun Jul 09, 2017 5:19 pm

Yes and no. I have some new points here, but the "story" I guess starts about at the same place. I do think that this is something that XMOS should look into, as Henk suggested in that thread, too. But now I tested both on 14.2.3 and 14.3.0 and I still struggle with this.

Who is online

Users browsing this forum: bear118 and 169 guests