The failure is more obvious on the Intel Mac OS snapshot machine, but the underlying failure is still there on other platforms. However, it is failing in a way that the regression tests are not detecting the failure. For some reason, the setjmp/longjmp functions are in area "_CODE" rather than "CODE" and end up located starting at 0x0000. After calling 0x0000, the simulator executes nonsense instructions since that area of memory does not map to flash/rom. In the case that the regression tests "passes", the simulator eventually reaches a halt instruction. In the case that the regression fail fails, the simulator eventually reaches an undefined opcode. Either way, it does not display the summary of the test results like it would if it really passed. (You can manually check .../support/regression/results/stm8/setjmp.out to see how the simulation terminated and confirm presence of the test result summary.)
Perhaps the area name in setjmp.s just needs to be fixed. I'll open a new ticket about the regression tests not catching this kind of failure.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems to me it's not. Why is this code in area "_CODE" when all other code is generated in "CODE"? Is there a special reason to put it in a separate area/segment?
If you link it manually as the first object, will it still work or is it placed at 0x0000 again? For this reason the mcs51 asm files declare all relevant areas first (e.g. device/lib/mcs51/gptr_cmp.asm) before starting the actual code.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The bug is fixed only to the extent that the regression test correctly runs in the simulator now. However, the setjmp/longjmp functions are located in RAM (check the .map file) so it would still fail on real hardware where RAM cannot be preloaded.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Fixed in rev9061.
The failure is more obvious on the Intel Mac OS snapshot machine, but the underlying failure is still there on other platforms. However, it is failing in a way that the regression tests are not detecting the failure. For some reason, the setjmp/longjmp functions are in area "_CODE" rather than "CODE" and end up located starting at 0x0000. After calling 0x0000, the simulator executes nonsense instructions since that area of memory does not map to flash/rom. In the case that the regression tests "passes", the simulator eventually reaches a halt instruction. In the case that the regression fail fails, the simulator eventually reaches an undefined opcode. Either way, it does not display the summary of the test results like it would if it really passed. (You can manually check .../support/regression/results/stm8/setjmp.out to see how the simulation terminated and confirm presence of the test result summary.)
Perhaps the area name in setjmp.s just needs to be fixed. I'll open a new ticket about the regression tests not catching this kind of failure.
So I was cheated by the previous regression test on my 32-bit ubuntu.
Shouldn't this bug be reopened if it isn't fixed?
I though this bug itself was already fixed in rev9061, and it revealed bug #2292.
It seems to me it's not. Why is this code in area "_CODE" when all other code is generated in "CODE"? Is there a special reason to put it in a separate area/segment?
If you link it manually as the first object, will it still work or is it placed at 0x0000 again? For this reason the mcs51 asm files declare all relevant areas first (e.g. device/lib/mcs51/gptr_cmp.asm) before starting the actual code.
The bug is fixed only to the extent that the regression test correctly runs in the simulator now. However, the setjmp/longjmp functions are located in RAM (check the .map file) so it would still fail on real hardware where RAM cannot be preloaded.
Sorry for my carelessness. Now it should be fixed in rev9062.