From jhurstel at markem-imaje.com Thu Mar 4 09:44:04 2010 From: jhurstel at markem-imaje.com (JEROME HURSTEL) Date: Thu, 4 Mar 2010 10:44:04 +0100 Subject: How to get rid of "Template with C linkage" error when compiling with -isystem flag ? Message-ID: Hi, I currently work on an eCos-based application with Code Sourcery 4.1. I have put -isystem option flag of the m68k-g++ compiler on eCos include paths not to be polluted by those specific warnings. And I got lots of "Template with C linkage" errors !!! This behaviour seems to be as expected. The compiler user's guide says : On very old systems, some of the pre-defined system header directories get even more special treatment. GNU C++ considers code in headers found in those directories to be surrounded by an extern "C" block. There is no way to request this behavior with a '#pragma', or from the command line. Is there a way to inhibit this behaviour ? Best regards, J?r?me Hurstel -------------------------------------------------------------------------- This e-mail, including any attachments, is transmitted for the sole use of the intended recipient and may contain information that may be privileged and confidential. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution or copying of this e-mail or the information contained herein is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender by reply e-mail and then delete the original message from your system. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company.This is your responsibility to ensure this-e-mail and any attachments are virus free. The company accepts no liability for any damage caused by any virus transmitted by this e-mail. Markem-Imaje S.A.S. 9, rue Gaspard Monge F - 26500 Bourg-l?s-Valence S.A.S. au capital de 22 000 000 euros 353 282 106 RCS Romans -------------- next part -------------- An HTML attachment was scrubbed... URL: From sreejad at cdactvm.in Fri Mar 5 06:30:19 2010 From: sreejad at cdactvm.in (Sreeja D) Date: Fri, 5 Mar 2010 12:00:19 +0530 Subject: Config_Preempt_rt on Freescale MCF5485 Message-ID: <006601cabc2d$53bd8540$261810ac@CIG1083> Is there Config_Preempt_rt patch support for linux 2.6.25 on Freescale MCF5485 board. ______________________________________ Scanned and protected by Email scanner -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrharryg at gmail.com Tue Mar 9 06:11:41 2010 From: mrharryg at gmail.com (Harry Gunnarsson) Date: Mon, 8 Mar 2010 22:11:41 -0800 Subject: uClinux & ColdFire pthread debugging using CodeSourcery 4.4-53 Message-ID: <5c75fa9d1003082211w4da007cfi5e93f65a0be3ce4d@mail.gmail.com> Hello, I am using the CodeSourcery toolchain for a ColdFire 5272 board, and I am interested in getting gdbserver working with pthread built apps. At risk of providing a too lengthy explanation to a problem I am seeing, I'll be deliberately very brief and if discussion occurs I am happy to provide more details. This board used to run the following - uClinux build based on the uclinux.org provided 2007 distribution (kernel 2.6.22) - Essentially provided Freescale M5272C3 configuration + customizations. - CodeSourcery 4.2-153 - App using pthreads and debugging using gdb/gdbserver from CodeSourcery worked fine (or at least with minor problems) Target: $ gdbserver :5000 ./theapp Host: $ gdb theapp.gdb $ ...target remote etc.... Now I am trying to get the latest uclinux.org distro from 2009 running (kernel 2.6.[29-31]). The main reason is to look into improvements (kernel, busybox etc) in general (stability) and JFFS2 enhancements in general. - uClinux 2009 distro - CodeSourcery 4.4-53 My port seems to work well in all aspects except for debugging multi-thread user apps. I have tried many permutations of target build flags (-mcpu, -m etc), and according to CS website it seems recommended to -m5208 runtime with M5272 ColdFire. Therefore, I have lately tried '-mcpu=5272' for .c sources and '-m5208' during link. But I cannot get it to work. Typically I see any of the following problems - gdbserver saying upon 'target remote...' comand from GDB 'gdbserver: error initializing thread_db library: version mismatch between libthread_db and libpthread' And debugging goes belly up when stepping over pthread_create calls - gdbserver 'unattaches' from the app upon 'target remote...' comand from GDB and let the app continue unhindered. GDB on host notices socket closed. - Any other kind of complaint from gdbserver.... And the bizarre thing is that using that I see the same kinds of problems when using - CodeSourcery 4.4, 4.3 or 4.2 - New kernel That's strange, I think. Do I need to enable something on the kernel side??? The only combination that I got to work somewhat satisfactory is the uclinux 2007+CS4.2 I even tried to build my own gdb/gdbserver from source, version 7.0.1, but then I saw even more bizzare problems I would appreciate any piece of advice... Thanks in advance Harry -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim at codesourcery.com Wed Mar 10 10:04:31 2010 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Wed, 10 Mar 2010 13:04:31 +0300 Subject: [coldfire-gnu-discuss] uClinux & ColdFire pthread debugging using CodeSourcery 4.4-53 In-Reply-To: <5c75fa9d1003082211w4da007cfi5e93f65a0be3ce4d@mail.gmail.com> References: <5c75fa9d1003082211w4da007cfi5e93f65a0be3ce4d@mail.gmail.com> Message-ID: <4B976EAF.5020003@codesourcery.com> On 3/9/10 9:11 AM, Harry Gunnarsson wrote: ... > Now I am trying to get the latest uclinux.org > distro from 2009 running (kernel 2.6.[29-31]). The main reason is to > look into improvements (kernel, busybox etc) in general (stability) and > JFFS2 enhancements in general. > - uClinux 2009 distro > - CodeSourcery 4.4-53 How do you build your applications (especially the ones that you trying to debug with CodeSourcery's tools)? To get a reliable uClinux system you need to build the binaries with the same tools you then try to debug them with. > My port seems to work well in all aspects except for debugging > multi-thread user apps. > I have tried many permutations of target build flags (-mcpu, -m etc), > and according to CS website it seems recommended to -m5208 runtime with > M5272 ColdFire. Therefore, I have lately tried '-mcpu=5272' for .c > sources and '-m5208' during link. A side note: just specifying -mcpu= consistently to the compiler is the best approach. Also, it is highly recommended to use the compiler driver (m68k-uclinux-gcc or m68k-uclinux-g++) to link the programs -- that way the driver will invoke the linker with the correct set of utility libraries; using the linker directly is error-prone to picking up the libraries for a different CPU. Regards, -- Maxim Kuvyrkov CodeSourcery maxim at codesourcery.com (650) 331-3385 x724 From mrharryg at gmail.com Wed Mar 10 16:18:05 2010 From: mrharryg at gmail.com (Harry Gunnarsson) Date: Wed, 10 Mar 2010 08:18:05 -0800 Subject: [coldfire-gnu-discuss] uClinux & ColdFire pthread debugging using CodeSourcery 4.4-53 In-Reply-To: <4B976EAF.5020003@codesourcery.com> References: <5c75fa9d1003082211w4da007cfi5e93f65a0be3ce4d@mail.gmail.com> <4B976EAF.5020003@codesourcery.com> Message-ID: <5c75fa9d1003100818q5264468fg31e12f33ea6995ad@mail.gmail.com> Thanks for the reply Earlier, with CS 4.2, I used the -m5307 flag for compiling and linking As mentioned I did some more research on the options and now I typically compile like this(The -D flags I don't really use, I brought them over from the userspace makefiles for uClinux distro) m68k-uclinux-gcc -mcpu=5272 -g3 -DCONFIG_COLDFIRE -DEMBED -Dlinux -D__linux__ -Dunix -D__uClinux__ -Isrc/pthread/join -DDEBUG -c src/pthread/join/join.c -o objs/jthread_m68k_Ono/join.o m68k-uclinux-gcc -mcpu=5272 -DCONFIG_COLDFIRE -Wl,--fatal-warnings -Wl,-elf2flt -o objs/jthread_m68k_Ono/jthread_m68k_Ono.bflt objs/jthread_m68k_Ono/join.o -lpthread Running with -v on linking, I see that the following path is used -L...installpath.../freescale-coldfire-4.4/bin/../m68k-uclinux/libc/m5206e/usr/lib Therefore I pick up gdbserver from this path freescale-coldfire-4.4/bin/../m68k-uclinux/libc/m5206e/usr/lib/bin/gdbserver and put it on the target Then I run as usual gdbserver :5000 ./jth...bflt and m68k-uclinux-gdb ./jth...bflt.gdb etc So I think I am doing the right thing here, but please advice if there is another recommended way. Yes, I always follow your last point; I never call ld explicitly. On Wed, Mar 10, 2010 at 2:04 AM, Maxim Kuvyrkov wrote: > On 3/9/10 9:11 AM, Harry Gunnarsson wrote: > ... > >> Now I am trying to get the latest uclinux.org >> >> distro from 2009 running (kernel 2.6.[29-31]). The main reason is to >> look into improvements (kernel, busybox etc) in general (stability) and >> JFFS2 enhancements in general. >> - uClinux 2009 distro >> - CodeSourcery 4.4-53 >> > > How do you build your applications (especially the ones that you trying to > debug with CodeSourcery's tools)? > > To get a reliable uClinux system you need to build the binaries with the > same tools you then try to debug them with. > > > My port seems to work well in all aspects except for debugging >> multi-thread user apps. >> I have tried many permutations of target build flags (-mcpu, -m etc), >> and according to CS website it seems recommended to -m5208 runtime with >> M5272 ColdFire. Therefore, I have lately tried '-mcpu=5272' for .c >> sources and '-m5208' during link. >> > > A side note: just specifying -mcpu= > consistently to the compiler is the best approach. Also, it is highly > recommended to use the compiler driver (m68k-uclinux-gcc or > m68k-uclinux-g++) to link the programs -- that way the driver will invoke > the linker with the correct set of utility libraries; using the linker > directly is error-prone to picking up the libraries for a different CPU. > > Regards, > > -- > Maxim Kuvyrkov > CodeSourcery > maxim at codesourcery.com > (650) 331-3385 x724 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxim at codesourcery.com Thu Mar 11 14:56:20 2010 From: maxim at codesourcery.com (Maxim Kuvyrkov) Date: Thu, 11 Mar 2010 17:56:20 +0300 Subject: [coldfire-gnu-discuss] uClinux & ColdFire pthread debugging using CodeSourcery 4.4-53 In-Reply-To: <5c75fa9d1003100818q5264468fg31e12f33ea6995ad@mail.gmail.com> References: <5c75fa9d1003082211w4da007cfi5e93f65a0be3ce4d@mail.gmail.com> <4B976EAF.5020003@codesourcery.com> <5c75fa9d1003100818q5264468fg31e12f33ea6995ad@mail.gmail.com> Message-ID: <4B990494.5060606@codesourcery.com> On 3/10/10 7:18 PM, Harry Gunnarsson wrote: > Thanks for the reply > > Earlier, with CS 4.2, I used the -m5307 flag for compiling and linking > > As mentioned I did some more research on the options and now I typically > compile like this(The -D flags I don't really use, I brought them over > from the userspace makefiles for uClinux distro) > > m68k-uclinux-gcc -mcpu=5272 -g3 -DCONFIG_COLDFIRE -DEMBED -Dlinux > -D__linux__ -Dunix -D__uClinux__ -Isrc/pthread/join -DDEBUG -c > src/pthread/join/join.c -o objs/jthread_m68k_Ono/join.o > m68k-uclinux-gcc -mcpu=5272 -DCONFIG_COLDFIRE -Wl,--fatal-warnings > -Wl,-elf2flt -o objs/jthread_m68k_Ono/jthread_m68k_Ono.bflt > objs/jthread_m68k_Ono/join.o -lpthread > > Running with -v on linking, I see that the following path is used > -L...installpath.../freescale-coldfire-4.4/bin/../m68k-uclinux/libc/m5206e/usr/lib This is the correct binary. > > Therefore I pick up gdbserver from this path > freescale-coldfire-4.4/bin/../m68k-uclinux/libc/m5206e/usr/lib/bin/gdbserver > and put it on the target > > Then I run as usual > gdbserver :5000 ./jth...bflt Are you sure you are invoking the very gdbserver you put on the target? May be the system gdbserver comes in PATH before the one you put on the target (I did this mistake a couple of times). -- Maxim Kuvyrkov CodeSourcery maxim at codesourcery.com (650) 331-3385 x724 From mrharryg at gmail.com Thu Mar 11 15:46:19 2010 From: mrharryg at gmail.com (Harry Gunnarsson) Date: Thu, 11 Mar 2010 07:46:19 -0800 Subject: [coldfire-gnu-discuss] uClinux & ColdFire pthread debugging using CodeSourcery 4.4-53 In-Reply-To: <4B990494.5060606@codesourcery.com> References: <5c75fa9d1003082211w4da007cfi5e93f65a0be3ce4d@mail.gmail.com> <4B976EAF.5020003@codesourcery.com> <5c75fa9d1003100818q5264468fg31e12f33ea6995ad@mail.gmail.com> <4B990494.5060606@codesourcery.com> Message-ID: <5c75fa9d1003110746p76ce6550kdf0ad5c89902e7b0@mail.gmail.com> Yes, I always check which lib path the compiler picks when experimenting with -mcpu=xxxx I know what you mean, it could be error prone picking the right binary and making sure it is run. Typically I NFS mount my linux host, put the binary on the nfs share. Then on the target: $ cd /var/mnt/jffs2_partition $ cp /var/mnt/nfs/gdbserver . $ cp /var/mnt/nfs/jth . $ ./gdbserver :5000 ./jth This is to be really sure I invoke the right gdbserver/testapp and to take NFS out of the equation( even though it is working fine....) In conclusion; I am pretty sure I invoke the correct binaries. Harry On Thu, Mar 11, 2010 at 6:56 AM, Maxim Kuvyrkov wrote: > On 3/10/10 7:18 PM, Harry Gunnarsson wrote: > >> Thanks for the reply >> >> Earlier, with CS 4.2, I used the -m5307 flag for compiling and linking >> >> As mentioned I did some more research on the options and now I typically >> compile like this(The -D flags I don't really use, I brought them over >> from the userspace makefiles for uClinux distro) >> >> m68k-uclinux-gcc -mcpu=5272 -g3 -DCONFIG_COLDFIRE -DEMBED -Dlinux >> -D__linux__ -Dunix -D__uClinux__ -Isrc/pthread/join -DDEBUG -c >> src/pthread/join/join.c -o objs/jthread_m68k_Ono/join.o >> m68k-uclinux-gcc -mcpu=5272 -DCONFIG_COLDFIRE -Wl,--fatal-warnings >> -Wl,-elf2flt -o objs/jthread_m68k_Ono/jthread_m68k_Ono.bflt >> objs/jthread_m68k_Ono/join.o -lpthread >> >> Running with -v on linking, I see that the following path is used >> >> -L...installpath.../freescale-coldfire-4.4/bin/../m68k-uclinux/libc/m5206e/usr/lib >> > > This is the correct binary. > > > >> Therefore I pick up gdbserver from this path >> >> freescale-coldfire-4.4/bin/../m68k-uclinux/libc/m5206e/usr/lib/bin/gdbserver >> and put it on the target >> >> Then I run as usual >> gdbserver :5000 ./jth...bflt >> > > Are you sure you are invoking the very gdbserver you put on the target? > May be the system gdbserver comes in PATH before the one you put on the > target (I did this mistake a couple of times). > > > -- > Maxim Kuvyrkov > CodeSourcery > maxim at codesourcery.com > (650) 331-3385 x724 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daperlazag at gmail.com Wed Mar 24 18:28:40 2010 From: daperlazag at gmail.com (David A Perlaza G) Date: Wed, 24 Mar 2010 13:28:40 -0500 Subject: Codesourcery toolchain for coldfire and eclipse In-Reply-To: <6228ad3c1003232018v7f908621y3cf51adb688d58ff@mail.gmail.com> References: <6228ad3c1003232018v7f908621y3cf51adb688d58ff@mail.gmail.com> Message-ID: <6228ad3c1003241128q59cbf8a8l5c733c60ae6f9557@mail.gmail.com> Hello. I am 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 build: mkdir: cannot make directory `.obj\src': No such file or directory Description ? ? Resource ? ? ? ?Path ? ?Location ? ? ? ?Type Fatal error: can't create .obj/src/hello.o: No such file or directory ? ? ? hello ? ? ? ? ? line 0 ?C/C++ Problem Attached is my makefile. Should I replace the dot in the Proj_dir line with my project path? I am using GNUWIN32 utilities to have the command line capabilities of linux OS on my windows XP installation. Many thanks in advance for your help. Best regards, -- David Alejandro Perlaza Goyeneche Ingeniero Electr?nico Universidad Nacional de Colombia -------------- next part -------------- ############################################################################################## # Start of default section # TRGT = m68k-elf- CC = $(TRGT)gcc CP = $(TRGT)objcopy AS = $(TRGT)gcc -x assembler-with-cpp BIN = $(CP) -O binary # List all default C defines here, like -D_DEBUG=1 DDEFS = # List all default ASM defines here, like -D_DEBUG=1 DADEFS = # List all default directories to look for include files here DINCDIR = # List the default directory to look for the libraries here DLIBDIR = # List all default libraries here DLIBS = # # End of default section ############################################################################################## ############################################################################################## # Start of user section # # Define project name here PROJECT = hello PROJ_DIR = . # Define linker script file here LDSCRIPT = "C:\Archivos de programa\CodeSourcery\Sourcery G++ Lite\m68k-elf\lib\m5208\m5282evb-ram.ld" #C:\Archivos de programa\CodeSourcery\Sourcery G++ Lite\m68k-elf\lib\m51qe\mcf51cn128-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 = # List all user libraries here ULIBS = #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:\Archivos de programa\CodeSourcery\Sourcery G++ Lite\m68k-elf\include" \ -I"C:\Archivos de programa\CodeSourcery\Sourcery G++ Lite\lib\gcc\m68k-elf\4.4.1\include" \ -I"C:\Archivos de programa\CodeSourcery\Sourcery G++ Lite\lib\gcc\m68k-elf\4.4.1\include-fixed" \ MCFLAGS = -mcpu=528x #cambiar a 51cn...... 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 $(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 version: echo $(CPFLAGS) clean: -del /f/s $(OBJDIR)\*.lst -del /f/s $(OBJDIR)\*.o -del /f $(PROJECT).elf -del /f $(PROJECT).map -del /f $(PROJECT).bin -del /f .dep\*.d # # Include the dependency files, should be the last of the makefile # -include $(shell mkdir .dep 2> nul) $(wildcard .dep/*) # *** EOF *** From list_ob at gmx.net Thu Mar 25 15:38:44 2010 From: list_ob at gmx.net (Oliver Betz) Date: Thu, 25 Mar 2010 16:38:44 +0100 Subject: Where do default memory region definitions come from? Message-ID: <4BAB8384.15521.D2EF19B6@list_ob.gmx.net> Hello All, linking with -nostartfiles -nostdlib -nodefaultlibs (likely somewhat redundant), I get still "warning: redeclaration of memory region `MEM_ROM_VECTORS'" etc. Where does the default memory region definition come from? How do I suppress it? TIA, Oliver (gcc novice) -- Oliver Betz, Muenchen From dan at codesourcery.com Thu Mar 25 15:58:08 2010 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Thu, 25 Mar 2010 11:58:08 -0400 Subject: [coldfire-gnu-discuss] Where do default memory region definitions come from? In-Reply-To: <4BAB8384.15521.D2EF19B6@list_ob.gmx.net> References: <4BAB8384.15521.D2EF19B6@list_ob.gmx.net> Message-ID: <20100325155807.GC9310@caradoc.them.org> On Thu, Mar 25, 2010 at 04:38:44PM +0100, Oliver Betz wrote: > Hello All, > > linking with -nostartfiles -nostdlib -nodefaultlibs (likely somewhat > redundant), I get still > "warning: redeclaration of memory region `MEM_ROM_VECTORS'" etc. > > Where does the default memory region definition come from? How do I > suppress it? There aren't default memory regions. It's probably coming from a linker script elsewhere on your command line, e.g. having the same script twice. -- Daniel Jacobowitz CodeSourcery From list_ob at gmx.net Thu Mar 25 16:29:21 2010 From: list_ob at gmx.net (Oliver Betz) Date: Thu, 25 Mar 2010 17:29:21 +0100 Subject: [coldfire-gnu-discuss] Where do default memory region definitions come from? In-Reply-To: <20100325155807.GC9310@caradoc.them.org> References: <4BAB8384.15521.D2EF19B6@list_ob.gmx.net>, <20100325155807.GC9310@caradoc.them.org> Message-ID: <4BAB8F61.4315.D31D70C0@list_ob.gmx.net> Daniel Jacobowitz wrote: [...] > > Where does the default memory region definition come from? How do I > > suppress it? > > There aren't default memory regions. It's probably coming from a > linker script elsewhere on your command line, e.g. having the same > script twice. indeed, I passed the linker script twice. Thanks for the quick and helpful reply! Oliver -- Oliver Betz, Muenchen From list-bastian.schick at sciopta.com Fri Mar 26 15:53:57 2010 From: list-bastian.schick at sciopta.com (42Bastian) Date: Fri, 26 Mar 2010 16:53:57 +0100 Subject: [coldfire-gnu-discuss] Where do default memory region definitions come from? In-Reply-To: <4BAB8384.15521.D2EF19B6@list_ob.gmx.net> References: <4BAB8384.15521.D2EF19B6@list_ob.gmx.net> Message-ID: <4BACD895.7050807@sciopta.com> Am 25.03.2010 16:38, schrieb Oliver Betz: > Hello All, > > linking with -nostartfiles -nostdlib -nodefaultlibs (likely somewhat > redundant), I get still No.IIRC: stdlib => libc defaultlib => libgcc -- 42Bastian + | http://www.sciopta.com | Fastest direct message passing kernel. | IEC61508 certified. + From dan at codesourcery.com Fri Mar 26 16:08:55 2010 From: dan at codesourcery.com (Daniel Jacobowitz) Date: Fri, 26 Mar 2010 12:08:55 -0400 Subject: [coldfire-gnu-discuss] Where do default memory region definitions come from? In-Reply-To: <4BACD895.7050807@sciopta.com> References: <4BAB8384.15521.D2EF19B6@list_ob.gmx.net> <4BACD895.7050807@sciopta.com> Message-ID: <20100326160855.GP9310@caradoc.them.org> On Fri, Mar 26, 2010 at 04:53:57PM +0100, 42Bastian wrote: > Am 25.03.2010 16:38, schrieb Oliver Betz: > > Hello All, > > > > linking with -nostartfiles -nostdlib -nodefaultlibs (likely somewhat > > redundant), I get still > > No.IIRC: > stdlib => libc > defaultlib => libgcc Don't worry about recalling, look it up :-) `-nostartfiles' -> No startup files. `-nodefaultlibs' -> No standard system libraries. `-nostdlib' -> Neither. -- Daniel Jacobowitz CodeSourcery From jsujjavanich at syntech-fuelmaster.com Fri Mar 26 20:57:40 2010 From: jsujjavanich at syntech-fuelmaster.com (Jate Sujjavanich) Date: Fri, 26 Mar 2010 16:57:40 -0400 Subject: linux 2.6.29-uc0, coldfire 5235 init Message-ID: <6C2434209962DC46B88345CA85C334A285DAAC885B@Courier.syntech.org> I am having trouble using Sourcery G++ Lite 4.4-53 for my Coldfire 5235 system. I had kernel booting to init and a command prompt. However, when I turn on CONFIG_FRAME_POINTER in the kernel, I get a kernel panic. Tracing via BDM tells me there is a SIGILL happening. From what I k now so far, the last thing init does is do a "wait" system call. My current guess is that the wait fails to return because the uClibc call is incompatible with CONFIG_FRAME_POINTER. Is this totally off the wall? Thanks. Jate S. -------------- next part -------------- An HTML attachment was scrubbed... URL: