Bootloader + Main App (ARM7) -

It should be possible to put together a library that would be used by the bootloader and the main application. If I am not mistaken, TI embeds their Stellarisware library in ROM of some of their MCU's. I suggest that you try to figure out how exactly they do it.

It should be possible to put together a library that would be used by the bootloader and the main application. If I am not mistaken, TI embeds their Stellarisware library in ROM of some of their MCU's. I suggest that you try to figure out how exactly they do it.

But a library should have to be linked twice, offering no solution to the code size issue.
Maybe it is better to place the functions needed in a predefined location - maybe via a function pointer table to make it flexible. That table can then be compiled as part of both components, but the actual implementation will reside in only one of them.

But a library should have to be linked twice

With a rather narrow definition of 'library', yes. What I meant is different.

..Tamir's solution seems viable, ill start looking into this asap. Cheers everyone.

I did some quick searching and reading on Mike's suggestion about StellarisWare library in ROM.

LM3S9B96 ROM USER'S GUIDE
www.ti.com/.../spmu127c.pdf

1 Introduction
The LM3S9B96 ROM contains the Stellaris® Peripheral Driver Library and the Stellaris Boot
Loader. The peripheral driver library can be utilized by applications to reduce their flash footprint, allowing the flash to be used for other purposes (such as additional features in the application). The boot loader is used as an initial program loader (when the flash is empty) as well as an application initiated firmware upgrade mechanism (by calling back to the boot loader).
There is a table at the beginning of the ROM that points to the entry points for the APIs that are provided in the ROM. Accessing the API through these tables provides scalability; while the API locations may change in future versions of the ROM, the API tables will not. The tables are split into two levels; the main table contains one pointer per peripheral which points to a secondary table that contains one pointer per API that is associated with that peripheral. The main table is located at 0x0100.0010, right after the Cortex-M3 vector table in the ROM.
The following table shows a small portion of the API tables in a graphical form that helps to illustrate the arrangement of the tables:

Would the Backward Compatibility be an issue?

...this is the route I was previously investigating which John mentions above.

ARM LTD support have replied and advised looking into creating/reading 'SYMDEF' which ive now tried through the uVision4 IDE and it does work although it has the following warnings ".\Hex\HEXOUTPUT.axf: Warning: L6307W: .text(APP.o) contains branch to unaligned destination."

As ive understood the SYMDEF generates a table listing all function / data variables addresses residing at the Bootloader App Level. Its this table ive imported into the Main App deleting unwanted references and compiled the Main App project.

Cheers all for your suggestions.

Have a good day :)

The BIOS-style method of having library functions stored in the boot loader and accessing it through a jump table or an interrupt vector can save code space.

But there is one big issue. When the library functions are generated using C/C++, there might be use of helper functions that can potentially interfere. The library code in the boot loader will get one copy of these helper functions and the application a second copy. Normally not a problem, unless these helper functions assumes the existence of RAM variables for storing some state information.

Having two sets of the helper functions means that there will be two (probably different) assumptions about where these variables are stored.