luckily, it is not working like that on z80 targets. anyway, there is sense in introducing the storage attributes for the constants, like: const int data __nonbanked = 42; or introduce the __attribute__() keyword, similar to gcc and clang. also there is sense to remove the obscure behavior, when in the banked C codethere is the __nonbanked function, the constant array just before that function also goes to the nonbanked space - that's frustrating. #pragma bank 2 #include <stdint.h> const uint8_t...
probably, the "C source line" symbol format may be extended a bit, to avoid the possible clashing. for example, by adding the additional information about the caller point (file/line) alongside with the existing information. or just completely disable the emission of those symbols for the internals of the inline functions - that result in loosing ability to step into them, similar to what is happening with macros.
the __banked __nonbanked functions
yes, this bug is pretty annoying :(
any news on this, Philipp?
it does not, it is ok to close this issue.
because the order of linking matter. the order how you pass the object files into the linker through the command line or the link file. on almost every system, including modern, order of linking matter.
because the order of linking matter. on almost every system, including modern, order of linking matter.