Hi Peter, >For problem 1, the commit comments imply my attempt to orthogonalize the >attributes went too far: critical and reentrant can't be combined with naked >because they require prologue/epilogue code, but I thought they might be >useful
>on an interrupt without realizing I'd already disallowed that combination too. > >I'll look into remove that restriction (SF 3257021). Yes it was no problem to remove the restriction. >FWIW, "naked" is a rather poorly defined construct, as the original >implementation would allow you to write code that would silently overwrite >parts > > >of the stack. "task" (documented only in the mailing list archives) is >equivalent to naked except that it allocates a stack frame when the function >requires one, and is what main() will be given when I deal with 3207046. The FreeRTOS example I'm using does not use 'task', but I agree that 'task' is useful for functions that don't return. >I'm curious, though, why your interrupt routine needs control of the order of >register saves. Does FreeRTOS inspect the stack to extract register values >for >some reason? FreeRTOS task switches through a pre-emptive interrupt. So manipulates the return address on the stack to switch tasks. This also means that all registers must be saved. Some way of saving all regs would be nice(tm). >For problem 2 my sole suggestion is to use msp430-objdump to display the >interrupt vector, and check that all values are valid and don't end up at >zero. (Unless you end up at zero as a consequence of hitting your naked ISR, >in which case maybe I had some other reason in mind for ruling out that >combination. In general, it's rather dangerous to assume that you can know >what > > >the compiler did to your code well enough to generate correct prologue and >epilogue code.) I still have to look into what is going on. Peter ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Mspgcc-users mailing list Mspgcc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mspgcc-users
