#2291 setjmp.c fails in rev9059 on MacOS

closed-fixed
Ben Shi
None
STM8
5
2014-08-20
2014-08-17
Ben Shi
No

Though regression test has passed on my ubuntu before submitting rev9059, I find that setjmp.c fails on MacOS from the snapshot build page.

Discussion

  • Ben Shi
    Ben Shi
    2014-08-18

    • status: open --> closed-fixed
     
  • Ben Shi
    Ben Shi
    2014-08-18

    Fixed in rev9061.

     
  • Erik Petrich
    Erik Petrich
    2014-08-18

    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.

     
  • Ben Shi
    Ben Shi
    2014-08-18

    So I was cheated by the previous regression test on my 32-bit ubuntu.

     
  • Maarten Brock
    Maarten Brock
    2014-08-18

    Shouldn't this bug be reopened if it isn't fixed?

     
  • Ben Shi
    Ben Shi
    2014-08-19

    I though this bug itself was already fixed in rev9061, and it revealed bug #2292.

     
  • Maarten Brock
    Maarten Brock
    2014-08-19

    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.

     
  • Erik Petrich
    Erik Petrich
    2014-08-19

    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.

     
  • Ben Shi
    Ben Shi
    2014-08-20

    Sorry for my carelessness. Now it should be fixed in rev9062.