From rjohnson at engagenet.com  Wed Nov 14 20:12:44 2007
From: rjohnson at engagenet.com (Rick Johnson)
Date: Wed, 14 Nov 2007 14:12:44 -0600
Subject: Problems with librt and libesmtp
Message-ID: <6629C06B144F5C4098DFF95C4FF9DAF70290E12D@mailsrv.engagenet.com>

Whenever I link in either of these libraries, my applications run very
slowly.  I don't even have to use a function from the library to cause
this slowness.  A simple 'Hellow World' took 30 seconds to run with
libesmtp linked in.  

 

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20071114/39ceb7b7/attachment.html>

From nathan at codesourcery.com  Thu Nov 15 07:54:41 2007
From: nathan at codesourcery.com (Nathan Sidwell)
Date: Thu, 15 Nov 2007 07:54:41 +0000
Subject: [coldfire-gnu-discuss] Problems with librt and libesmtp
In-Reply-To: <6629C06B144F5C4098DFF95C4FF9DAF70290E12D@mailsrv.engagenet.com>
References: <6629C06B144F5C4098DFF95C4FF9DAF70290E12D@mailsrv.engagenet.com>
Message-ID: <473BFB41.1010608@codesourcery.com>

Rick Johnson wrote:
> Whenever I link in either of these libraries, my applications run very 
> slowly.  I don?t even have to use a function from the library to cause 
> this slowness.  A simple ?Hellow World? took 30 seconds to run with 
> libesmtp linked in. 

Have you tried profiling your application?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery



From Christof.Frey at varian.com  Thu Nov 22 17:32:15 2007
From: Christof.Frey at varian.com (Christof Frey)
Date: Thu, 22 Nov 2007 09:32:15 -0800
Subject: Unexpected zero divide trap whilst running fib.c demo app
Message-ID: <CFAB8288DDD3554A945E29E58D01F9F50434B3251A@PA-EX-MBXVS03.vms.ad.varian.com>

Hi all,

I followed the getting started guide for 4.2-47 chapter 3.2 and implemented the fib.c accordingly to validate correct installation of the whole toolchain.
The command line I used is:
m68k-elf-gcc -mcpu=5235 -Tm5235evb-ram-hosted.ld fib.c -o fib -g
When trying to debug the application I get the following output in GDB:

(gdb) target remote | m68k-elf-sprite pe://ParallelPortCable m5235evb
Remote debugging using | m68k-elf-sprite pe://ParallelPortCable m5235evb
m68k-elf-sprite: Opening P&E ParallelPortCable port 1 (LPT1 : Parallel Port 1 (A
ddress $0378))
m68k-elf-sprite: Target reset
0x00000000 in __cs3_interrupt_vector_coldfire ()
(gdb) load
Loading section .text, size 0xe58 lma 0x0
Loading section .data, size 0x400 lma 0xe58
Start address 0x9ac, load size 4696
Transfer rate: 2 KB/sec, 2348 bytes/write.
(gdb) break main
Breakpoint 1 at 0x60c: file fib.c, line 16.
(gdb) continue
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000d32 in __cs3_isr_divide_by_zero ()
(gdb)

I must admit that I had to change line 55 in file m5235evb.xml in order to get the initialization working:
original:
    <write-memory address="0x80000048" value="0x2308"/>
changed to:
    <write-memory address="0x40000048" value="0x2308"/>
since 0x800000xx is not in the address space. I guess this was a bug (?)

A wonder why the application gets a zero divide trap ? (I think it is caused by write() function)

Thank you and best regards,
Christof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20071122/a98622fd/attachment.html>

From nathan at codesourcery.com  Fri Nov 23 15:07:11 2007
From: nathan at codesourcery.com (Nathan Sidwell)
Date: Fri, 23 Nov 2007 15:07:11 +0000
Subject: [coldfire-gnu-discuss] Unexpected zero divide trap whilst running
 fib.c demo app
