It is exacly like this in IAR4 - the vector table in LIB is located in segment CODE, which is
of type CODE and aligned on 2-byte boundaries; the table begins with __APP_start, so
other symbols could be located by computing the offset.
Here’s the excerpt from LIB’s ASM_Functions.s:
RSEG CODE:CODE(2)
__APP_Start ;void __APP_Start(void)
B 0x0800C121
__USB_Istr ;
B USB_Istr
__CTR_HP ;
B CTR_HP
__MSD_WriteBlock ;
B MSD_WriteBlock
__MSD_ReadBlock ;
B MSD_ReadBlock
__Get_Font_8x14 ;
B Get_Font_8x14
__Get_Ref_Wave ;
B Get_Ref_Wave
__SD_Set_Changed ;void SD_Set_Changed(void);
B SD_Set_Changed
The only EXPORTED symbol is __APP_Start, which contains the IAR4 entry point for APP.
Now, the parallel definitions in APP’s ASM_Functions.s are these:
__CTR_HP ;void __CTR_HP(void)
B 0x08004159
__USB_Istr ;void __USB_Istr(void);
B 0x08004155
;-------------------------------------------------------------------------------
__MSD_WriteBlock ;u8 __MSD_WriteBlock(u8* pBuffer, u32 WriteAddr, u16 NumByteToWrite)
B 0x0800415D
__MSD_ReadBlock ;u8 __MSD_ReadBlock(u8* pBuffer, u32 ReadAddr, u16 NumByteToRead)
B 0x08004161
__Get_Font_8x14 ;u16 __Get_TAB_8x14(unsigned char Code, unsigned short Row)
B 0x08004165
__Get_Ref_Wave ;u8 __Get_Ref_Wave(unsigned short i)
B 0x08004169
__SD_Set_Changed ;void __SD_Set_Changed(void)
B 0x0800416D
from which you can infer that __APP_Start resides in memory at location 0x08004151 when LIB is compiled under IAR4. Of course, it won’t get the same address with IAR5 - there’s a brand new linker, there.
And, for the very same reason (as you already pointed out), __APP_Start should be updated to contain a different address - the APP entry point under both gcc and IAR5 will be different from 0x0800C121.
Well, this needs a solid rework in IAR5 too
A good starting point for me could be the one you proposed - a separate section whose address is specified via linker config. These notes explain how to do that in IAR5:
http://supp.iar.com/Support/?note=36121
http://supp.iar.com/Support/?note=17934
Don’t know about gcc, but another problem in the migration to IAR5 could be given by different stack alignment: from the migration guide at http://supp.iar.com/FilesPublic/SUPPORT/004242/EWARM_MigrationGuide.ENU.pdf, I read
Antonio