Error report seen in .o file but not in Console Topic is solved

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:

Error report seen in .o file but not in Console

Postby aclassifier » Thu Jan 18, 2018 4:12 pm

This thread is a follow-up from http://www.xcore.com/viewtopic.php?f=26&t=6331.

The problem here is that in /.build/src/__arduino_on_xmos_test.xc.o I found a lot of alias error reports. I opened in in TextEdit and much is readable there. You will find all alias error reports in /.build/src/__arduino_on_xmos_test.xc.o file.zip. See first attachment zip file.

However, when I started this thread I had made a task out of the code in main in the above src file (there is only one), then there was a completely different set of error reports in /.build/src/__arduino_on_xmos_test.xc.o. See second attachment zip file.

None of these error reports are seen in the console.

Is this something "serious" or is it some kind of perturbation that the developers have done to observe some particular behaviour?

xTIMEcomposer 14.3.2
Attachments
__arduino_on_xmos_test - 2018 01 18 B other errors in .o file.zip
other errors in /.build/src/__arduino_on_xmos_test.xc.o
(88.77 KiB) Downloaded 151 times
__arduino_on_xmos_test - 2018 01 18 B other errors in .o file.zip
other errors in /.build/src/__arduino_on_xmos_test.xc.o
(88.77 KiB) Downloaded 151 times
__arduino_on_xmos_test - 2018 01 18 A alias errors in .o file.zip
alias errors in /.build/src/__arduino_on_xmos_test.xc.o
(84.25 KiB) Downloaded 87 times
__arduino_on_xmos_test - 2018 01 18 A alias errors in .o file.zip
alias errors in /.build/src/__arduino_on_xmos_test.xc.o
(84.25 KiB) Downloaded 87 times
View Solution
robertxmos
XCore Addict
Posts: 169
Joined: Fri Oct 23, 2015 10:23 am

Postby robertxmos » Thu Jan 18, 2018 5:13 pm

Hi aclassifier,

The xc language will check for bad code at compile time as much as possible (e.g. array bound overflow).
Somethings it can't check until run time (it does not have all the information).
In this case the code will contain simple 'trap' instructions that stop the core should something bad happen (rather than it carrying on into undefined behavior - a form of 'defensive programming').

To make things nicer, the .o contains messages that will be printed up by the IDE/debugger if/when you arrive at one of these traps statements.
These messages are not loaded onto your target, they are there to give you more information if/when things go bad.

The reason the number of messages has changed is because the ability for the compiler to be sure at compile-time or not has changed.
This is all quite normal.

robert
User avatar
aclassifier
Respected Member
Posts: 319
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Postby aclassifier » Thu Jan 18, 2018 11:08 pm

So, that's where those messages are! Thanks! This is so good! I love it!

Off Topic
It reminds me of a message I got from the occam compiler: "Run-time disjointness check inserted". This was from the occam 2 compiler, I have the manuals, it's in the May 1995 D7405A occam 2.1 Toolset Reference Manual, page 119. It also was in th earlier Toolsets. The compiler ran on 386/486, and I seem to remember that when this message came the disk had been quiet for a while, so I got the feeling that that message was going to appear soon, since the processor was doing some loop. I think it was searching to do the disjointness checks at compile time, but had to give up. Or maybe there was some NP-complete algorithm that gave up. (Does anybody know?) I also think that this was when there was a replicated PAR with some kind of weakness in the definition of the limit. N had to be a constant, but still. "Disjointness" Inmos didn't define in their Glossary in the same set of books, but I think it basically was aliasing between processes. Disclaimer: mostly trying to reconstruct memory here..

Who is online

Users browsing this forum: bear118 and 121 guests