In-Reply-To: <CFAB8288DDD3554A945E29E58D01F9F50434B3251A@PA-EX-MBXVS03.vms.ad.varian.com>
References: <CFAB8288DDD3554A945E29E58D01F9F50434B3251A@PA-EX-MBXVS03.vms.ad.varian.com>
Message-ID: <4746EC9F.2030203@codesourcery.com>

Christof Frey wrote:
> Hi all,
>  
> I followed the getting started guide for 4.2-47 chapter 3.2 and 
> implemented the fib.c accordingly to validate correct installation of 
> the whole toolchain.
> The command line I used is:
> m68k-elf-gcc -mcpu=5235 -Tm5235evb-ram-hosted.ld fib.c -o fib -g
> When trying to debug the application I get the following output in GDB:
>  
> (gdb) target remote | m68k-elf-sprite pe://ParallelPortCable m5235evb
> Remote debugging using | m68k-elf-sprite pe://ParallelPortCable m5235evb
> m68k-elf-sprite: Opening P&E ParallelPortCable port 1 (LPT1 : Parallel 
> Port 1 (A
> ddress $0378))
> m68k-elf-sprite: Target reset
> 0x00000000 in __cs3_interrupt_vector_coldfire ()
> (gdb) load
> Loading section .text, size 0xe58 lma 0x0
> Loading section .data, size 0x400 lma 0xe58
> Start address 0x9ac, load size 4696
> Transfer rate: 2 KB/sec, 2348 bytes/write.
> (gdb) break main
> Breakpoint 1 at 0x60c: file fib.c, line 16.
> (gdb) continue
> Continuing.
>  
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000d32 in __cs3_isr_divide_by_zero ()
> (gdb)
>  
> I must admit that I had to change line 55 in file m5235evb.xml in order 
> to get the initialization working:
> original:
>     <write-memory address="0x80000048" value="0x2308"/>
> changed to:
>     <write-memory address="0x40000048" value="0x2308"/>
> since 0x800000xx is not in the address space. I guess this was a bug (?)

Yes, thanks, that was a typo in the configuration file.

> A wonder why the application gets a zero divide trap ? (I think it is 
> caused by write() function)

Are you able to generate a stack trace and determine the location of the trap?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery



From Christof.Frey at varian.com  Mon Nov 26 10:23:31 2007
From: Christof.Frey at varian.com (Christof Frey)
Date: Mon, 26 Nov 2007 02:23:31 -0800
Subject: [coldfire-gnu-discuss] Unexpected zero divide trap whilst
 running fib.c demo app
In-Reply-To: <4746EC9F.2030203@codesourcery.com>
References: <CFAB8288DDD3554A945E29E58D01F9F50434B3251A@PA-EX-MBXVS03.vms.ad.varian.com>
 <4746EC9F.2030203@codesourcery.com>
Message-ID: <CFAB8288DDD3554A945E29E58D01F9F50434D44B2E@PA-EX-MBXVS03.vms.ad.varian.com>



Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000d32 in __cs3_isr_divide_by_zero ()
(gdb) backtrace
#0  0x00000d32 in __cs3_isr_divide_by_zero ()
#1  0x000009a0 in late_initialize ()
#2  0x000008de in __do_global_ctors_aux ()
#3  0x020022e3 in ?? ()
#4  0x00ffffcc in ?? ()
#5  0x00000e18 in _init ()
#6  0x00ffffe0 in ?? ()
#7  0x00ffffe0 in ?? ()
#8  0xfffffffe in ?? ()
#9  0x00000000 in ?? ()
(gdb)

-----Original Message-----
From: Nathan Sidwell [mailto:nathan at codesourcery.com]
Sent: Friday, November 23, 2007 4:07 PM
To: Christof Frey
Cc: coldfire-gnu-discuss at codesourcery.com
Subject: Re: [coldfire-gnu-discuss] Unexpected zero divide trap whilst running fib.c demo app

