From j.revathy at gdatech.co.in Tue Apr 1 09:48:14 2008 From: j.revathy at gdatech.co.in (revathy) Date: Tue, 01 Apr 2008 15:18:14 +0530 Subject: linker error Message-ID: <47F204DE.9080404@gdatech.co.in> Hi all, We are working on CAN driver module for the coldfire Processor. While we are compiling the driver we are facing the following error. /opt/freescale/usr/local/gcc-4.2.47-uclibc-0.9.47/m68k-uclinux/bin/m68k-uclinux-ld.real: error: no memory region specified for loadable section `.modinfo' make: *** [vmlinux] Error 1 Can any one help us. Thanks in advance J.Revathy ------------------- We recently installed the spam filter from Abaca. It's over 99% accurate. Check it out - http://www.abaca.com/success/story.cgi?domain=gdatech.co.in ------------------- From TDannemiller at peco2.com Wed Apr 2 13:22:31 2008 From: TDannemiller at peco2.com (TDannemiller at peco2.com) Date: Wed, 2 Apr 2008 09:22:31 -0400 Subject: Debugging with cache enabled Message-ID: I'm trying G++ Lite with a Coldfire MC5485 target. When using a gdb soft breakpoint (break, tbreak) while processor cache is enabled, I always get an exception when trying to continue (or advance) after the breakpoint. The exception is vector 11, "Unimplemented line-f opcode". The single step (source line "step") also does not work when cache is enabled. Is this normal? I haven't seen any comments about this on this or the Freescale forums. The breakpoints (and step) work fine if processor cache is disabled, but my program doesn't run fast enough unless cache is enabled, and so I can't debug this way. Any suggestions? I'm aware of the hardware breakpoint, but it's not as versatile as the soft breaks (advance, until, step, etc). Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From David.Seymour at freescale.com Wed Apr 2 15:03:54 2008 From: David.Seymour at freescale.com (Seymour David) Date: Wed, 2 Apr 2008 08:03:54 -0700 Subject: [coldfire-gnu-discuss] Debugging with cache enabled In-Reply-To: References: Message-ID: Hi Tom, First I haven't tried this so I am going by gut knowledge. I suspect that when you set the soft breakpoints that the instruction opcode (or just the 16-bits of the opcode) is being replaced with the HALT (0x4ac8) instruction. Since it is actually in the code space, it probably is getting cached. When the debugger HALTs, it probably replaces the HALT with the real opcode BUT the cache is not updated (i.e. self modifying code is bad for cache). If the cache is flushed (if in copy-back mode) or invalidated (for write thru mode) then when you re-start code execution the cache will be updated properly. I may have some of the details incorrect but think the general description is correct. I typically do not enable cache when debugging as a rule of thumb. Some dev tools are better than others at supporting debugging while cache enabled. I just don't know the exact state of GDB for this. Regards, David David E Seymour Come to FTF 2008 June 16th through the 19th in Orlando http://www.freescale.com/ftf ________________________________ From: TDannemiller at peco2.com [mailto:TDannemiller at peco2.com] Sent: Wednesday, April 02, 2008 8:23 AM To: coldfire-gnu-discuss at codesourcery.com Subject: [coldfire-gnu-discuss] Debugging with cache enabled I'm trying G++ Lite with a Coldfire MC5485 target. When using a gdb soft breakpoint (break, tbreak) while processor cache is enabled, I always get an exception when trying to continue (or advance) after the breakpoint. The exception is vector 11, "Unimplemented line-f opcode". The single step (source line "step") also does not work when cache is enabled. Is this normal? I haven't seen any comments about this on this or the Freescale forums. The breakpoints (and step) work fine if processor cache is disabled, but my program doesn't run fast enough unless cache is enabled, and so I can't debug this way. Any suggestions? I'm aware of the hardware breakpoint, but it's not as versatile as the soft breaks (advance, until, step, etc). Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From carlos at codesourcery.com Wed Apr 2 20:48:41 2008 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 02 Apr 2008 16:48:41 -0400 Subject: [coldfire-gnu-discuss] linker error In-Reply-To: <47F204DE.9080404@gdatech.co.in> References: <47F204DE.9080404@gdatech.co.in> Message-ID: <47F3F129.3080806@codesourcery.com> revathy wrote: > /opt/freescale/usr/local/gcc-4.2.47-uclibc-0.9.47/m68k-uclinux/bin/m68k-uclinux-ld.real: > error: no memory region specified for loadable section `.modinfo' > make: *** [vmlinux] Error 1 > Can any one help us. This is likely a bug in your kernel linker script. Your kernel linker script needs to account for the new section. Check the upstream kernel to see if this has already been fixed. Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From mark at codesourcery.com Thu Apr 3 04:09:55 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Wed, 02 Apr 2008 21:09:55 -0700 Subject: [coldfire-gnu-discuss] Debugging with cache enabled In-Reply-To: References: Message-ID: <47F45893.90800@codesourcery.com> Seymour David wrote: > I typically do not enable cache when debugging as a rule of thumb. Some > dev tools are better than others at supporting debugging while cache > enabled. I just don?t know the exact state of GDB for this. I've asked our team to look into this. I'll report back if I learn more about our current status. Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From haluongvn at gmail.com Tue Apr 8 07:48:52 2008 From: haluongvn at gmail.com (Ha Luong) Date: Tue, 8 Apr 2008 14:48:52 +0700 Subject: Could I rebuild libcs3.a, libcs3coldfire.a and libcs3hosted.a? Message-ID: <61577c8f0804080048w35fc25a8t4b2e32c5f5e03f9@mail.gmail.com> Dear Sir, Could you please tell me how can rebuild libcs3.a, libcs3coldfire.a and libcs3hosted.a? Thank you, Ha Luong -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at codesourcery.com Tue Apr 8 13:10:56 2008 From: nathan at codesourcery.com (Nathan Sidwell) Date: Tue, 08 Apr 2008 14:10:56 +0100 Subject: [coldfire-gnu-discuss] Could I rebuild libcs3.a, libcs3coldfire.a and libcs3hosted.a? In-Reply-To: <61577c8f0804080048w35fc25a8t4b2e32c5f5e03f9@mail.gmail.com> References: <61577c8f0804080048w35fc25a8t4b2e32c5f5e03f9@mail.gmail.com> Message-ID: <47FB6EE0.7020808@codesourcery.com> Ha Luong wrote: > Dear Sir, > > Could you please tell me how can rebuild libcs3.a, libcs3coldfire.a and > libcs3hosted.a? you cannot rebuild these libraries. nathan -- Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery From daniel.mclean at optusnet.com.au Wed Apr 9 01:04:25 2008 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Wed, 9 Apr 2008 11:04:25 +1000 Subject: Access Error When Running Factorical Sample on M52235EVB with CodeSourcery G++ Version 4.2-59-m68k-elf Message-ID: Hi, I can successfully run and debug all the samples from ROM (or RAM if they fit) except for the factorial.c example. This occurs on both the Dev Kit (M52235EVB) and a custom board I have here (both using the PE Micro pod). Below is a stack trace from the debugger: sample [C/C++ Local Application] Sourcery G++ Debug Sprite for ColdFire ELF (9/04/08 10:58) (Suspended) Thread [0] (Suspended: Signal 'SIGTRAP' received. Description: Trace/breakpoint trap.) 6 __cs3_isr_access_error() 0x000094d2 5 0x44082700 4 _localeconv_r() 0x00005174 3 vfprintf() 0x0000257c 2 printf() 0x000005a6 1 main() at C:\Documents and Settings\maczor\workspace\sample\factorial.c:15 0x0000051c m68k-elf-gdb (9/04/08 10:58) C:\Documents and Settings\maczor\workspace\sample\Debug\sample (9/04/08 10:58) I can reproduce this problem by changing the printf line in the helloworld.c file printf("Hello World! %d", 25); Any ideas on what is causing this? I'm going to try the 4.2-111 version to see if there is any difference. Thanks Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.mclean at optusnet.com.au Wed Apr 9 01:03:16 2008 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Wed, 9 Apr 2008 11:03:16 +1000 Subject: Access Error When Running Factorical Sample on M52235EVB with CodeSourcery G++ Version 4.2-59-m68k-elf Message-ID: Hi, I can successfully run and debug all the samples from ROM (or RAM if they fit) except for the factorial.c example. This occurs on both the Dev Kit (M52235EVB) and a custom board I have here (both using the PE Micro pod). Below is a stack trace from the debugger: sample [C/C++ Local Application] Sourcery G++ Debug Sprite for ColdFire ELF (9/04/08 10:58) (Suspended) Thread [0] (Suspended: Signal 'SIGTRAP' received. Description: Trace/breakpoint trap.) 6 __cs3_isr_access_error() 0x000094d2 5 0x44082700 4 _localeconv_r() 0x00005174 3 vfprintf() 0x0000257c 2 printf() 0x000005a6 1 main() at C:\Documents and Settings\maczor\workspace\sample\factorial.c:15 0x0000051c m68k-elf-gdb (9/04/08 10:58) C:\Documents and Settings\maczor\workspace\sample\Debug\sample (9/04/08 10:58) I can reproduce this problem by changing the printf line in the helloworld.c file printf("Hello World! %d", 25); Any ideas on what is causing this? I'm going to try the 4.2-111 version to see if there is any difference. Thanks Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.mclean at optusnet.com.au Wed Apr 9 13:08:02 2008 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Wed, 9 Apr 2008 23:08:02 +1000 Subject: [coldfire-gnu-discuss] Access Error When Running Factorical Sample on M52235EVB with CodeSourcery G++ Version 4.2-59-m68k-elf In-Reply-To: Message-ID: There is no difference in version 4.2-111. It still does not work.. _____ From: Daniel McLean [mailto:daniel.mclean at optusnet.com.au] Sent: Wednesday, 9 April 2008 11:04 AM To: coldfire-gnu-discuss at codesourcery.com Subject: [coldfire-gnu-discuss] Access Error When Running Factorical Sample on M52235EVB with CodeSourcery G++ Version 4.2-59-m68k-elf Hi, I can successfully run and debug all the samples from ROM (or RAM if they fit) except for the factorial.c example. This occurs on both the Dev Kit (M52235EVB) and a custom board I have here (both using the PE Micro pod). Below is a stack trace from the debugger: sample [C/C++ Local Application] Sourcery G++ Debug Sprite for ColdFire ELF (9/04/08 10:58) (Suspended) Thread [0] (Suspended: Signal 'SIGTRAP' received. Description: Trace/breakpoint trap.) 6 __cs3_isr_access_error() 0x000094d2 5 0x44082700 4 _localeconv_r() 0x00005174 3 vfprintf() 0x0000257c 2 printf() 0x000005a6 1 main() at C:\Documents and Settings\maczor\workspace\sample\factorial.c:15 0x0000051c m68k-elf-gdb (9/04/08 10:58) C:\Documents and Settings\maczor\workspace\sample\Debug\sample (9/04/08 10:58) I can reproduce this problem by changing the printf line in the helloworld.c file printf("Hello World! %d", 25); Any ideas on what is causing this? I'm going to try the 4.2-111 version to see if there is any difference. Thanks Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at codesourcery.com Wed Apr 9 16:38:55 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Wed, 09 Apr 2008 09:38:55 -0700 Subject: [coldfire-gnu-discuss] Access Error When Running Factorical Sample on M52235EVB with CodeSourcery G++ Version 4.2-59-m68k-elf In-Reply-To: References: Message-ID: <47FCF11F.704@codesourcery.com> Daniel McLean wrote: > There is no difference in version 4.2-111? It still does not work?? Just a check: are you using the "hosted" or "unhosted" configuration? Also, how does your startup code work? Are you using the crt0.o and such that we're providing, or something else? Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From carlos at codesourcery.com Wed Apr 9 16:45:31 2008 From: carlos at codesourcery.com (Carlos O'Donell) Date: Wed, 09 Apr 2008 12:45:31 -0400 Subject: [coldfire-gnu-discuss] Access Error When Running Factorical Sample on M52235EVB with CodeSourcery G++ Version 4.2-59-m68k-elf In-Reply-To: References: Message-ID: <47FCF2AB.5090604@codesourcery.com> Daniel McLean wrote: > I can successfully run and debug all the samples from ROM (or RAM if > they fit) except for the factorial.c example. There is a small-factorial.c example (share/sourceryg++-m68k-elf-examples/small-factorial/small-factorial.c) which should fit anywhere. > This occurs on both the Dev Kit (M52235EVB) and a custom board I have > here (both using the PE Micro pod)? What board did you select for your project? Is your project using a hosted or unhosted target configuration? What board did you select when you created the debug configuration? > 6 __cs3_isr_access_error() 0x000094d2 > 5 0x44082700 This isn't a valid memory address for the board, which is why you faulted. How did you build the example? > 4 _localeconv_r() 0x00005174 > 3 vfprintf() 0x0000257c > 2 printf() 0x000005a6 > 1 main() at C:\Documents and > Settings\maczor\workspace\sample\factorial.c:15 0x0000051c Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From daniel.mclean at optusnet.com.au Wed Apr 9 23:05:40 2008 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Thu, 10 Apr 2008 09:05:40 +1000 Subject: [coldfire-gnu-discuss] Access Error When Running Factorical Sample on M52235EVB with CodeSourcery G++ Version 4.2-59-m68k-elf In-Reply-To: <47FCF2AB.5090604@codesourcery.com> Message-ID: Thanks for the quick reply.. I was using the hosted example with a Processor type of MCF52235 and a Board Type of m52235evb Eval (60MHz)... I have not modified any of the startup code. I followed stps specified in the Getting Started Guide (Chapter 5.2 - Building Applications). I'm using the hosted configuration so that I can see the output from printf/write in the Debug Output window. For the debug section I chose Sourcery G++ Debug Sprite for Coldfire ELF. In the Coldfire Settings tab of the Debug dialog, I chose the PE Micro Pod (USB1: USB-ML-CF Rev 0 (PE6012677)). I selected the config file m52235evb for debugging. I've tried the small-factorial.c you suggested and it runs fine from RAM or ROM. I get this output: factorial (0) = 1 factorial (1) = 1 factorial (2) = 2 factorial (3) = 6 factorial (4) = 24 factorial (5) = 120 factorial (6) = 720 factorial (7) = 5040 factorial (8) = 40320 factorial (9) = 362880 For building the application I just selected build all.... I built a new project again following the Getting Started Guide to the letter and have tried both the small-factorial.c (which worked), as well as factorial.c and pi.c (which didn't work) and I get the same problem... I get the same issue inside __locale_charset: test Debug [C/C++ Local Application] Sourcery G++ Debug Sprite for ColdFire ELF (10/04/08 08:38) (Suspended) Thread [0] (Suspended: Signal 'SIGTRAP' received. Description: race/breakpoint trap.) 5 __cs3_isr_access_error() coldfire-isrs.c:564 0x00008e5a 4 0x44082700 3 __locale_charset() \opt\codesourcery\m68k-elf\src\newlib\newlib\libc\locale\locale.c:275 0x00005b7a 2 printf() \opt\codesourcery\m68k-elf\src\newlib\newlib\libc\stdio\printf.c:52 0x000017b4 1 main() C:\Documents and Settings\maczor\workspace2\test\pi.c:26 0x00000672 m68k-elf-gdb (10/04/08 08:37) C:\Documents and Settings\maczor\workspace2\test\Debug\test (10/04/08 08:38) As a side issue how can I generate a linker file so that I can see where the linker/compiler is putting the objects.. -M and -Map seem to fail saying that there was no link occurring in the build process.. Thanks Daniel -----Original Message----- From: Carlos O'Donell [mailto:carlos at codesourcery.com] Sent: Thursday, 10 April 2008 2:46 AM To: Daniel McLean Cc: coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] Access Error When Running Factorical Sample on M52235EVB with CodeSourcery G++ Version 4.2-59-m68k-elf Daniel McLean wrote: > I can successfully run and debug all the samples from ROM (or RAM if > they fit) except for the factorial.c example. There is a small-factorial.c example (share/sourceryg++-m68k-elf-examples/small-factorial/small-factorial.c) which should fit anywhere. > This occurs on both the Dev Kit (M52235EVB) and a custom board I have > here (both using the PE Micro pod). What board did you select for your project? Is your project using a hosted or unhosted target configuration? What board did you select when you created the debug configuration? > 6 __cs3_isr_access_error() 0x000094d2 > 5 0x44082700 This isn't a valid memory address for the board, which is why you faulted. How did you build the example? > 4 _localeconv_r() 0x00005174 > 3 vfprintf() 0x0000257c > 2 printf() 0x000005a6 > 1 main() at C:\Documents and > Settings\maczor\workspace\sample\factorial.c:15 0x0000051c Cheers, Carlos. -- Carlos O'Donell CodeSourcery carlos at codesourcery.com (650) 331-3385 x716 From daniel.mclean at optusnet.com.au Wed Apr 9 23:07:49 2008 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Thu, 10 Apr 2008 09:07:49 +1000 Subject: [coldfire-gnu-discuss] Access Error When Running Factorical Sample on M52235EVB with CodeSourcery G++ Version 4.2-59-m68k-elf In-Reply-To: <47FCF11F.704@codesourcery.com> Message-ID: Hi Mark, I'm using the hosted configuration. I have not changed the startup code.. I followed the guide in the Getting Started document. Thanks Daniel -----Original Message----- From: Mark Mitchell [mailto:mark at codesourcery.com] Sent: Thursday, 10 April 2008 2:39 AM To: Daniel McLean Cc: coldfire-gnu-discuss at codesourcery.com Subject: Re: [coldfire-gnu-discuss] Access Error When Running Factorical Sample on M52235EVB with CodeSourcery G++ Version 4.2-59-m68k-elf Daniel McLean wrote: > There is no difference in version 4.2-111. It still does not work.. Just a check: are you using the "hosted" or "unhosted" configuration? Also, how does your startup code work? Are you using the crt0.o and such that we're providing, or something else? Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From haluongvn at gmail.com Sun Apr 13 11:42:09 2008 From: haluongvn at gmail.com (Ha Luong) Date: Sun, 13 Apr 2008 18:42:09 +0700 Subject: Could I write the interrupt function for catching signal SIGTRAP? Message-ID: <61577c8f0804130442j57fdfb27jf7afa3806400f8ef@mail.gmail.com> Dear Sir, I have the error when debugging with m68k-elf-gdb pe://USBMultilink/PE6013031 m5282evb Program received signal SIGTRAP, Trace/breakpoint trap. 0x22812620 in ?? () Could I write the interrupt function for catching signal SIGTRAP? Could you please explain what "00000000 <__cs3_interrupt_vector>:" does? If I have "jmp 0x00000000", could I write the interrupt function for catching the address error? And I could continue debugging the next address code after it? Thank you very much, Ha Luong -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Voss at brv.se Tue Apr 15 07:09:45 2008 From: Martin.Voss at brv.se (Martin Voss) Date: Tue, 15 Apr 2008 09:09:45 +0200 Subject: CS and 2.4.x vs. 2.6.x Message-ID: Hi, We have tried the CodeSourcery 4.2.1 toolchain for a MCF5208 based platform. We have also tried to compile the latest (20070130 + patch to bring it up to March 2008) uClinux-dist. We have successfully compiled both 2.6.x and 2.4.x kernels and they seem to work. However, is it at all correct to try and compile the 2.4 kernel and build user applications for the 2.4 kernel using this toolchain? I can admit that I don't fully understand the dependency of uClibc and kernel versions. When we compile a *kernel* uClibc is not involved at all, but when we start compiling user apps it is used. Is the CS toolchain's uClibc built for a 2.6. kernel only, and therefore it is incorrect to use this toolchain for all 2.4 related stuff? Sorry if this is obvious questions. Regards, Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at codesourcery.com Tue Apr 15 15:08:09 2008 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Tue, 15 Apr 2008 11:08:09 -0400 Subject: [coldfire-gnu-discuss] CS and 2.4.x vs. 2.6.x In-Reply-To: References: Message-ID: <20080415150805.GP13707@caradoc.them.org> On Tue, Apr 15, 2008 at 09:09:45AM +0200, Martin Voss wrote: > Hi, > > > > We have tried the CodeSourcery 4.2.1 toolchain for a MCF5208 based > platform. We have also tried to compile the latest (20070130 + patch to > bring it up to March 2008) uClinux-dist. We have successfully compiled > both 2.6.x and 2.4.x kernels and they seem to work. However, is it at > all correct to try and compile the 2.4 kernel and build user > applications for the 2.4 kernel using this toolchain? We build our glibc-based toolchains to require 2.6. I don't think the uClibc toolchains have any similar knob, but we never test them with 2.4 and we recommend the use of 2.6. So, it might work with 2.4, but we can't recommend it. As for building the kernel itself, our experience is that the Linux/uClinux kernel assumes too much about the tools used to build it. So using a very new compiler and a very old kernel rarely works. It may compile but not work correctly due to any number of problems fixed in 2.6. uClibc is not involved here, only gcc and binutils. -- Daniel Jacobowitz CodeSourcery From mark at codesourcery.com Wed Apr 16 06:41:13 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Tue, 15 Apr 2008 23:41:13 -0700 Subject: 2008q1 Release Message-ID: <48059F89.1090007@codesourcery.com> CodeSourcery is pleased to announce the availability of the 2008q1 Sourcery G++ Lite Edition release for ColdFire processors. This is available for download from: http://www.codesourcery.com/gnu_toolchains/coldfire New features in this release include: * Optimizations for ColdFire V4 and V4e cores. * Multi-GOT and Huge GOT support to permit the creation of large shared libraries under uClinux and GNU/Linux. * GCC has been upgraded to GCC 4.2.3. Enjoy! -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From daniel.mclean at optusnet.com.au Fri Apr 18 04:12:41 2008 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Fri, 18 Apr 2008 14:12:41 +1000 Subject: CS3 Startup Process - Specifying A Different Vector Table In-Reply-To: <48059F89.1090007@codesourcery.com> Message-ID: Hi, I'm having some rouble specifying my own vector table (as its size is different to the CS3 file. The linker complains that it is defined multiple times and that its size has changed. I get this error from the linker: From daniel.mclean at optusnet.com.au Fri Apr 18 04:17:48 2008 From: daniel.mclean at optusnet.com.au (Daniel McLean) Date: Fri, 18 Apr 2008 14:17:48 +1000 Subject: CS3 Startup Process - Specifying A Different Vector Table Message-ID: Hi, (Sorry for the repost but Outlook decided to send the email before I was finished composing it) I'm having some trouble specifying my own vector table (as its size is different to the one in the CS3 libraries). The linker complains that it is defined multiple times and that its size has changed. I get this error specifically: **** Build of configuration Sourcery G++ for ColdFire ELF for project wh3rev0 **** cs-make all m68k-elf-gcc -c -O2 -g3 -Wall -mcpu=52233 -DFreeRTOS -DGNU_COMPILE -D_GCC_USES_FP -I . -I.\\FreeRTOS\\mcf52235 -fshort-enums -fpack-struct vectors.c -MMD -o vectors.o vectors.c:542:9: warning: no newline at end of file m68k-elf-ld -Twh3rev0-rom.ld -Map=wh3rev0.map --start-group wh3rev0main.o reentrancy.o interrupt_handlers.o version.o vectors.o ./mcf5223x/mcf5223x.a ./FreeRTOS/FreeRTOS.a ./serial/serial.a ./securedigital/securedigital.a ./onboardflash/onboardflash.a ./console/console.a ./config/config.a ./sampling/sampling.a ./drive/drive.a ./fram/fram.a ./sstspiflash/sstspiflash.a ./spiflash/spiflash.a ./crc/crc.a ./hash/hash.a ./random/random.a ./eventlog/eventlog.a ./accumulators/accumulators.a ./loadsurvey/loadsurvey.a ./channels/channels.a ./webserver/webserver.a ./networking/networking.a ./tftp/tftp.a ./wh3ap/wh3ap.a ./wh3cp/wh3cp.a ./dhcp/dhcp.a ./tcpip/tcpip.a ./firmware/firmware.a ./gsmmodem/gsmmodem.a ./timing/timing.a ./security/security.a ./wavenis/wavenis.a ./waveflows/waveflows.a ./ustdlib/ustdlib.a ./uip/uip.a ./iobus/iobus.a ./relayouts/relayouts.a ./rtc/rtc.a -Lc:\\program\ files\\codesourcery\\sourcery\ g++\\m68k-elf\\lib\\m5208\\ -Lc:\\program\ files\\codesourcery\\sourcery\ g++\\lib\\gcc\\m68k-elf\\4.2.3\\m5208\\ -lgcc -lm -lc -lcs3 -lcs3unhosted -lcs3coldfire --end-group -o wh3rev0.elf vectors.o:(.cs3.interrupt_vector+0x0): multiple definition of `__cs3_interrupt_vector_coldfire' c:\program files\codesourcery\sourcery g++\m68k-elf\lib\m5208\\libcs3coldfire.a(coldfire-vector.o):(.cs3.interrupt_ vector+0x0): first defined here m68k-elf-ld: Warning: size of symbol `__cs3_interrupt_vector_coldfire' changed from 1024 in c:\program files\codesourcery\sourcery g++\m68k-elf\lib\m5208\\libcs3coldfire.a(coldfire-vector.o) to 1048 in vectors.o cs-make: *** [wh3rev0.elf] Error 1 However when I use the same vector file in a managed make project (eg. the factorial example from the Getting Started Guide). I have no problems. The difference I assume is because managed make uses gcc to build the elf file from a collection of object files, and my problem is arising because I want to use ld to link the files together, and some files are coming out of archives? What am I doing wrong, and why is ld even looking for the vector table when I've already got it defined? Thanks Daniel Here's my vectors.c file in case its of any use: /* Vector table that is compatible with CS3 .... */ typedef void handler(void); extern void __cs3_stack(void); extern void __cs3_reset(void); extern void __cs3_isr_access_error(void); extern void __cs3_isr_address_error(void); extern void __cs3_isr_illegal_instruction(void); extern void __cs3_isr_divide_by_zero(void); extern void __cs3_isr_interrupt_6(void); extern void __cs3_isr_interrupt_7(void); extern void __cs3_isr_privilege_violation(void); extern void __cs3_isr_trace(void); extern void __cs3_isr_unimplemented_line_a_opcode(void); extern void __cs3_isr_unimplemented_line_f_opcode(void); extern void __cs3_isr_non_pc_breakpoint_debug_interrupt(void); extern void __cs3_isr_pc_breakpoint_debug_interrupt(void); extern void __cs3_isr_format_error(void); extern void __cs3_isr_interrupt_15(void); extern void __cs3_isr_interrupt_16(void); extern void __cs3_isr_interrupt_17(void); extern void __cs3_isr_interrupt_18(void); extern void __cs3_isr_interrupt_19(void); extern void __cs3_isr_interrupt_20(void); extern void __cs3_isr_interrupt_21(void); extern void __cs3_isr_interrupt_22(void); extern void __cs3_isr_interrupt_23(void); extern void __cs3_isr_spurious_interrupt(void); extern void __cs3_isr_interrupt_25(void); extern void __cs3_isr_interrupt_26(void); extern void __cs3_isr_interrupt_27(void); extern void __cs3_isr_interrupt_28(void); extern void __cs3_isr_interrupt_29(void); extern void __cs3_isr_interrupt_30(void); extern void __cs3_isr_interrupt_31(void); extern void __cs3_isr_trap0(void); extern void __cs3_isr_trap1(void); extern void __cs3_isr_trap2(void); extern void __cs3_isr_trap3(void); extern void __cs3_isr_trap4(void); extern void __cs3_isr_trap5(void); extern void __cs3_isr_trap6(void); extern void __cs3_isr_trap7(void); extern void __cs3_isr_trap8(void); extern void __cs3_isr_trap9(void); extern void __cs3_isr_trap10(void); extern void __cs3_isr_trap11(void); extern void __cs3_isr_trap12(void); extern void __cs3_isr_trap13(void); extern void __cs3_isr_trap14(void); extern void __cs3_isr_trap15(void); extern void __cs3_isr_fp_branch_unordered(void); extern void __cs3_isr_fp_inexact_result(void); extern void __cs3_isr_fp_divide_by_zero(void); extern void __cs3_isr_fp_underflow(void); extern void __cs3_isr_fp_operand_error(void); extern void __cs3_isr_fp_overflow(void); extern void __cs3_isr_fp_input_not_a_number(void); extern void __cs3_isr_fp_input_denormalized_number(void); extern void __cs3_isr_interrupt_56(void); extern void __cs3_isr_interrupt_57(void); extern void __cs3_isr_interrupt_58(void); extern void __cs3_isr_interrupt_59(void); extern void __cs3_isr_interrupt_60(void); extern void __cs3_isr_unsupported_instruction(void); extern void __cs3_isr_interrupt_62(void); extern void __cs3_isr_interrupt_63(void); extern void __cs3_isr_interrupt_64(void); extern void __cs3_isr_interrupt_65(void); extern void __cs3_isr_interrupt_66(void); extern void __cs3_isr_interrupt_67(void); extern void __cs3_isr_interrupt_68(void); extern void __cs3_isr_interrupt_69(void); extern void __cs3_isr_interrupt_70(void); extern void __cs3_isr_interrupt_71(void); extern void __cs3_isr_interrupt_72(void); extern void __cs3_isr_interrupt_73(void); extern void __cs3_isr_interrupt_74(void); extern void __cs3_isr_interrupt_75(void); extern void __cs3_isr_interrupt_76(void); extern void __cs3_isr_interrupt_77(void); extern void __cs3_isr_interrupt_78(void); extern void __cs3_isr_interrupt_79(void); extern void __cs3_isr_interrupt_80(void); extern void __cs3_isr_interrupt_81(void); extern void __cs3_isr_interrupt_82(void); extern void __cs3_isr_interrupt_83(void); extern void __cs3_isr_interrupt_84(void); extern void __cs3_isr_interrupt_85(void); extern void __cs3_isr_interrupt_86(void); extern void __cs3_isr_interrupt_87(void); extern void __cs3_isr_interrupt_88(void); extern void __cs3_isr_interrupt_89(void); extern void __cs3_isr_interrupt_90(void); extern void __cs3_isr_interrupt_91(void); extern void __cs3_isr_interrupt_92(void); extern void __cs3_isr_interrupt_93(void); extern void __cs3_isr_interrupt_94(void); extern void __cs3_isr_interrupt_95(void); extern void __cs3_isr_interrupt_96(void); extern void __cs3_isr_interrupt_97(void); extern void __cs3_isr_interrupt_98(void); extern void __cs3_isr_interrupt_99(void); extern void __cs3_isr_interrupt_100(void); extern void __cs3_isr_interrupt_101(void); extern void __cs3_isr_interrupt_102(void); extern void __cs3_isr_interrupt_103(void); extern void __cs3_isr_interrupt_104(void); extern void __cs3_isr_interrupt_105(void); extern void __cs3_isr_interrupt_106(void); extern void __cs3_isr_interrupt_107(void); extern void __cs3_isr_interrupt_108(void); extern void __cs3_isr_interrupt_109(void); extern void __cs3_isr_interrupt_110(void); extern void __cs3_isr_interrupt_111(void); extern void __cs3_isr_interrupt_112(void); extern void __cs3_isr_interrupt_113(void); extern void __cs3_isr_interrupt_114(void); extern void __cs3_isr_interrupt_115(void); extern void __cs3_isr_interrupt_116(void); extern void __cs3_isr_interrupt_117(void); extern void __cs3_isr_interrupt_118(void); extern void __cs3_isr_interrupt_119(void); extern void __cs3_isr_interrupt_120(void); extern void __cs3_isr_interrupt_121(void); extern void __cs3_isr_interrupt_122(void); extern void __cs3_isr_interrupt_123(void); extern void __cs3_isr_interrupt_124(void); extern void __cs3_isr_interrupt_125(void); extern void __cs3_isr_interrupt_126(void); extern void __cs3_isr_interrupt_127(void); extern void __cs3_isr_interrupt_128(void); extern void __cs3_isr_interrupt_129(void); extern void __cs3_isr_interrupt_130(void); extern void __cs3_isr_interrupt_131(void); extern void __cs3_isr_interrupt_132(void); extern void __cs3_isr_interrupt_133(void); extern void __cs3_isr_interrupt_134(void); extern void __cs3_isr_interrupt_135(void); extern void __cs3_isr_interrupt_136(void); extern void __cs3_isr_interrupt_137(void); extern void __cs3_isr_interrupt_138(void); extern void __cs3_isr_interrupt_139(void); extern void __cs3_isr_interrupt_140(void); extern void __cs3_isr_interrupt_141(void); extern void __cs3_isr_interrupt_142(void); extern void __cs3_isr_interrupt_143(void); extern void __cs3_isr_interrupt_144(void); extern void __cs3_isr_interrupt_145(void); extern void __cs3_isr_interrupt_146(void); extern void __cs3_isr_interrupt_147(void); extern void __cs3_isr_interrupt_148(void); extern void __cs3_isr_interrupt_149(void); extern void __cs3_isr_interrupt_150(void); extern void __cs3_isr_interrupt_151(void); extern void __cs3_isr_interrupt_152(void); extern void __cs3_isr_interrupt_153(void); extern void __cs3_isr_interrupt_154(void); extern void __cs3_isr_interrupt_155(void); extern void __cs3_isr_interrupt_156(void); extern void __cs3_isr_interrupt_157(void); extern void __cs3_isr_interrupt_158(void); extern void __cs3_isr_interrupt_159(void); extern void __cs3_isr_interrupt_160(void); extern void __cs3_isr_interrupt_161(void); extern void __cs3_isr_interrupt_162(void); extern void __cs3_isr_interrupt_163(void); extern void __cs3_isr_interrupt_164(void); extern void __cs3_isr_interrupt_165(void); extern void __cs3_isr_interrupt_166(void); extern void __cs3_isr_interrupt_167(void); extern void __cs3_isr_interrupt_168(void); extern void __cs3_isr_interrupt_169(void); extern void __cs3_isr_interrupt_170(void); extern void __cs3_isr_interrupt_171(void); extern void __cs3_isr_interrupt_172(void); extern void __cs3_isr_interrupt_173(void); extern void __cs3_isr_interrupt_174(void); extern void __cs3_isr_interrupt_175(void); extern void __cs3_isr_interrupt_176(void); extern void __cs3_isr_interrupt_177(void); extern void __cs3_isr_interrupt_178(void); extern void __cs3_isr_interrupt_179(void); extern void __cs3_isr_interrupt_180(void); extern void __cs3_isr_interrupt_181(void); extern void __cs3_isr_interrupt_182(void); extern void __cs3_isr_interrupt_183(void); extern void __cs3_isr_interrupt_184(void); extern void __cs3_isr_interrupt_185(void); extern void __cs3_isr_interrupt_186(void); extern void __cs3_isr_interrupt_187(void); extern void __cs3_isr_interrupt_188(void); extern void __cs3_isr_interrupt_189(void); extern void __cs3_isr_interrupt_190(void); extern void __cs3_isr_interrupt_191(void); extern void __cs3_isr_interrupt_192(void); extern void __cs3_isr_interrupt_193(void); extern void __cs3_isr_interrupt_194(void); extern void __cs3_isr_interrupt_195(void); extern void __cs3_isr_interrupt_196(void); extern void __cs3_isr_interrupt_197(void); extern void __cs3_isr_interrupt_198(void); extern void __cs3_isr_interrupt_199(void); extern void __cs3_isr_interrupt_200(void); extern void __cs3_isr_interrupt_201(void); extern void __cs3_isr_interrupt_202(void); extern void __cs3_isr_interrupt_203(void); extern void __cs3_isr_interrupt_204(void); extern void __cs3_isr_interrupt_205(void); extern void __cs3_isr_interrupt_206(void); extern void __cs3_isr_interrupt_207(void); extern void __cs3_isr_interrupt_208(void); extern void __cs3_isr_interrupt_209(void); extern void __cs3_isr_interrupt_210(void); extern void __cs3_isr_interrupt_211(void); extern void __cs3_isr_interrupt_212(void); extern void __cs3_isr_interrupt_213(void); extern void __cs3_isr_interrupt_214(void); extern void __cs3_isr_interrupt_215(void); extern void __cs3_isr_interrupt_216(void); extern void __cs3_isr_interrupt_217(void); extern void __cs3_isr_interrupt_218(void); extern void __cs3_isr_interrupt_219(void); extern void __cs3_isr_interrupt_220(void); extern void __cs3_isr_interrupt_221(void); extern void __cs3_isr_interrupt_222(void); extern void __cs3_isr_interrupt_223(void); extern void __cs3_isr_interrupt_224(void); extern void __cs3_isr_interrupt_225(void); extern void __cs3_isr_interrupt_226(void); extern void __cs3_isr_interrupt_227(void); extern void __cs3_isr_interrupt_228(void); extern void __cs3_isr_interrupt_229(void); extern void __cs3_isr_interrupt_230(void); extern void __cs3_isr_interrupt_231(void); extern void __cs3_isr_interrupt_232(void); extern void __cs3_isr_interrupt_233(void); extern void __cs3_isr_interrupt_234(void); extern void __cs3_isr_interrupt_235(void); extern void __cs3_isr_interrupt_236(void); extern void __cs3_isr_interrupt_237(void); extern void __cs3_isr_interrupt_238(void); extern void __cs3_isr_interrupt_239(void); extern void __cs3_isr_interrupt_240(void); extern void __cs3_isr_interrupt_241(void); extern void __cs3_isr_interrupt_242(void); extern void __cs3_isr_interrupt_243(void); extern void __cs3_isr_interrupt_244(void); extern void __cs3_isr_interrupt_245(void); extern void __cs3_isr_interrupt_246(void); extern void __cs3_isr_interrupt_247(void); extern void __cs3_isr_interrupt_248(void); extern void __cs3_isr_interrupt_249(void); extern void __cs3_isr_interrupt_250(void); extern void __cs3_isr_interrupt_251(void); extern void __cs3_isr_interrupt_252(void); extern void __cs3_isr_interrupt_253(void); extern void __cs3_isr_interrupt_254(void); extern void __cs3_isr_interrupt_255(void); handler *__attribute__((section (".cs3.interrupt_vector"))) __cs3_interrupt_vector_coldfire[] = { __cs3_stack, __cs3_reset, __cs3_isr_access_error, __cs3_isr_address_error, __cs3_isr_illegal_instruction, __cs3_isr_divide_by_zero, __cs3_isr_interrupt_6, __cs3_isr_interrupt_7, __cs3_isr_privilege_violation, __cs3_isr_trace, __cs3_isr_unimplemented_line_a_opcode, __cs3_isr_unimplemented_line_f_opcode, __cs3_isr_non_pc_breakpoint_debug_interrupt, __cs3_isr_pc_breakpoint_debug_interrupt, __cs3_isr_format_error, __cs3_isr_interrupt_15, __cs3_isr_interrupt_16, __cs3_isr_interrupt_17, __cs3_isr_interrupt_18, __cs3_isr_interrupt_19, __cs3_isr_interrupt_20, __cs3_isr_interrupt_21, __cs3_isr_interrupt_22, __cs3_isr_interrupt_23, __cs3_isr_spurious_interrupt, __cs3_isr_interrupt_25, __cs3_isr_interrupt_26, __cs3_isr_interrupt_27, __cs3_isr_interrupt_28, __cs3_isr_interrupt_29, __cs3_isr_interrupt_30, __cs3_isr_interrupt_31, __cs3_isr_trap0, __cs3_isr_trap1, __cs3_isr_trap2, __cs3_isr_trap3, __cs3_isr_trap4, __cs3_isr_trap5, __cs3_isr_trap6, __cs3_isr_trap7, __cs3_isr_trap8, __cs3_isr_trap9, __cs3_isr_trap10, __cs3_isr_trap11, __cs3_isr_trap12, __cs3_isr_trap13, __cs3_isr_trap14, __cs3_isr_trap15, __cs3_isr_fp_branch_unordered, __cs3_isr_fp_inexact_result, __cs3_isr_fp_divide_by_zero, __cs3_isr_fp_underflow, __cs3_isr_fp_operand_error, __cs3_isr_fp_overflow, __cs3_isr_fp_input_not_a_number, __cs3_isr_fp_input_denormalized_number, __cs3_isr_interrupt_56, __cs3_isr_interrupt_57, __cs3_isr_interrupt_58, __cs3_isr_interrupt_59, __cs3_isr_interrupt_60, __cs3_isr_unsupported_instruction, __cs3_isr_interrupt_62, __cs3_isr_interrupt_63, __cs3_isr_interrupt_64, __cs3_isr_interrupt_65, __cs3_isr_interrupt_66, __cs3_isr_interrupt_67, __cs3_isr_interrupt_68, __cs3_isr_interrupt_69, __cs3_isr_interrupt_70, __cs3_isr_interrupt_71, __cs3_isr_interrupt_72, __cs3_isr_interrupt_73, __cs3_isr_interrupt_74, __cs3_isr_interrupt_75, __cs3_isr_interrupt_76, __cs3_isr_interrupt_77, __cs3_isr_interrupt_78, __cs3_isr_interrupt_79, __cs3_isr_interrupt_80, __cs3_isr_interrupt_81, __cs3_isr_interrupt_82, __cs3_isr_interrupt_83, __cs3_isr_interrupt_84, __cs3_isr_interrupt_85, __cs3_isr_interrupt_86, __cs3_isr_interrupt_87, __cs3_isr_interrupt_88, __cs3_isr_interrupt_89, __cs3_isr_interrupt_90, __cs3_isr_interrupt_91, __cs3_isr_interrupt_92, __cs3_isr_interrupt_93, __cs3_isr_interrupt_94, __cs3_isr_interrupt_95, __cs3_isr_interrupt_96, __cs3_isr_interrupt_97, __cs3_isr_interrupt_98, __cs3_isr_interrupt_99, __cs3_isr_interrupt_100, __cs3_isr_interrupt_101, __cs3_isr_interrupt_102, __cs3_isr_interrupt_103, __cs3_isr_interrupt_104, __cs3_isr_interrupt_105, __cs3_isr_interrupt_106, __cs3_isr_interrupt_107, __cs3_isr_interrupt_108, __cs3_isr_interrupt_109, __cs3_isr_interrupt_110, __cs3_isr_interrupt_111, __cs3_isr_interrupt_112, __cs3_isr_interrupt_113, __cs3_isr_interrupt_114, __cs3_isr_interrupt_115, __cs3_isr_interrupt_116, __cs3_isr_interrupt_117, __cs3_isr_interrupt_118, __cs3_isr_interrupt_119, __cs3_isr_interrupt_120, __cs3_isr_interrupt_121, __cs3_isr_interrupt_122, __cs3_isr_interrupt_123, __cs3_isr_interrupt_124, __cs3_isr_interrupt_125, __cs3_isr_interrupt_126, __cs3_isr_interrupt_127, __cs3_isr_interrupt_128, __cs3_isr_interrupt_129, __cs3_isr_interrupt_130, __cs3_isr_interrupt_131, __cs3_isr_interrupt_132, __cs3_isr_interrupt_133, __cs3_isr_interrupt_134, __cs3_isr_interrupt_135, __cs3_isr_interrupt_136, __cs3_isr_interrupt_137, __cs3_isr_interrupt_138, __cs3_isr_interrupt_139, __cs3_isr_interrupt_140, __cs3_isr_interrupt_141, __cs3_isr_interrupt_142, __cs3_isr_interrupt_143, __cs3_isr_interrupt_144, __cs3_isr_interrupt_145, __cs3_isr_interrupt_146, __cs3_isr_interrupt_147, __cs3_isr_interrupt_148, __cs3_isr_interrupt_149, __cs3_isr_interrupt_150, __cs3_isr_interrupt_151, __cs3_isr_interrupt_152, __cs3_isr_interrupt_153, __cs3_isr_interrupt_154, __cs3_isr_interrupt_155, __cs3_isr_interrupt_156, __cs3_isr_interrupt_157, __cs3_isr_interrupt_158, __cs3_isr_interrupt_159, __cs3_isr_interrupt_160, __cs3_isr_interrupt_161, __cs3_isr_interrupt_162, __cs3_isr_interrupt_163, __cs3_isr_interrupt_164, __cs3_isr_interrupt_165, __cs3_isr_interrupt_166, __cs3_isr_interrupt_167, __cs3_isr_interrupt_168, __cs3_isr_interrupt_169, __cs3_isr_interrupt_170, __cs3_isr_interrupt_171, __cs3_isr_interrupt_172, __cs3_isr_interrupt_173, __cs3_isr_interrupt_174, __cs3_isr_interrupt_175, __cs3_isr_interrupt_176, __cs3_isr_interrupt_177, __cs3_isr_interrupt_178, __cs3_isr_interrupt_179, __cs3_isr_interrupt_180, __cs3_isr_interrupt_181, __cs3_isr_interrupt_182, __cs3_isr_interrupt_183, __cs3_isr_interrupt_184, __cs3_isr_interrupt_185, __cs3_isr_interrupt_186, __cs3_isr_interrupt_187, __cs3_isr_interrupt_188, __cs3_isr_interrupt_189, __cs3_isr_interrupt_190, __cs3_isr_interrupt_191, __cs3_isr_interrupt_192, __cs3_isr_interrupt_193, __cs3_isr_interrupt_194, __cs3_isr_interrupt_195, __cs3_isr_interrupt_196, __cs3_isr_interrupt_197, __cs3_isr_interrupt_198, __cs3_isr_interrupt_199, __cs3_isr_interrupt_200, __cs3_isr_interrupt_201, __cs3_isr_interrupt_202, __cs3_isr_interrupt_203, __cs3_isr_interrupt_204, __cs3_isr_interrupt_205, __cs3_isr_interrupt_206, __cs3_isr_interrupt_207, __cs3_isr_interrupt_208, __cs3_isr_interrupt_209, __cs3_isr_interrupt_210, __cs3_isr_interrupt_211, __cs3_isr_interrupt_212, __cs3_isr_interrupt_213, __cs3_isr_interrupt_214, __cs3_isr_interrupt_215, __cs3_isr_interrupt_216, __cs3_isr_interrupt_217, __cs3_isr_interrupt_218, __cs3_isr_interrupt_219, __cs3_isr_interrupt_220, __cs3_isr_interrupt_221, __cs3_isr_interrupt_222, __cs3_isr_interrupt_223, __cs3_isr_interrupt_224, __cs3_isr_interrupt_225, __cs3_isr_interrupt_226, __cs3_isr_interrupt_227, __cs3_isr_interrupt_228, __cs3_isr_interrupt_229, __cs3_isr_interrupt_230, __cs3_isr_interrupt_231, __cs3_isr_interrupt_232, __cs3_isr_interrupt_233, __cs3_isr_interrupt_234, __cs3_isr_interrupt_235, __cs3_isr_interrupt_236, __cs3_isr_interrupt_237, __cs3_isr_interrupt_238, __cs3_isr_interrupt_239, __cs3_isr_interrupt_240, __cs3_isr_interrupt_241, __cs3_isr_interrupt_242, __cs3_isr_interrupt_243, __cs3_isr_interrupt_244, __cs3_isr_interrupt_245, __cs3_isr_interrupt_246, __cs3_isr_interrupt_247, __cs3_isr_interrupt_248, __cs3_isr_interrupt_249, __cs3_isr_interrupt_250, __cs3_isr_interrupt_251, __cs3_isr_interrupt_252, __cs3_isr_interrupt_253, __cs3_isr_interrupt_254, __cs3_isr_interrupt_255, 0x00000000, /* KEY_UPPER */ 0x00000000, /* KEY_LOWER */ 0x00000000, /* CFMPROT */ 0x00000000, /* CFMSACC */ 0x00000000, /* CFMDACC */ 0x00000000 /* CFMSEC */ }; From mark at codesourcery.com Sat Apr 19 00:07:39 2008 From: mark at codesourcery.com (Mark Mitchell) Date: Fri, 18 Apr 2008 17:07:39 -0700 Subject: [coldfire-gnu-discuss] CS3 Startup Process - Specifying A Different Vector Table In-Reply-To: References: Message-ID: <480937CB.8090200@codesourcery.com> Daniel McLean wrote: > However when I use the same vector file in a managed make project (eg. the > factorial example from the Getting Started Guide). I have no problems. The > difference I assume is because managed make uses gcc to build the elf file > from a collection of object files, and my problem is arising because I want > to use ld to link the files together, and some files are coming out of > archives? Yes, using ld to link directly is rather tricky. We always recommend that users use gcc to link, instead of ld, because gcc knows what options to pass for libraries and such. You can still pass options to the linker with "-Wl"; for example: gcc -Wl,-map,map.txt file.o -o program.exe passes along the "-map" option to the linker. Is there a reason that you need to use "ld"? > What am I doing wrong, and why is ld even looking for the vector table when > I've already got it defined? It's possible that something is requiring some symbol defined in coldfire-vector.o (from libcs3coldfire.a) and therefore the linker is pulling that in, even though you've already got a definition. You could probably see if that's the case by looking at the mapfile. (See options above.) Thanks, -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713