From maxim at codesourcery.com Mon Jan 5 18:25:40 2009 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Mon, 05 Jan 2009 10:25:40 -0800 Subject: [coldfire-gnu-discuss] problems when install coldfire m68k-elf.bin In-Reply-To: <38B2E349C3AA4B4CAEEBEBBFA35F541C5DE880@red.qustream.net> References: <38B2E349C3AA4B4CAEEBEBBFA35F541C5DE880@red.qustream.net> Message-ID: <496250A4.60500@codesourcery.com> Gaoyang Dou wrote: ... > > Stack Trace: > > java.awt.HeadlessException: > > No X11 DISPLAY variable was set, but this program performed an operation > which requires it. The graphical installer requires DISPLAY environment variable be set to appropriate value. If you do not have X11 connection to your host, you should get through using '-i console'. Let me know if that doesn't help. -- Maxim From tarmo.kuuse at proekspert.ee Thu Jan 8 12:48:02 2009 From: tarmo.kuuse at proekspert.ee (Tarmo Kuuse) Date: Thu, 08 Jan 2009 14:48:02 +0200 Subject: GDB and unresolved breakpoints (RedBoot, compiled under Cygwin) Message-ID: <4965F602.5030702@proekspert.ee> Hi! We are developing RedBoot (boot loader for eCos) for MCF5208 using the Windows personal edition of 4.3-79 ELF toolchain. eCos requires a Unix build environment, so we build it under Cygwin. The build works and the resulting RedBoot runs just fine. The problem is debugging RedBoot in Eclipse. It seems like GDB fails to understand absolute source file locations provided in ".debug" section. For example: eCos source tree contains 3 different files named "eth_drv.c" in different directories. When setting a breakpoint, Eclipse displays a small yellow exclamation mark and message "Unresolved breakpoint". When stepping, display suddenly jumps from the correct file to the first instance of "eth_drv.c" it finds in the directory tree. It is not the file that was compiled. After that, stepping kind of goes haywire. I don't understand why this is happening. GDB should know exactly which source file was used. ELF object's debug section contains the correct absolute file location. I checked that using the dwarfdump tool. The absolute path is in unix format (because it's built in cygwin) "/ecos-c/foo/bar.c". Could this be the culprit? Compiler and linker get options "-ggdb" and "-O0". These are full compiler options: -mcpu=5208 -fno-use-cxa-atexit -isystem /ecos-c/Tools/CodeSourcery/SourceryG++/lib/gcc/m68k-elf/4.3.2/include/ -isystem /ecos-c/Tools/CodeSourcery/SourceryG++/lib/gcc/m68k-elf/4.3.2/include-fixed/ -malign-int -Wall -Wpointer-arith -Winline -Wundef -Woverloaded-virtual -ggdb -O0 -fno-rtti -fno-exceptions I have uploaded a file which contains dwarfdump output for the module in question: http://www.hot.ee/tarmospam/dwarfdump_redboot_eth_drv.txt I am used to working on targets without debugger support. It's OK when there is no hope. However, it is quite annoying to come so close to a proper debug environment and then stumble over something this small. -- Kind regards, Tarmo Kuuse Proekspert AS tarmo.kuuse at proekspert.ee From tarmo.kuuse at proekspert.ee Tue Jan 13 14:00:24 2009 From: tarmo.kuuse at proekspert.ee (Tarmo Kuuse) Date: Tue, 13 Jan 2009 16:00:24 +0200 Subject: [coldfire-gnu-discuss] GDB and unresolved breakpoints (RedBoot, compiled under Cygwin) In-Reply-To: <4965F602.5030702@proekspert.ee> References: <4965F602.5030702@proekspert.ee> Message-ID: <496C9E78.8070301@proekspert.ee> Tarmo Kuuse wrote: > We are developing RedBoot (boot loader for eCos) for MCF5208 using the > Windows personal edition of 4.3-79 ELF toolchain. eCos requires a Unix > build environment, so we build it under Cygwin. The build works and the > resulting RedBoot runs just fine. /** TODO: in future, when hearing eCos and Windows in one sentence, run like hell. Update 2009-01-13: don't stop for anything */ > The absolute path is in unix format (because it's built in cygwin) > "/ecos-c/foo/bar.c". Could this be the culprit? Okay, problem solved. I forgot to add CYGPATH to Windows environment variables. Kudos to Codesourcery guys for the hint. By the way - it's not quite plug and play. When debugging for the first time, Eclipse complains: [quote begins] Can't find a source file at "c:\ecos-c\projects\...[snip]...\vectors.S" Locate the file or edit the source lookup path to include its location. [quote ends] The "\ecos-c" should have vanished when cygpath converted path to windows format. In my case is still there and breaks the path. Pressing the button "Locate File" and browsing to the source automatically adds a path mapping from "c:\ecos-c" to "c:\" which heals the defective path. I can proceed with actual debugging. -- Kind regards, Tarmo Kuuse Proekspert AS tarmo.kuuse at proekspert.ee From dan at codesourcery.com Tue Jan 13 14:15:43 2009 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Tue, 13 Jan 2009 09:15:43 -0500 Subject: [coldfire-gnu-discuss] GDB and unresolved breakpoints (RedBoot, compiled under Cygwin) In-Reply-To: <496C9E78.8070301@proekspert.ee> References: <4965F602.5030702@proekspert.ee> <496C9E78.8070301@proekspert.ee> Message-ID: <20090113141543.GJ26210@caradoc.them.org> On Tue, Jan 13, 2009 at 04:00:24PM +0200, Tarmo Kuuse wrote: > By the way - it's not quite plug and play. When debugging for the first > time, Eclipse complains: > > [quote begins] > Can't find a source file at "c:\ecos-c\projects\...[snip]...\vectors.S" > Locate the file or edit the source lookup path to include its location. > [quote ends] > > The "\ecos-c" should have vanished when cygpath converted path to windows > format. In my case is still there and breaks the path. So there's no c:\ecos-c\ directory? Does "$CYGPATH -w /ecos-c/projects/.../vectors.S" print what you'd expect? None of the path manipulation is in SG++; we delegate it all to Cygwin. -- Daniel Jacobowitz CodeSourcery From RobertoAbbiati at bertronic.it Wed Jan 14 13:38:12 2009 From: RobertoAbbiati at bertronic.it (Roberto Abbiati) Date: Wed, 14 Jan 2009 14:38:12 +0100 Subject: Coldfire 52235evb debug problem Message-ID: Hi, I'm using eclipse and Sourcery G++ Lite Edition with a coldfire EVM. I have used the FREERTOS code (Coldfire V2 RTOS and TCP/IP Demo). I can build the project and download the program in flash memory using freescale's "CF Flasher 3.1". Problems arise when I try to debug the code. To identify the problem, I have used the command prompt console and text commands. The steps are: 1/ m68k-elf-gdb RTOSDemo.elf RESPONSE: GNU gdb (Sourcery G++ Lite 4.3-54) 6.8.50.20080821-cvs Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=i686-mingw32 --target=m68k-elf". For bug reporting instructions, please see: ... 2/ (gdb) target remote | m68k-elf-sprite pe://USBMultilink m52235evb RESPONSE: Remote debugging using | m68k-elf-sprite pe://USBMultilink m52235evb m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF : Future MCF5223xPoE Badge (PE6011471)) m68k-elf-sprite: Target reset 0x00000000 in __cs3_interrupt_vector_coldfire () 3/ (gdb) c Continuing. RESPONSE: Program received signal SIGTRAP, Trace/breakpoint trap. 0x0000000a in __cs3_interrupt_vector_coldfire () If I try to continue, I always obtain this kind of response. Instead, if I try the step command: (gdb) step RESPONSE: Single stepping until exit from function __cs3_interrupt_vector_coldfire, which has no line number information. and the program waits forever, so I must close the command prompt shell. Could anyone help me? Thanks Roberto -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at codesourcery.com Wed Jan 14 20:44:19 2009 From: kazu at codesourcery.com (Kazu Hirata) Date: Wed, 14 Jan 2009 15:44:19 -0500 Subject: [coldfire-gnu-discuss] Coldfire 52235evb debug problem In-Reply-To: References: Message-ID: <496E4EA3.7050106@codesourcery.com> Hi Roberto, > I'm using eclipse and Sourcery G++ Lite Edition with a coldfire EVM. I > have used the FREERTOS code (Coldfire V2 RTOS and TCP/IP Demo). > I can build the project and download the program in flash memory using > freescale's "CF Flasher 3.1". > Problems arise when I try to debug the code. > To identify the problem, I have used the command prompt console and text > commands. The steps are: Before you hit "c", could you make sure if pc is set correctly with "p pc"? If you need to update it, you can say "set pc=0xNNNNNNNN". If I remember correctly, "target remote ..." doesn't set pc for you. You would have to do that manually. Hope this helps, Kazu Hirata From braun at stzedn.de Thu Jan 15 07:00:40 2009 From: braun at stzedn.de (Nathan Braun) Date: Thu, 15 Jan 2009 08:00:40 +0100 Subject: [coldfire-gnu-discuss] Coldfire 52235evb debug problem In-Reply-To: References: Message-ID: <496EDF18.3040809@stzedn.de> Hi Roberto, I use: set $pc = _start continue @0x0000 there is the start address of the program and not the first instruction on the ColdFire. Please consider also the remarks in http://www.codesourcery.com/archives/coldfire-gnu-discuss/msg00559.html which addresses some issues when debugging from Flash. Maybe your linker script links OK. The symbol _start must not point to 0x400 since the ColdFire expects memory access bit masks there. Otherwise later the program will run into memory access exceptions. Best regards Nathan Braun Roberto Abbiati schrieb: > Hi, > I'm using eclipse and Sourcery G++ Lite Edition with a coldfire EVM. I > have used the FREERTOS code (Coldfire V2 RTOS and TCP/IP Demo). > I can build the project and download the program in flash memory using > freescale's "CF Flasher 3.1". > Problems arise when I try to debug the code. > To identify the problem, I have used the command prompt console and text > commands. The steps are: > 1/ m68k-elf-gdb RTOSDemo.elf > RESPONSE: > GNU gdb (Sourcery G++ Lite 4.3-54) 6.8.50.20080821-cvs > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "--host=i686-mingw32 --target=m68k-elf". > For bug reporting instructions, please see: > ... > > > > 2/ (gdb) target remote | m68k-elf-sprite pe://USBMultilink m52235evb > RESPONSE: > Remote debugging using | m68k-elf-sprite pe://USBMultilink m52235evb > m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF : > Future > MCF5223xPoE Badge (PE6011471)) > m68k-elf-sprite: Target reset > 0x00000000 in __cs3_interrupt_vector_coldfire () > > 3/ (gdb) c > Continuing. > RESPONSE: > Program received signal SIGTRAP, Trace/breakpoint trap. > 0x0000000a in __cs3_interrupt_vector_coldfire () > > If I try to continue, I always obtain this kind of response. > > Instead, if I try the step command: > > (gdb) step > RESPONSE: > Single stepping until exit from function __cs3_interrupt_vector_coldfire, > which has no line number information. > and the program waits forever, so I must close the command prompt shell. > > Could anyone help me? > Thanks > > Roberto -- Dipl. Ing. (FH) Nathan Braun Tel: +49 7634 6949341 Fax: +49 7634 5049886 Mob: +49 178 7935705 Steinbeis-Transferzentrum Embedded Design und Networking an der Berufsakademie L?rrach Poststra?e 35, 79423 Heitersheim Leiter: Prof. Dr.-Ing. Axel Sikora Fon: +49 -7634-6949-340 Fax: +49 -7634-5049-886 Mail: info at stzedn.de Zentrale: Steinbeis GmbH & Co. KG f?r Technologietransfer Willi-Bleicher-Stra?e 19, 70174 Stuttgart Registergericht Stuttgart HRA 12 480 Komplement?r: Steinbeis-Verwaltung-GmbH, Registergericht Stuttgart HRB 18715 Gesch?ftsf?hrer: Prof. Dr. Heinz Trasch, Prof. Dr. Michael Auer Der Inhalt dieser E-Mail einschlie?lich aller Anh?nge ist vertraulich und ausschlie?lich f?r den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Ver?ffentlichung, Vervielf?ltigung oder Weitergabe des Inhalts dieser E-Mail unzul?ssig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen, sowie die Originalnachricht zu l?schen und alle Kopien hiervon zu vernichten. This e-mail message including any attachments is for the sole use of the intended recipient(s) and may contain privileged or confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply e-mail and delete the original message and destroy all copies thereof. From RobertoAbbiati at bertronic.it Thu Jan 15 11:01:13 2009 From: RobertoAbbiati at bertronic.it (Roberto Abbiati) Date: Thu, 15 Jan 2009 12:01:13 +0100 Subject: R: [coldfire-gnu-discuss] Coldfire 52235evb debug problem In-Reply-To: <496E2E4D.1060602@sciopta.com> Message-ID: Thank you for your help, now it works from dos prompt. I can debug the code also from eclipse (but only if I write the "continue" command manually in the console, if I use the "continue" command directly from the "run commands" in "debug configurations" eclipse freezes and I must terminate it...) Roberto Abbiati -----Messaggio originale----- Da: 42Bastian [mailto:list-bastian.schick at sciopta.com] Inviato: mercoled? 14 gennaio 2009 19.26 A: Roberto Abbiati Oggetto: Re: [coldfire-gnu-discuss] Coldfire 52235evb debug problem Roberto > 2/ (gdb) target remote | m68k-elf-sprite pe://USBMultilink m52235evb > RESPONSE: > Remote debugging using | m68k-elf-sprite pe://USBMultilink m52235evb > m68k-elf-sprite: Opening P&E USBMultilink port 1 (USB1 : USB-ML-CF REF : > Future > MCF5223xPoE Badge (PE6011471)) > m68k-elf-sprite: Target reset > 0x00000000 in __cs3_interrupt_vector_coldfire () I'd say you have a setup problem. Address 0 contains the reset-SP and 0x4 the entry point. Try setting the PC manually to the value of _start (obtained from the map file). -- 42Bastian From Pablo.Martinez-Crespo at iba-group.com Fri Jan 16 10:34:26 2009 From: Pablo.Martinez-Crespo at iba-group.com (Pablo Martinez-Crespo) Date: Fri, 16 Jan 2009 11:34:26 +0100 Subject: Error in makefile on Sourcery G++ for coldfire Message-ID: <892BC9A3C8D93D4FA9A502F8A6452AE33ADCAC@llnexc01.lln.iba> Hello *, I'm trying to compile my first "Hello World" project using Eclipse and the Codesourcery tool chain. I have configured and installed everything but I get this error when try to compile: ***multiple target patterns. Stop. Here is the code of the makefile and the line where the error comes: ######################################################################## ###################### # Start of user section # # Define project name here PROJECT = helloFirst PROJ_DIR = "D:/Tools/HelloFirst" # Define linker script file here LDSCRIPT = "C:/Program Files/CodeSourcery/Sourcery G++/m68k-elf/lib/m5475/m5485evb-ram.ld" # List all user C define here, like -D_DEBUG=1 UDEFS = # Define ASM defines here UADEFS = # List C source files here SRC = $(PROJ_DIR)/src/hello.c # List ASM source files here #ASRC = # List all user directories here UINCDIR = $(PROJ_DIR)/. \ $(PROJ_DIR)/src \ $(PROJ_DIR)/inc # List the user directory to look for the libraries here ULIBDIR = "C:/cygwin/lib" # List all user libraries here ULIBS = "C:/cygwin/usr/lib" #ULIBS = -lm # Define optimisation level here OPT = -O0 # # End of user defines ######################################################################## ###################### OBJDIR = .obj INCDIR = $(patsubst %,-I%,$(DINCDIR) $(UINCDIR)) LIBDIR = $(patsubst %,-L%,$(DLIBDIR) $(ULIBDIR)) DEFS = $(DDEFS) $(UDEFS) ADEFS = $(DADEFS) $(UADEFS) OBJS = $(patsubst $(PROJ_DIR)/%, $(PROJ_DIR)/$(OBJDIR)/%, $(ASRC:.s=.o) $(SRC:.c=.o)) LIBS = $(DLIBS) $(ULIBS) INCDIR += -I"C:/Program Files/CodeSourcery/Sourcery G++ Lite/lib/gcc/m68k-elf/4.2.3/include" \ -I"C:/Program Files/CodeSourcery/Sourcery G++ Lite/m68k-elf/include" \ -I"C:/Program Files/CodeSourcery/Sourcery G++ Lite/m68k-elf/include/sys" \ -I"C:/Program Files/CodeSourcery/Sourcery G++ Lite/m68k-elf/include/machine" \ -I"C:/Program Files/CodeSourcery/Sourcery G++ Lite/lib/gcc/m68k-elf/4.2.3/install-tools/include" MCFLAGS = -mcpu=548x ASFLAGS = $(MCFLAGS) -g -Wa,--register-prefix-optional,-amhls=$(@:.o=.lst) $(ADEFS) CPFLAGS = $(MCFLAGS) $(OPT) -g -fomit-frame-pointer \ -fno-builtin -ffreestanding -nostdinc \ -Wall -Wstrict-prototypes -fverbose-asm \ -Wa,-ahlms=$(@:.o=.lst) $(DEFS) LDFLAGS = $(MCFLAGS) -T$(LDSCRIPT) \ -fno-builtin -ffreestanding -nostdinc \ -Wl,-Map=$(PROJECT).map,--cref,--no-warn-mismatch $(LIBDIR) # Generate dependency information CPFLAGS += -MD -MP -MF .dep/$(@F).d # # makefile rules # .SECONDEXPANSION: all: $(OBJS) $(PROJECT).elf $(PROJECT).bin # <--------Error comes here-------< $(OBJDIR)/%o : %c | $$(@D)/.tmp $(CC) -c $(CPFLAGS) -I . $(INCDIR) $< -o $@ $(OBJDIR)/%.o : %.s | $$(@D)/.tmp $(AS) -c $(ASFLAGS) $< -o $@ %elf: $(OBJS) $(CC) $(OBJS) $(LDFLAGS) $(LIBS) -o $@ %bin: %elf $(BIN) $< $@ %/.tmp: -mkdir $(subst /,\,$*) -touch $@ .PRECIOUS: %/.tmp Can some one help me with this topic, I don't have any experience with makefile, I looked already the documentation on the GNU website and many forums but couldn't find any solution. Many thanks in advance Pablo The contents of this e-mail message and any attachments are intended solely for the recipient (s) named above. This communication is intended to be and to remain confidential and may be protected by intellectual property rights. Any use of the information contained herein (including but not limited to, total or partial reproduction, communication or distribution of any form) by persons other than the designated recipient(s) is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free. Ion Beam Applications does not accept liability for any such errors. Thank you for your cooperation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tarmo.kuuse at proekspert.ee Fri Jan 16 18:32:08 2009 From: tarmo.kuuse at proekspert.ee (Tarmo Kuuse) Date: Fri, 16 Jan 2009 20:32:08 +0200 Subject: [coldfire-gnu-discuss] Error in makefile on Sourcery G++ for coldfire In-Reply-To: <892BC9A3C8D93D4FA9A502F8A6452AE33ADCAC@llnexc01.lln.iba> References: <892BC9A3C8D93D4FA9A502F8A6452AE33ADCAC@llnexc01.lln.iba> Message-ID: <4970D2A8.4080406@proekspert.ee> Hi Pablo, Pablo Martinez-Crespo wrote: > I'm trying to compile my first "Hello World" project using Eclipse and > the Codesourcery tool chain. I have configured and installed everything > but I get this error when try to compile: > > ***multiple target patterns. Stop. The error occurs because you are using windows drive letters (C: and D:). For example: PROJ_DIR = "D:/Tools/HelloFirst" LDSCRIPT = "C:/Program Files/CodeSourcery/Sourcery G++/m68k-elf/lib/m5475/m5485evb-ram.ld" There were many others scattered around your Makefile. Make is a unix tool. It treats the colon ':' as a special character. You are not allowed to use the colon anywhere else - not in file names nor command arguments. Replace all drive letters with their Cygwin mount points. Usually "C:" corresponds to "/cygdrive/c", "D:" is "/cygdrive/d" etc. You can get a full list using command "mount -l". -- Kind regards, Tarmo Kuuse From dan at codesourcery.com Fri Jan 16 19:30:33 2009 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Fri, 16 Jan 2009 14:30:33 -0500 Subject: [coldfire-gnu-discuss] Error in makefile on Sourcery G++ for coldfire In-Reply-To: <4970D2A8.4080406@proekspert.ee> References: <892BC9A3C8D93D4FA9A502F8A6452AE33ADCAC@llnexc01.lln.iba> <4970D2A8.4080406@proekspert.ee> Message-ID: <20090116193032.GC15740@caradoc.them.org> On Fri, Jan 16, 2009 at 08:32:08PM +0200, Tarmo Kuuse wrote: > Hi Pablo, > > Pablo Martinez-Crespo wrote: >> I'm trying to compile my first "Hello World" project using Eclipse and >> the Codesourcery tool chain. I have configured and installed everything >> but I get this error when try to compile: Are you using a managed make project, or trying to write the Makefile by hand? Managed make is much easier. > The error occurs because you are using windows drive letters (C: and D:). > For example: > > PROJ_DIR = "D:/Tools/HelloFirst" > LDSCRIPT = "C:/Program Files/CodeSourcery/Sourcery > G++/m68k-elf/lib/m5475/m5485evb-ram.ld" > > There were many others scattered around your Makefile. > > Make is a unix tool. It treats the colon ':' as a special character. You > are not allowed to use the colon anywhere else - not in file names nor > command arguments. > > Replace all drive letters with their Cygwin mount points. Usually "C:" > corresponds to "/cygdrive/c", "D:" is "/cygdrive/d" etc. You can get a > full list using command "mount -l". The version of Make we ship with Sourcery G++ understands drive letters, not Cygwin paths. -- Daniel Jacobowitz CodeSourcery From tarmo.kuuse at proekspert.ee Mon Jan 19 08:25:18 2009 From: tarmo.kuuse at proekspert.ee (Tarmo Kuuse) Date: Mon, 19 Jan 2009 10:25:18 +0200 Subject: [coldfire-gnu-discuss] Error in makefile on Sourcery G++ for coldfire In-Reply-To: <20090116193032.GC15740@caradoc.them.org> References: <892BC9A3C8D93D4FA9A502F8A6452AE33ADCAC@llnexc01.lln.iba> <4970D2A8.4080406@proekspert.ee> <20090116193032.GC15740@caradoc.them.org> Message-ID: <497438EE.2030303@proekspert.ee> Hi! I saw the exact same problem as OP when building eCos. The "make" included with cygwin chokes on windows paths (those seem to come from Sourcery G++ when it is interrogated for system includes). We use a (rather ugly) workaround to get unix-only paths. Daniel Jacobowitz wrote: > On Fri, Jan 16, 2009 at 08:32:08PM +0200, Tarmo Kuuse wrote: >> Pablo Martinez-Crespo wrote: [snip] >> The error occurs because you are using windows drive letters (C: and D:). > The version of Make we ship with Sourcery G++ understands drive > letters, not Cygwin paths. That's news for me. Pablo, you might want to ignore my previous advice. Try using "cs-make" instead of "make" for building your project. [offtopic] Does cs-make also understand Cygwin paths? When I try, an "include /ecos-c/.../rules.mak" statement found in a makefile results in error "No such file or directory". -- Kind regards, Tarmo Kuuse From dan at codesourcery.com Mon Jan 19 14:43:43 2009 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Mon, 19 Jan 2009 09:43:43 -0500 Subject: [coldfire-gnu-discuss] Error in makefile on Sourcery G++ for coldfire In-Reply-To: <497438EE.2030303@proekspert.ee> References: <892BC9A3C8D93D4FA9A502F8A6452AE33ADCAC@llnexc01.lln.iba> <4970D2A8.4080406@proekspert.ee> <20090116193032.GC15740@caradoc.them.org> <497438EE.2030303@proekspert.ee> Message-ID: <20090119144342.GN15740@caradoc.them.org> On Mon, Jan 19, 2009 at 10:25:18AM +0200, Tarmo Kuuse wrote: > [offtopic] > > Does cs-make also understand Cygwin paths? When I try, an > "include /ecos-c/.../rules.mak" > statement found in a makefile results in error > "No such file or directory". No, I don't think it does. It's provided primarily for the use of our IDE, which generates Windows paths on Windows (and Unix paths on Linux hosts, obviously). -- Daniel Jacobowitz CodeSourcery From mark at codesourcery.com Mon Jan 19 16:45:37 2009 From: mark at codesourcery.com (Mark Mitchell) Date: Mon, 19 Jan 2009 08:45:37 -0800 Subject: [coldfire-gnu-discuss] Error in makefile on Sourcery G++ for coldfire In-Reply-To: <20090119144342.GN15740@caradoc.them.org> References: <892BC9A3C8D93D4FA9A502F8A6452AE33ADCAC@llnexc01.lln.iba> <4970D2A8.4080406@proekspert.ee> <20090116193032.GC15740@caradoc.them.org> <497438EE.2030303@proekspert.ee> <20090119144342.GN15740@caradoc.them.org> Message-ID: <4974AE31.4060302@codesourcery.com> Daniel Jacobowitz wrote: > On Mon, Jan 19, 2009 at 10:25:18AM +0200, Tarmo Kuuse wrote: >> [offtopic] >> >> Does cs-make also understand Cygwin paths? When I try, an >> "include /ecos-c/.../rules.mak" >> statement found in a makefile results in error >> "No such file or directory". > > No, I don't think it does. For eCos, I suspect you'll be better off using Cygwin make, and appropriate uses of "cygpath -u" and "cygpath -w" as necessary to convert Windows paths to/from Cygwin paths. -- Mark Mitchell CodeSourcery mark at codesourcery.com (650) 331-3385 x713 From tarmo.kuuse at proekspert.ee Tue Jan 20 14:51:40 2009 From: tarmo.kuuse at proekspert.ee (Tarmo Kuuse) Date: Tue, 20 Jan 2009 16:51:40 +0200 Subject: [coldfire-gnu-discuss] Error in makefile on Sourcery G++ for coldfire In-Reply-To: <4974AE31.4060302@codesourcery.com> References: <892BC9A3C8D93D4FA9A502F8A6452AE33ADCAC@llnexc01.lln.iba> <4970D2A8.4080406@proekspert.ee> <20090116193032.GC15740@caradoc.them.org> <497438EE.2030303@proekspert.ee> <20090119144342.GN15740@caradoc.them.org> <4974AE31.4060302@codesourcery.com> Message-ID: <4975E4FC.6030106@proekspert.ee> Hi, Mark Mitchell wrote: >>> Does cs-make also understand Cygwin paths? When I try, an >>> "include /ecos-c/.../rules.mak" >>> statement found in a makefile results in error >>> "No such file or directory". >> No, I don't think it does. Ok. I wasn't expecting that either. Thank you for the replies. > For eCos, I suspect you'll be better off using Cygwin make, I already do. Everything is Unix-style to satisfy cygwin's make (it takes some hacking to ensure that). Path conversion is done by your gcc and this works flawlessly (except when debugging inside Eclipse). I was simply curious about potential alternatives. > and appropriate uses of "cygpath -u" and "cygpath -w" as necessary to > convert Windows paths to/from Cygwin paths. eCos's makefiles are unmodifiable. They are generated inside an unpenetrable fortress of spaghetti scripts. -- Kind regards, Tarmo Kuuse From jsujjavanich at syntech-fuelmaster.com Thu Jan 29 23:34:01 2009 From: jsujjavanich at syntech-fuelmaster.com (Jate Sujjavanich) Date: Thu, 29 Jan 2009 18:34:01 -0500 Subject: Compiled shared uClibc with another shared lib Message-ID: I am attempting to generate a shared library using a custom compiled uClibc. I extracted the uClibc source from the CodeSourcery 4.2-153 archive, and I was able to compile using a config file from the build script. m68k-uclinux-gcc -nostdlib -mid-shared-library -mshared-library-id=3 -o lib3.so \ $(ROOTDIR)/uClibc/lib/Scrt1.o $(ROOTDIR)/uClibc/lib/crti.o \ -Wl,--whole-archive ${OBJECTS} -Wl,--no-whole-archive \ -Wl,-R,$(ROOTDIR)/uClibc/lib/libc.gdb \ -lpthread -lgcc $(ROOTDIR)/uClibc/lib/crtn.o The linker errors out with the following: ...uClibc/lib/Scrt1.o: In function `lib_main': (.text+0x8): undefined reference to `__shared_flat_add_library' Collect2: ld returned 1 exit status The linker doesn't seem to know about the information from libc.gdb. The previous way I've linked is with the builtin shared libc. That method is successful. - Jate S. From dave at meadorresearch.com Fri Jan 30 23:32:56 2009 From: dave at meadorresearch.com (Dave Meador) Date: Fri, 30 Jan 2009 15:32:56 -0800 Subject: Coldfire application/compiler problem Message-ID: <49838E28.5080809@meadorresearch.com> Hello, I have a c++ application using Freescale 547x_548x 2007 BSP which compiles runs using compiler version: g++ version 4.1.1 (CodeSourcery Sourcery G++ 4.1-30). However, I needed to upgrade to the latest Freescale 2008 BSP fix corruptions which were caused by a flaw in the CPU cache handling of the kernel -- the release notes claim this issue is fixed in the latest 2008 BSP. My application (same exact code) now crashes with a strange problem when compiled with the 2008 BSP compiler: g++ version 4.2.3 (Sourcery G++ Lite 4.2-125) I also tried upgrading to the latest CodeSourcery compiler: gcc version 4.3.2 (Sourcery G++ Lite 4.3-43) - but I get the same crash behaviour as the Lite-4.2-125 version. The problem I am getting is my application starts up and runs, but then it crashes as soon as it calls "new" to allocate a specific class. No constructor code is executed before the crash. I have tried the following to determine where the crash could be happening, but it appears as though the breakage is in the code executed just prior to calling the constructor (sorry I don't know the compiler terminology here): * Tried logging first line inside the constructor - no logs are executed, but crashes after the call to "new" * Tried eliminating the body code of the constructor, no help * Tried calling "new"/"delete" with sizeof(MyClass) just prior to the real alloc and the test alloc/delete completes fine, but crashes upon calling the alloc of "MyClass". * Tried moving the alloc MyClass call to various other places in the code, it crashes upon the first call every time. Does anyone have any ideas what this could be and how I might go about figuring this out? Any help would be greatly appreciated, Dave