Christof Frey wrote:
> Hi all,
>
> I followed the getting started guide for 4.2-47 chapter 3.2 and
> implemented the fib.c accordingly to validate correct installation of
> the whole toolchain.
> The command line I used is:
> m68k-elf-gcc -mcpu=5235 -Tm5235evb-ram-hosted.ld fib.c -o fib -g When
> trying to debug the application I get the following output in GDB:
>
> (gdb) target remote | m68k-elf-sprite pe://ParallelPortCable m5235evb
> Remote debugging using | m68k-elf-sprite pe://ParallelPortCable
> m5235evb
> m68k-elf-sprite: Opening P&E ParallelPortCable port 1 (LPT1 : Parallel
> Port 1 (A ddress $0378))
> m68k-elf-sprite: Target reset
> 0x00000000 in __cs3_interrupt_vector_coldfire ()
> (gdb) load
> Loading section .text, size 0xe58 lma 0x0 Loading section .data, size
> 0x400 lma 0xe58 Start address 0x9ac, load size 4696 Transfer rate: 2
> KB/sec, 2348 bytes/write.
> (gdb) break main
> Breakpoint 1 at 0x60c: file fib.c, line 16.
> (gdb) continue
> Continuing.
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000d32 in __cs3_isr_divide_by_zero ()
> (gdb)
>
> I must admit that I had to change line 55 in file m5235evb.xml in
> order to get the initialization working:
> original:
>     <write-memory address="0x80000048" value="0x2308"/> changed to:
>     <write-memory address="0x40000048" value="0x2308"/> since
> 0x800000xx is not in the address space. I guess this was a bug (?)

Yes, thanks, that was a typo in the configuration file.

> A wonder why the application gets a zero divide trap ? (I think it is
> caused by write() function)

Are you able to generate a stack trace and determine the location of the trap?

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery



From nathan at codesourcery.com  Mon Nov 26 11:32:40 2007
From: nathan at codesourcery.com (Nathan Sidwell)
Date: Mon, 26 Nov 2007 11:32:40 +0000
Subject: [coldfire-gnu-discuss] Unexpected zero divide trap whilst running
 fib.c demo app
In-Reply-To: <CFAB8288DDD3554A945E29E58D01F9F50434D44B2E@PA-EX-MBXVS03.vms.ad.varian.com>
References: <CFAB8288DDD3554A945E29E58D01F9F50434B3251A@PA-EX-MBXVS03.vms.ad.varian.com> <4746EC9F.2030203@codesourcery.com> <CFAB8288DDD3554A945E29E58D01F9F50434D44B2E@PA-EX-MBXVS03.vms.ad.varian.com>
Message-ID: <474AAED8.30803@codesourcery.com>

Christof Frey wrote:
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000d32 in __cs3_isr_divide_by_zero ()
> (gdb) backtrace
> #0  0x00000d32 in __cs3_isr_divide_by_zero ()
> #1  0x000009a0 in late_initialize ()
> #2  0x000008de in __do_global_ctors_aux ()

Thanks.  Here's the disassembly of late_initialize.

0000098c <late_initialize>:
  98c:   223c 0000 0000  movel #0,%d1
  992:   4e7b 1801       movec %d1,%vbr
  996:   223c 8100 0000  movel #-2130706432,%d1
  99c:   4e7b 1002       movec %d1,%cacr
  9a0:   223c 4000 c040  movel #1073791040,%d1
  9a6:   4e7b 1004       movec %d1,%itt0
  9aa:   4e75            rts

The reason you end up in __cs3_isr_divide_by_zero is because all the vectors 
point at the same routine (which stops).  The toolchain simply uses the first 
label that matches that address, which in this case is __cs3_isr_divide_by_zero.

Could you verify that your program image is the same as mine?
	m68k-elf-objdump -d fib
from the command line, or
	disassemble late_initialize
from gdb should do the trick.  If it's different, then just the late_initialize 
routine addresses are important.

Could you also find the stack values so we know exactly which trap you are 
experiencing?  You can do this with
	x/8x $sp
when gdb stops in the trap handler.

I've double checked and the 5235 part does have a cache, so writing to the cacr 
should be ok.  The value being written is 0x81000000, which should invalidate 
all the cache entries and enable caching.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery



