Detection / call to _sdcc_external_startup is not working anymore instead presence of __sdcc_external_startup (note the double _ in front) is checked and called.
According to SDCC documentation the correct implementation / naming is _sdcc_external_startup
https://sdcc.sourceforge.net/doc/sdccman.pdf (page 68)
One of these modules (crtstart.asm) contains a call to the C routine _sdcc_external_startup() at the start of the CODE area. This routine is also in the runtime library and returns 0 by default. If this routine returns a non-zero value, the static & global variable initialization will be skipped and the function main will be invoked. Otherwise static & global variables will be initialized before the function main is invoked. You could add an _sdcc_external_startup() routine to your program to override the default if you need to setup hardware or perform some other critical operation prior to static & global variable initialization. ...
unsigned char _sdcc_external_startup ()
{
return 0;
}
Right now, when you create a program with your own _sdcc_external_startup function it is never called. However if you call the function __sdcc_external_startup everything works as expected.
The name has been changed as of in-development version 4.2.10. I assume you must be using a snapshot build or self-built version from latest source. If so, note that the linked version of the manual is from 4.2.8 and does not reflect the change, meaning this is not a bug.
See [feature-requests:#859] and this GitHub issue I filed notifying the Free-PDK project about this change.
Please also be aware that as of 4.2.12 the behaviour of
__sdcc_external_startuphas been harmonised, which means that all platforms now check the return value of the function call and will skip initialisation of global/static variables if the returned value is non-zero.Related
Feature Requests:
#859I see...
Right now it is just a REALLY REALLY REALLY bad behaviour from SDCC.
It took me some time (I had to look at the disassembly) to find out why every single existing program ever written for PDK was not working when using latest SDCC branch.
Breaking every source code written for a platform is one thing...
... but not adding a simple warning in the compiler when the old function name is found but using a self defined function which is in 99.999% of all cases just WRONG for PDK is crazy.
Note: PDK platform uses some macros in all sources which are needed to setup sysclock and to add tuning macros executed during flashing of the firmware.
And since just an underscore was added a simple detection / redifinition in header files is also not possible.
I suggest to completely rename it to a more meaningful name like
__sdcc_pre_initor__sdcc_system_initAfter a complete rename, something in the base headers could be added like this.
Now the user finds out during compile time what is wrong. No need to try to flash the non working program and to spend hours...
It is technically properly documented as a breaking change in the current manual.
The fact that there has not been any new PDF snapshot of of it in months is very unfortunate, though.
Adding some sort of warning or error message sounds like a good idea at least for a transition period. Maybe a deliberately incompatible internal function declaration could do that job.
The valid issue pointed out by this factually invalid bug report is now recorded in [feature-requests:#868].
Related
Feature Requests:
#868