Add a check and prompt to rename _sdcc_external_startup to __sdcc_external_startup with newer SDCC versions#14
Conversation
|
By the way, if you're wondering why not also add the opposite check, for use of The |
|
Yes, indeed. Thanks to @spth for adding it unexpectedly quickly. However, the SDCC change only emits a warning and lets compilation proceed, whereas my suggested change actually causes compilation (or, technically, the assembly stage) to fail altogether and the message makes explicitly clear what the situation is and what needs to be changed, so I think it still has some merit even in light of the SDCC feature. |
As you may be aware, as of current SDCC development version 4.2.10, and for the forthcoming release version 4.3.0, the
_sdcc_external_startupfunction has been renamed to__sdcc_external_startup(note the additional underscore at the beginning). See SDCC feature request #859.This creates potential compatibility problems for Free-PDK header users who:
In both cases, the user will encounter transparent (i.e. without warning or error) failure or misbehaviour due to omission of system clock initialisation and calibration that is typically done inside the startup function by the Free-PDK header macros.
While there are potentially plans to solve the former issue SDCC-side (see feature request #868), I have devised a way of helping the latter case, and also situations where existing codebases are updated to the latest Free-PDK includes.
Because it is (one way or another) obligatory to call the
PDK_SET_SYSCLOCK()macro within the startup function, it can be used as a convenient point to make a check on the name of the startup function when necessary.This modification adds a check against the SDCC version in use, and if it's a version equal to or newer than the revision the change to
__sdcc_external_startupwas made, it uses inline assembler macros to then check whether a label (i.e. function) is defined with the old name. When one is, an error message is emitted prompting the user to update their code to the new name:Where the user is already using the new name, the check is entirely transparent.
Note that the check does not change the code emitted by the macro. The check takes place entirely at compile-time.