From Christof.Frey at varian.com  Mon Nov 26 13:02:31 2007
From: Christof.Frey at varian.com (Christof Frey)
Date: Mon, 26 Nov 2007 05:02:31 -0800
Subject: [coldfire-gnu-discuss] Unexpected zero divide trap whilst
 running fib.c demo app
In-Reply-To: <474AAED8.30803@codesourcery.com>
References: <CFAB8288DDD3554A945E29E58D01F9F50434B3251A@PA-EX-MBXVS03.vms.ad.varian.com>
 <4746EC9F.2030203@codesourcery.com>
 <CFAB8288DDD3554A945E29E58D01F9F50434D44B2E@PA-EX-MBXVS03.vms.ad.varian.com>
 <474AAED8.30803@codesourcery.com>
Message-ID: <CFAB8288DDD3554A945E29E58D01F9F50434D44C0F@PA-EX-MBXVS03.vms.ad.varian.com>

late initialization from my image (from attached *zip - identical to yours):

0000098c <late_initialize>:
 98c:   223c 0000 0000  movel #0,%d1
 992:   4e7b 1801       movec %d1,%vbr
 996:   223c 8100 0000  movel #-2130706432,%d1
 99c:   4e7b 1002       movec %d1,%cacr
 9a0:   223c 4000 c040  movel #1073791040,%d1
 9a6:   4e7b 1004       movec %d1,%itt0
 9aa:   4e75            rts


stack values:

Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000d32 in __cs3_isr_divide_by_zero ()
(gdb) x/8x $sp
0xffffb4:       0x000009a0      0x000008de      0x00000d60      0x00ffffcc
0xffffc4:       0x00000e18      0x00ffffe0      0x00ffffe0      0xfffffffe
(gdb)

I solved the problem with the option -nostartfiles, so the command line that works is:

m68k-elf-gcc -mcpu=5235 -Tm5235evb-ram-hosted.ld fib.c -nostartfiles -o fib -g

With above command line there is no change in the code of <late_initialize> but many other differences.


Christof
-----Original Message-----
From: Nathan Sidwell [mailto:nathan at codesourcery.com]
Sent: Monday, November 26, 2007 12:33 PM
To: Christof Frey
Cc: coldfire-gnu-discuss at codesourcery.com
Subject: Re: [coldfire-gnu-discuss] Unexpected zero divide trap whilst running fib.c demo app

Christof Frey wrote:
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000d32 in __cs3_isr_divide_by_zero ()
> (gdb) backtrace
> #0  0x00000d32 in __cs3_isr_divide_by_zero ()
> #1  0x000009a0 in late_initialize ()
> #2  0x000008de in __do_global_ctors_aux ()

Thanks.  Here's the disassembly of late_initialize.

0000098c <late_initialize>:
  98c:   223c 0000 0000  movel #0,%d1
  992:   4e7b 1801       movec %d1,%vbr
  996:   223c 8100 0000  movel #-2130706432,%d1
  99c:   4e7b 1002       movec %d1,%cacr
  9a0:   223c 4000 c040  movel #1073791040,%d1
  9a6:   4e7b 1004       movec %d1,%itt0
  9aa:   4e75            rts

The reason you end up in __cs3_isr_divide_by_zero is because all the vectors point at the same routine (which stops).  The toolchain simply uses the first label that matches that address, which in this case is __cs3_isr_divide_by_zero.

Could you verify that your program image is the same as mine?
        m68k-elf-objdump -d fib
from the command line, or
        disassemble late_initialize
from gdb should do the trick.  If it's different, then just the late_initialize routine addresses are important.

Could you also find the stack values so we know exactly which trap you are experiencing?  You can do this with
        x/8x $sp
when gdb stops in the trap handler.

I've double checked and the 5235 part does have a cache, so writing to the cacr should be ok.  The value being written is 0x81000000, which should invalidate all the cache entries and enable caching.

nathan

--
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fib_dump.zip
Type: application/x-zip-compressed
Size: 8646 bytes
Desc: fib_dump.zip
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20071126/07398c82/attachment.bin>

