I have 2 cross compilers that target m68k-elf (coldfire): 1. GCC 4.2.1 (binutils 2.18) - host = windows 2. GCC 4.4.2 (binutils 2.20) - host = OSX(intel) the first was provided by the vendor of the embedded system I am working with, the second I built. They both work fine when creating code that links against the vendors non-debug static libs. However, when I link (with the 4.4.2/2.20 combo) against the debug versions of the vendor supplied libs, I get several gcc_except_table sections at the beginning of the code. This does not happen with the vendors 4.2.1/2.18 setup. The embedded system must have the start of text at 0x020000000, but with the exception entries it gets pushed back to around 0x020000A0 so when it loads it traps. I built the 4.4.2 gcc with the same configure flags that the vendor supplied gcc was compiled with (less the windows specific), I am using the same crt & link script with both compilers. I know that the non-debug libs were built with -fno-exceptoins and the debug versions were built without this flag. I can see gcc_except_table sections in the debug libs when viewed via readelf. But again, when linking with 4.2.1/2.18 is does not happen. I was reading Ian Lance Taylor's linking articles on his blog from back in 2007, but the info on gcc_except_table was very short. It did imply that there was a optimization that moved the exception tables from inline with the text to the beginning of text, or did I misunderstand? The elf file gets converted to s-records before it gets loaded onto the embedded system, I could easily enough strip out the exception tables and shift the address of everything else so the text starts at the correct place, but is this asking for trouble? Or is this case of simply not being able to use libs with exceptions built on a windows host on a different host? If anyone has any pointers on where I should look to resolve this I would sure like hear. thanks alan
