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

Technical questions regarding the XTC tools and programming with XMOS.
Post Reply
User avatar
aclassifier
Respected Member
Posts: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Error report seen in .o file but not in Console

Post by aclassifier »

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 230 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 230 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 166 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 166 times


--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
View Solution
robertxmos
XCore Addict
Posts: 169
Joined: Fri Oct 23, 2015 10:23 am

Post by robertxmos »

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: 483
Joined: Wed Apr 25, 2012 8:52 pm
Contact:

Post by aclassifier »

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..
--
Øyvind Teig
Trondheim (Norway)
https://www.teigfam.net/oyvind/home/
Post Reply