From Christof.Frey at varian.com  Mon Nov 26 14:02:27 2007
From: Christof.Frey at varian.com (Christof Frey)
Date: Mon, 26 Nov 2007 06:02:27 -0800
Subject: Sourcery G++ Lite support for m5235evb serial I/F ?
Message-ID: <CFAB8288DDD3554A945E29E58D01F9F50434D44C60@PA-EX-MBXVS03.vms.ad.varian.com>

Hi,

is there any support from the Lite version for <stdio.h> functions ( in particular printf(); ) to work via the serial communication interface of the M5235BCC evaluation board from Freescale ?

I am pretty new to the GNU toolchains for embedded systems so I'd appreciate to get any direction for further information to above.

Thanks,
Christof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/coldfire-gnu-discuss/attachments/20071126/62ece807/attachment.html>

From kazu at codesourcery.com  Mon Nov 26 16:14:11 2007
From: kazu at codesourcery.com (Kazu Hirata)
Date: Mon, 26 Nov 2007 11:14:11 -0500
Subject: [coldfire-gnu-discuss] Sourcery G++ Lite support for m5235evb
 serial I/F ?
In-Reply-To: <CFAB8288DDD3554A945E29E58D01F9F50434D44C60@PA-EX-MBXVS03.vms.ad.varian.com>
References: <CFAB8288DDD3554A945E29E58D01F9F50434D44C60@PA-EX-MBXVS03.vms.ad.varian.com>
Message-ID: <474AF0D3.8020701@codesourcery.com>

Hi Christof,

> is there any support from the Lite version for <stdio.h> functions ( in particular printf(); ) to work via the serial communication interface of the M5235BCC evaluation board from Freescale ?

You need to override "write".

   ssize_t write(int fd, const void *buf, size_t count);

Your version of write should take COUNT characters from BUF.  You can 
ignore FD.  printf uses the function to write to stdout.  You still have to 
write the serial port support yourself.

If you would like printf support just for debugging purposes, you can route 
stdout to gdb's console just by linking your application with -T 
m5235evb-ram-hosted.ld or m5235evb-rom-hosted.ld.  In that case, you do not 
need to override "write".  The default version of "write" knows how to 
print characters at gdb's console.

Hope this helps,

Kazu Hirata


From Christof.Frey at varian.com  Mon Nov 26 16:24:24 2007
From: Christof.Frey at varian.com (Christof Frey)
Date: Mon, 26 Nov 2007 08:24:24 -0800
Subject: [coldfire-gnu-discuss] Sourcery G++ Lite support for m5235evb
 serial I/F ?
In-Reply-To: <474AF0D3.8020701@codesourcery.com>
References: <CFAB8288DDD3554A945E29E58D01F9F50434D44C60@PA-EX-MBXVS03.vms.ad.varian.com>
 <474AF0D3.8020701@codesourcery.com>
Message-ID: <CFAB8288DDD3554A945E29E58D01F9F50434D44D3C@PA-EX-MBXVS03.vms.ad.varian.com>

Thank you very much for this quick support

Christof

-----Original Message-----
From: Kazu Hirata [mailto:kazu at codesourcery.com]
Sent: Monday, November 26, 2007 5:14 PM
To: Christof Frey
Cc: coldfire-gnu-discuss at codesourcery.com
Subject: Re: [coldfire-gnu-discuss] Sourcery G++ Lite support for m5235evb serial I/F ?

Hi Christof,

> is there any support from the Lite version for <stdio.h> functions ( in particular printf(); ) to work via the serial communication interface of the M5235BCC evaluation board from Freescale ?

You need to override "write".

   ssize_t write(int fd, const void *buf, size_t count);

Your version of write should take COUNT characters from BUF.  You can ignore FD.  printf uses the function to write to stdout.  You still have to write the serial port support yourself.

If you would like printf support just for debugging purposes, you can route stdout to gdb's console just by linking your application with -T m5235evb-ram-hosted.ld or m5235evb-rom-hosted.ld.  In that case, you do not need to override "write".  The default version of "write" knows how to print characters at gdb's console.

Hope this helps,

Kazu Hirata


