Apologies for breaking the thread, but I don't actually subscribe to the patches list so can't just hit reply!
Bart wrote: > This SPI driver did not use linker garbage collection the way I > intended for SPI drivers. It created a C++ object in > src/spi_stm32_init.cxx which was places in libextras.a. Hence the C++ > object was always part of any application link, and because of the > KEEP(*.ctors) in the linker script its constructor would never get > garbage-collected. Net result: all applications would end up with the > C++ object, the constructor, and the cyg_spi_cortexm_stm32_init() > function, even if SPI was never used. That bit of code was essentially a cut and paste from the AT91 SPI driver, which sounds as though it may suffer from the same problem. > I also looked at moving the three SPI buses into separate modules, > built unconditionally. Again linker magic would ensure that only buses > actually used by the application would end up in the application, with > no need for developers to enable the relevant CDL components. This > does not look entirely feasible right now, there are too many per-bus > configuration options. Getting rid of the 'bus enable' checkboxes would definitely be a good thing. Generally, the configuration options are only used to statically initialise the 3 bus data structures - so it should be fairly easy to pull each bus data structure declaration into a separate compile unit with per-bus constructors and function tables. The common core functions would then only be pulled in if at least one of the per-bus compile units were actually referenced. I'll have a look at it. Chris.