From mark at codesourcery.com  Mon Nov 26 16:37:53 2007
From: mark at codesourcery.com (Mark Mitchell)
Date: Mon, 26 Nov 2007 08:37:53 -0800
Subject: [coldfire-gnu-discuss] Sourcery G++ Lite support for m5235evb
 serial I/F ?
In-Reply-To: <474AF0D3.8020701@codesourcery.com>
References: <CFAB8288DDD3554A945E29E58D01F9F50434D44C60@PA-EX-MBXVS03.vms.ad.varian.com> <474AF0D3.8020701@codesourcery.com>
Message-ID: <474AF661.6000809@codesourcery.com>

Kazu Hirata wrote:

> You need to override "write".
> 
>   ssize_t write(int fd, const void *buf, size_t count);

Actuall, you should override "_write" rather than "write".  The
functions intended to be overridden are all prefaced with "_".

-- 
Mark Mitchell
CodeSourcery
mark at codesourcery.com
(650) 331-3385 x713


From nathan at codesourcery.com  Mon Nov 26 16:42:29 2007
From: nathan at codesourcery.com (Nathan Sidwell)
Date: Mon, 26 Nov 2007 16:42:29 +0000
Subject: [coldfire-gnu-discuss] Sourcery G++ Lite support for m5235evb
 serial I/F ?
In-Reply-To: <474AF661.6000809@codesourcery.com>
References: <CFAB8288DDD3554A945E29E58D01F9F50434D44C60@PA-EX-MBXVS03.vms.ad.varian.com> <474AF0D3.8020701@codesourcery.com> <474AF661.6000809@codesourcery.com>
Message-ID: <474AF775.1070205@codesourcery.com>

Mark Mitchell wrote:
> Kazu Hirata wrote:
> 
>> You need to override "write".
>>
>>   ssize_t write(int fd, const void *buf, size_t count);
> 
> Actuall, you should override "_write" rather than "write".  The
> functions intended to be overridden are all prefaced with "_".

This depends on how newlib is configured.  For ARM toolchains, Mark Mitchell is 
correct.  For ColdFire toolchains Kazu is correct.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery



From janders2 at digipen.edu  Wed Nov 28 22:49:16 2007
From: janders2 at digipen.edu (janders2 at digipen.edu)
Date: Wed, 28 Nov 2007 14:49:16 -0800
Subject: Can't get m68k-elf-gcc to link
Message-ID: <20071128144916.zso3tjwmck0gk0g0@webmail.digipen.edu>

Hello,
                I am using the g++ lite for coldfire m68k and I can?t  
seem to get the files to link when compiling. It will compile fine,  
but if I try and Link or Compile/Link I get this error log:

C:\Documents and Settings\BluePolarBear\Desktop>m68k-elf-gcc Hello.c
c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.1/
/../../../m68k-elf/bin/ld.exe: warning: cannot find entry symbol _start; defau
ing to 80000080
c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.1/
/../../../m68k-elf/lib\libc.a(lib_a-makebuf.o): In function `__smakebuf':
makebuf.c:(.text+0xde): undefined reference to `isatty'
c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.1/
/../../../m68k-elf/lib\libc.a(lib_a-sbrkr.o): In function `_sbrk_r':
sbrkr.c:(.text+0x10): undefined reference to `sbrk'
c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.1/
/../../../m68k-elf/lib\libc.a(lib_a-writer.o): In function `_write_r':
writer.c:(.text+0x18): undefined reference to `write'
c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.1/
/../../../m68k-elf/lib\libc.a(lib_a-closer.o): In function `_close_r':
closer.c:(.text+0x10): undefined reference to `close'
c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.1/
/../../../m68k-elf/lib\libc.a(lib_a-fstatr.o): In function `_fstat_r':
fstatr.c:(.text+0x14): undefined reference to `fstat'
c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.1/
/../../../m68k-elf/lib\libc.a(lib_a-lseekr.o): In function `_lseek_r':
lseekr.c:(.text+0x18): undefined reference to `lseek'
c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.1/
/../../../m68k-elf/lib\libc.a(lib_a-readr.o): In function `_read_r':
readr.c:(.text+0x18): undefined reference to `read'
collect2: ld returned 1 exit status

Any info as to why this is happening would be a big help.

Jeremy Anderson




From sandra at codesourcery.com  Wed Nov 28 23:44:08 2007
From: sandra at codesourcery.com (Sandra Loosemore)
Date: Wed, 28 Nov 2007 18:44:08 -0500
Subject: [coldfire-gnu-discuss] Can't get m68k-elf-gcc to link
In-Reply-To: <20071128144916.zso3tjwmck0gk0g0@webmail.digipen.edu>
References: <20071128144916.zso3tjwmck0gk0g0@webmail.digipen.edu>
Message-ID: <474DFD48.9070905@codesourcery.com>

janders2 at digipen.edu wrote:
> Hello,
>                I am using the g++ lite for coldfire m68k and I can?t 
> seem to get the files to link when compiling. It will compile fine, but 
> if I try and Link or Compile/Link I get this error log:  [snip]

You need to specify a linker script.  This is discussed in the Getting Started 
Guide included with the Lite distribution.

-Sandra


From david at westcontrol.com  Thu Nov 29 13:15:45 2007
From: david at westcontrol.com (David Brown)
Date: Thu, 29 Nov 2007 14:15:45 +0100
Subject: Source code for cs3 library
Message-ID: <474EBB81.3080201@westcontrol.com>

I'm trying to see exactly how the new CS3 startup code works, with a 
view to using it instead of my own hand-written startup code for 
ColdFire projects, but I'm having a great deal of difficulty finding the 
source for the library.  I am currently using the "lite" version 
freescale-coldfire-4.2.47-m68k-elf on windows (my subscription ran out 
about a month ago, and we haven't yet figured out if we want to renew 
it, and which computers we need to use it on).

As far as I can figure out, the newlib-stable/libgloss/m68k directory in 
the 4.2.47 source code tarball contains the source for the older startup 
code - files such as cf-crt1.c are labelled copyright 2006, and use the 
earlier style of startup.  The Makefile.in in this directory will 
generate the older linker files (m5213evb-ram-hosted.ld, etc) and not 
the newer versions (which have clock-speed specific versions for 
convenience).

This is important to me various reasons.  I like to know exactly what 
code is running on my boards, and I need to be able to modify the 
startup code (for using my own boards that do not correspond directly to 
the evaluation boards, for re-arranging memory maps to suit my needs, 
and for adding new features such as making extra sections that go at 
specific addresses).

I also note that you've made a little mistake in the rom version of the 
linker files - your .bss section is marked ">ram AT>rom" instead of just 
">ram" - there is no need for the .bss section to be mirrored in rom.

Thanks for any pointers,

David Brown


From nathan at codesourcery.com  Thu Nov 29 13:01:53 2007
From: nathan at codesourcery.com (Nathan Sidwell)
Date: Thu, 29 Nov 2007 13:01:53 +0000
Subject: [coldfire-gnu-discuss] Source code for cs3 library
In-Reply-To: <474EBB81.3080201@westcontrol.com>
References: <474EBB81.3080201@westcontrol.com>
Message-ID: <474EB841.80604@codesourcery.com>

David,
> As far as I can figure out, the newlib-stable/libgloss/m68k directory in 
> the 4.2.47 source code tarball contains the source for the older startup 
> code - files such as cf-crt1.c are labelled copyright 2006, and use the 
> earlier style of startup.  The Makefile.in in this directory will 
> generate the older linker files (m5213evb-ram-hosted.ld, etc) and not 
> the newer versions (which have clock-speed specific versions for 
> convenience).

Correct.  The code in libgloss/m68k is no longer used.  the CS3 startup code 
sources are in m68k-elf/lib/src

> I also note that you've made a little mistake in the rom version of the 
> linker files - your .bss section is marked ">ram AT>rom" instead of just 
> ">ram" - there is no need for the .bss section to be mirrored in rom.

the AT>rom is harmless and does mean the headers are somewhat more intelligible.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery