[uClinux-dev] g++, strange behavior issues

Discussion:

Angelo Dureghello

2014-01-23 09:15:55 UTC

Dear all,

i have a small board with a coldfire mcf5307, 4 MB flash and 16MB sdram.

I have loaded on it this ucLinux:

~ # cat /proc/version
uClinux version 2.6.36.2 (angelo at angel3) (gcc version 4.6.1 (Sourcery
CodeBench Lite 2011.09-23) ) #122 Fri Dec 14 23:52:01 CET 2012

I am now trying to upload and run a simple c++ program, with just 3
simple classes,
and a main().

Fist issue,

I tried to use the most recent uclinux.org supplied toolchanin
(m68k-uclinux-20101118),
i get :

make
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c -o
obj/base64.o src/base64.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c -o
obj/main.o src/main.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c -o
obj/sha256.o src/sha256.cc
/usr/local/bin/m68k-uclinux-g++ obj/base64.o obj/main.o obj/sha256.o
-m5307 -o bin/cfbm -Wl,-Map,bin/cfbm.map
ERROR: text=0x1c100 overlaps data=0x0 ?
collect2: ld returned 1 exit status
make: *** [bin/cfbm] Error 1

Surfing the net, i don't find any good explaination to this, and the
common workaround
suggested is to use the CodeSourcery toolchain.
So as a first thing i was wondering if the uclinux "user" folder does
contain some cpp
projects, how do they compile ?

Then i moved to the CodeSourcery toolchain, that i copied from an old
hard disk, since
seems is not free to download anymore, is it ? Are there any alternative ?

With this toolchain strange things happen, until a certain point, adding
code, everything
works fine, program is correctly compiled on my host and executed on the
board. Then,
strangely, as the code increase, the program execution crash (without
errors on console)
and paralize the system. As i remove (comment out) some lines, ini
random places, program
start to work correctly again.
So for now, also the CodeSourcery toolchain solution is not helping me.

I have now the suspect that uClinux itself has not been correctly
configured, or that i am
suffering for my 16MB of ram, even if i see 6,8MB still free before
executing.

~ # cat /proc/meminfo
MemTotal: 13684 kB
MemFree: 6984 kB
Buffers: 16 kB
Cached: 144 kB
SwapCached: 0 kB
Active: 64 kB
Inactive: 48 kB
Active(anon): 0 kB
Inactive(anon): 0 kB
Active(file): 64 kB
Inactive(file): 48 kB
Unevictable: 0 kB
Mlocked: 0 kB
MmapCopy: 412 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 40 kB
Writeback: 0 kB
AnonPages: 0 kB
Mapped: 0 kB
Shmem: 0 kB
Slab: 1292 kB
SReclaimable: 64 kB
SUnreclaim: 1228 kB
KernelStack: 108 kB
PageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6840 kB
Committed_AS: 0 kB
VmallocTotal: 0 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB

I don't know actually how to move, every help is accepted.

Many thanks,
angelo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20140123/ec296d67/attachment.html>

Larry Baker

2014-01-23 18:49:04 UTC

Permalink

Angelo,

Hi Larry,
flthdr is the utility to manipulate the header
====
flthdr -s flat-executable
flthdr -z flat-executable
creates a fully compressed executable, and
flthdr -d flat-executable
compresses only the data segment.
====
...MaTed

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

Dear all,
i have a small board with a coldfire mcf5307, 4 MB flash and 16MB sdram.
~ # cat /proc/version
uClinux version 2.6.36.2 (angelo at angel3) (gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-23) ) #122 Fri Dec 14 23:52:01 CET 2012
I am now trying to upload and run a simple c++ program, with just 3 simple classes,
and a main().
Fist issue,
I tried to use the most recent uclinux.org supplied toolchanin (m68k-uclinux-20101118),
make
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c -o obj/base64.o src/base64.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c -o obj/main.o src/main.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c -o obj/sha256.o src/sha256.cc
/usr/local/bin/m68k-uclinux-g++ obj/base64.o obj/main.o obj/sha256.o -m5307 -o bin/cfbm -Wl,-Map,bin/cfbm.map
ERROR: text=0x1c100 overlaps data=0x0 ?
collect2: ld returned 1 exit status
make: *** [bin/cfbm] Error 1
Surfing the net, i don't find any good explaination to this, and the common workaround
suggested is to use the CodeSourcery toolchain.
So as a first thing i was wondering if the uclinux "user" folder does contain some cpp
projects, how do they compile ?
Then i moved to the CodeSourcery toolchain, that i copied from an old hard disk, since
seems is not free to download anymore, is it ? Are there any alternative ?
With this toolchain strange things happen, until a certain point, adding code, everything
works fine, program is correctly compiled on my host and executed on the board. Then,
strangely, as the code increase, the program execution crash (without errors on console)
and paralize the system. As i remove (comment out) some lines, ini random places, program
start to work correctly again.
So for now, also the CodeSourcery toolchain solution is not helping me.
I have now the suspect that uClinux itself has not been correctly configured, or that i am
suffering for my 16MB of ram, even if i see 6,8MB still free before executing.
~ # cat /proc/meminfo
MemTotal: 13684 kB
MemFree: 6984 kB
Buffers: 16 kB
Cached: 144 kB
SwapCached: 0 kB
Active: 64 kB
Inactive: 48 kB
Active(anon): 0 kB
Inactive(anon): 0 kB
Active(file): 64 kB
Inactive(file): 48 kB
Unevictable: 0 kB
Mlocked: 0 kB
MmapCopy: 412 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 40 kB
Writeback: 0 kB
AnonPages: 0 kB
Mapped: 0 kB
Shmem: 0 kB
Slab: 1292 kB
SReclaimable: 64 kB
SUnreclaim: 1228 kB
KernelStack: 108 kB
PageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6840 kB
Committed_AS: 0 kB
VmallocTotal: 0 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
I don't know actually how to move, every help is accepted.
Many thanks,
angelo
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20140123/8f4770ae/attachment.html>

Angelo Dureghello

2014-01-23 22:31:38 UTC

Permalink

Dear Larry,

many thanks for the very useful info, unfortunately i have still not solved.

Original stack size in the header was 4096, i set it up growing until
65535, same result, program block and paralize the uclinux system
without any wanring.

I have some doubt,
1) for example about the fact that i see that ti have compiled uclinux
with CodeSourcery toolchain (i did it some time ago don't remember
exactly the reason now), can this be an issue ? Anyway, actually i am
compiling my c++ program with this same toolchain (gcc 4.6.1).
2) could i have some uclinux configuration issues ? In particular i have
doubt on general setup and processor

General Setup:
[*] Prompt for development and/or incomplete code/drivers
() Cross-compiler tool prefix
() Local version - append to kernel release
[*] Automatically append version information to the version string
[*] System V IPC
[ ] POSIX Message Queues
[ ] BSD Process Accounting
[ ] Export task/process statistics through netlink (EXPERIMENTAL)
[ ] Auditing support
RCU Subsystem --->
[ ] Kernel .config support
(14) Kernel log buffer size (16 => 64KB, 17 => 128KB)
[ ] enable deprecated sysfs features to support old userspace tools
[ ] Kernel->user space relay support (formerly relayfs)
[ ] Namespaces support
[ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support
[ ] Optimize for size
[*] Configure standard kernel features (for small systems) --->
Kernel Performance Events And Counters --->
[ ] Enable VM event counters for /proc/vmstat
[*] Enable SLUB debugging support
[*] Disable heap randomization
Choose SLAB allocator (SLUB (Unqueued Allocator)) --->
[ ] Allow mmapped anonymous memory to be uninitialized
[ ] Profiling support
GCOV-based kernel profiling --->

CPU (MCF5307) --->
[*] Enable setting the CPU clock frequency
(90000000) Set the core clock frequency
(2) Set the core/bus clock divide ratio
[ ] Old mask 5307 (1H55J) silicon
*** Platform ***
[*] Sysam AMCORE board support
[ ] Arnewsh 5307 board support
[ ] Motorola M5307C3 board support
[ ] SnapGear SecureEdge/MP3 platform support
[ ] Feith CLEOPATRA board support
[ ] SecureEdge/NETtel board support
[*] Support for U-Boot command line parameters
[*] Use 4Kb for kernel stacks instead of 8Kb
*** RAM configuration ***
(0) Address of the base of RAM
(0x1000000) Size of RAM (in bytes), or 0 for automatic
(0x0) Address of the base of system vectors
(0x20000) Address of the base of kernel code
RAM bus width (AUTO) --->
*** ROM configuration ***
[ ] Specify ROM linker regions
Kernel executes from (RAM) --->
Preemption Model (No Forced Preemption (Server)) --->
Memory model (Flat Memory) --->
(1) Turn on mmap() excess space trimming before booting

Do you see something strange here ?

I go on investingating,

Many thanks,
angelo

Post by Larry Baker
Angelo,
This sounds like your application stack size is too small and you are
overflowing the stack. Remember, uClinux has no MMU to protect for
that. Try increasing the stack size. Ted Ma told me once the
application flthdr can manipulate the stack size in the executable's

Hi Larry,
flthdr is the utility to manipulate the header
====
The flat format also defines the stack size for an application as a
field in the flat header. To increase the stack allocated to an
application, a simple change of this field is all that is required.
flthdr -s flat-executable
The flat format also allows two compression options. The entire
executable can be compressed, providing maximum ROM savings. It also
offers the often useful side effect that the application is loaded
entirely into a contiguous RAM block. You also may choose
data-segment-only compression. This is important if you want to save
flthdr -z flat-executable
creates a fully compressed executable, and
flthdr -d flat-executable
compresses only the data segment.
====
...MaTed

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov <mailto:baker at usgs.gov>

Dear all,
i have a small board with a coldfire mcf5307, 4 MB flash and 16MB sdram.
~ # cat /proc/version
uClinux version 2.6.36.2 (angelo at angel3) (gcc version 4.6.1 (Sourcery
CodeBench Lite 2011.09-23) ) #122 Fri Dec 14 23:52:01 CET 2012
I am now trying to upload and run a simple c++ program, with just 3 simple classes,
and a main().
Fist issue,
I tried to use the most recent uclinux.org <http://uclinux.org>
supplied toolchanin (m68k-uclinux-20101118),
make
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c
-o obj/base64.o src/base64.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c
-o obj/main.o src/main.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall -c
-o obj/sha256.o src/sha256.cc
/usr/local/bin/m68k-uclinux-g++ obj/base64.o obj/main.o obj/sha256.o
-m5307 -o bin/cfbm -Wl,-Map,bin/cfbm.map
ERROR: text=0x1c100 overlaps data=0x0 ?
collect2: ld returned 1 exit status
make: *** [bin/cfbm] Error 1
Surfing the net, i don't find any good explaination to this, and the common workaround
suggested is to use the CodeSourcery toolchain.
So as a first thing i was wondering if the uclinux "user" folder does contain some cpp
projects, how do they compile ?
Then i moved to the CodeSourcery toolchain, that i copied from an old hard disk, since
seems is not free to download anymore, is it ? Are there any
alternative ?
With this toolchain strange things happen, until a certain point, adding code, everything
works fine, program is correctly compiled on my host and executed on the board. Then,
strangely, as the code increase, the program execution crash (without errors on console)
and paralize the system. As i remove (comment out) some lines, ini random places, program
start to work correctly again.
So for now, also the CodeSourcery toolchain solution is not helping me.
I have now the suspect that uClinux itself has not been correctly
configured, or that i am
suffering for my 16MB of ram, even if i see 6,8MB still free before executing.
~ # cat /proc/meminfo
MemTotal: 13684 kB
MemFree: 6984 kB
Buffers: 16 kB
Cached: 144 kB
SwapCached: 0 kB
Active: 64 kB
Inactive: 48 kB
Active(anon): 0 kB
Inactive(anon): 0 kB
Active(file): 64 kB
Inactive(file): 48 kB
Unevictable: 0 kB
Mlocked: 0 kB
MmapCopy: 412 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 40 kB
Writeback: 0 kB
AnonPages: 0 kB
Mapped: 0 kB
Shmem: 0 kB
Slab: 1292 kB
SReclaimable: 64 kB
SUnreclaim: 1228 kB
KernelStack: 108 kB
PageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6840 kB
Committed_AS: 0 kB
VmallocTotal: 0 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
I don't know actually how to move, every help is accepted.
Many thanks,
angelo
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org <mailto:uClinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20140123/7358f46b/attachment.html>

Larry Baker

2014-01-24 21:50:12 UTC

Permalink

Angelo,

My most frustrating experience with uClinux was with the memory allocator. Linux uses a "buddy" system power-of-2 allocator. It is VERY easy to fragment memory such that no more can be allocated. Usually I received an error message, which you say does not happen for you. Perhaps that is because in my case, the memory allocation failure occurs during program loading, while yours occurs during program execution (C++ startup vs. a plain C program?).

The current memory free list is in /proc/buddyinfo. Memory is organized into blocks by powers-of-2. The first one is the 2^0 * PAGESIZE. PAGESIZE is 4096 on x86 systems. To find out the PAGESIZE, try "getconf PAGESIZE" or "getconf PAGE_SIZE" (unless someone on the list knows what it is for a coldfire mcf5307). Even if there are, for example, 6 MB free memory and your program only needs 5 MB, you won't be able to run your program, because the next higher power-of-2 is 8 MB.

Maybe this is what is happening to you. I moved on to using SoC ARM chips with lots more RAM and MMUs because I was wasting so much time trying to squeeze a program to fit in an uClinux system.

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

Post by Angelo Dureghello
Dear Larry,
many thanks for the very useful info, unfortunately i have still not solved.
Original stack size in the header was 4096, i set it up growing until 65535, same result, program block and paralize the uclinux system without any wanring.
I have some doubt,
1) for example about the fact that i see that ti have compiled uclinux with CodeSourcery toolchain (i did it some time ago don't remember exactly the reason now), can this be an issue ? Anyway, actually i am compiling my c++ program with this same toolchain (gcc 4.6.1).
2) could i have some uclinux configuration issues ? In particular i have doubt on general setup and processor
[*] Prompt for development and/or incomplete code/drivers
() Cross-compiler tool prefix
() Local version - append to kernel release
[*] Automatically append version information to the version string
[*] System V IPC
[ ] POSIX Message Queues
[ ] BSD Process Accounting
[ ] Export task/process statistics through netlink (EXPERIMENTAL)
[ ] Auditing support
RCU Subsystem --->
[ ] Kernel .config support
(14) Kernel log buffer size (16 => 64KB, 17 => 128KB)
[ ] enable deprecated sysfs features to support old userspace tools
[ ] Kernel->user space relay support (formerly relayfs)
[ ] Namespaces support
[ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support
[ ] Optimize for size
[*] Configure standard kernel features (for small systems) --->
Kernel Performance Events And Counters --->
[ ] Enable VM event counters for /proc/vmstat
[*] Enable SLUB debugging support
[*] Disable heap randomization
Choose SLAB allocator (SLUB (Unqueued Allocator)) --->
[ ] Allow mmapped anonymous memory to be uninitialized
[ ] Profiling support
GCOV-based kernel profiling --->
CPU (MCF5307) --->
[*] Enable setting the CPU clock frequency
(90000000) Set the core clock frequency
(2) Set the core/bus clock divide ratio
[ ] Old mask 5307 (1H55J) silicon
*** Platform ***
[*] Sysam AMCORE board support
[ ] Arnewsh 5307 board support
[ ] Motorola M5307C3 board support
[ ] SnapGear SecureEdge/MP3 platform support
[ ] Feith CLEOPATRA board support
[ ] SecureEdge/NETtel board support
[*] Support for U-Boot command line parameters
[*] Use 4Kb for kernel stacks instead of 8Kb
*** RAM configuration ***
(0) Address of the base of RAM
(0x1000000) Size of RAM (in bytes), or 0 for automatic
(0x0) Address of the base of system vectors
(0x20000) Address of the base of kernel code
RAM bus width (AUTO) --->
*** ROM configuration ***
[ ] Specify ROM linker regions
Kernel executes from (RAM) --->
Preemption Model (No Forced Preemption (Server)) --->
Memory model (Flat Memory) --->
(1) Turn on mmap() excess space trimming before booting
Do you see something strange here ?
I go on investingating,
Many thanks,
angelo

Post by Larry Baker
Angelo,

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20140124/2765c7e5/attachment.html>

Angelo Dureghello

2014-01-27 17:06:36 UTC

Permalink

Dear Larry and all,

many thanks for your kind reply,

i enabled all the kernel debug / dump support options i found, but still
my application, together with the kernel, locks silently, blocking the
whole system without any message. Once the system is locked, i don't
have any network or console access anymore.

/var/tmp # cat /proc/buddyinfo
Node 0, zone DMA 1 6 16 5 3 5 3
1 0 0 1
/var/tmp #

My application in c++ has now about 500K, shouldn't be a memory space
problem.

/var/tmp # ls
cfbm jffs2
/var/tmp # ls -al
drwxr-xr-x 3 root 0 1024 Jan 14 17:36 .
drwxr-xr-x 6 root 0 1024 Jan 14 17:27 ..
-rwxr-xr-x 1 root 0 580956 Jan 14 17:36 cfbm
drwxr-xr-x 6 root 0 0 Jan 1 1970 jffs2
/var/tmp # cat /proc/meminfo
MemTotal: 13560 kB
MemFree: 5988 kB
Buffers: 28 kB
Cached: 724 kB
SwapCached: 0 kB
Active: 128 kB

/var/tmp # ./cfbm
s 1
s 2
s 3
s 6

After launching the app, i just see some traces i "cout" and then the
whole system stops.
Some time i see "s6" trace, some time "s3"only.

Strangely, i never had any issue with C apps until now, but they are
generally much smaller.

Regards,
Angelo

Post by Larry Baker
Angelo,
My most frustrating experience with uClinux was with the memory
allocator. Linux uses a "buddy" system power-of-2 allocator. It is
VERY easy to fragment memory such that no more can be allocated.
Usually I received an error message, which you say does not happen
for you. Perhaps that is because in my case, the memory allocation
failure occurs during program loading, while yours occurs during
program execution (C++ startup vs. a plain C program?).
The current memory free list is in . Memory is organized into blocks
by powers-of-2. The first one is the 2^0 * PAGESIZE. PAGESIZE is
4096 on x86 systems. To find out the PAGESIZE, try "getconf PAGESIZE"
or "getconf PAGE_SIZE" (unless someone on the list knows what it is
for a coldfire mcf5307). Even if there are, for example, 6 MB free
memory and your program only needs 5 MB, you won't be able to run your
program, because the next higher power-of-2 is 8 MB.
Maybe this is what is happening to you. I moved on to using SoC ARM
chips with lots more RAM and MMUs because I was wasting so much time
trying to squeeze a program to fit in an uClinux system.
Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov <mailto:baker at usgs.gov>

Post by Angelo Dureghello
Dear Larry,
many thanks for the very useful info, unfortunately i have still not solved.
Original stack size in the header was 4096, i set it up growing until
65535, same result, program block and paralize the uclinux system
without any wanring.
I have some doubt,
1) for example about the fact that i see that ti have compiled
uclinux with CodeSourcery toolchain (i did it some time ago don't
remember exactly the reason now), can this be an issue ? Anyway,
actually i am compiling my c++ program with this same toolchain (gcc
4.6.1).
2) could i have some uclinux configuration issues ? In particular i
have doubt on general setup and processor
[*] Prompt for development and/or incomplete code/drivers
() Cross-compiler tool prefix
() Local version - append to kernel release
[*] Automatically append version information to the version string
[*] System V IPC
[ ] POSIX Message Queues
[ ] BSD Process Accounting
[ ] Export task/process statistics through netlink (EXPERIMENTAL)
[ ] Auditing support
RCU Subsystem --->
[ ] Kernel .config support
(14) Kernel log buffer size (16 => 64KB, 17 => 128KB)
[ ] enable deprecated sysfs features to support old userspace tools
[ ] Kernel->user space relay support (formerly relayfs)
[ ] Namespaces support
[ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support
[ ] Optimize for size
[*] Configure standard kernel features (for small systems) --->
Kernel Performance Events And Counters --->
[ ] Enable VM event counters for /proc/vmstat
[*] Enable SLUB debugging support
[*] Disable heap randomization
Choose SLAB allocator (SLUB (Unqueued Allocator)) --->
[ ] Allow mmapped anonymous memory to be uninitialized
[ ] Profiling support
GCOV-based kernel profiling --->
CPU (MCF5307) --->
[*] Enable setting the CPU clock frequency
(90000000) Set the core clock frequency
(2) Set the core/bus clock divide ratio
[ ] Old mask 5307 (1H55J) silicon
*** Platform ***
[*] Sysam AMCORE board support
[ ] Arnewsh 5307 board support
[ ] Motorola M5307C3 board support
[ ] SnapGear SecureEdge/MP3 platform support
[ ] Feith CLEOPATRA board support
[ ] SecureEdge/NETtel board support
[*] Support for U-Boot command line parameters
[*] Use 4Kb for kernel stacks instead of 8Kb
*** RAM configuration ***
(0) Address of the base of RAM
(0x1000000) Size of RAM (in bytes), or 0 for automatic
(0x0) Address of the base of system vectors
(0x20000) Address of the base of kernel code
RAM bus width (AUTO) --->
*** ROM configuration ***
[ ] Specify ROM linker regions
Kernel executes from (RAM) --->
Preemption Model (No Forced Preemption (Server)) --->
Memory model (Flat Memory) --->
(1) Turn on mmap() excess space trimming before booting
Do you see something strange here ?
I go on investingating,
Many thanks,
angelo

Post by Larry Baker
Angelo,
This sounds like your application stack size is too small and you
are overflowing the stack. Remember, uClinux has no MMU to protect
for that. Try increasing the stack size. Ted Ma told me once the
application flthdr can manipulate the stack size in the executable's

Hi Larry,
flthdr is the utility to manipulate the header
====
The flat format also defines the stack size for an application as a
field in the flat header. To increase the stack allocated to an
application, a simple change of this field is all that is required.
flthdr -s flat-executable
The flat format also allows two compression options. The entire
executable can be compressed, providing maximum ROM savings. It
also offers the often useful side effect that the application is
loaded entirely into a contiguous RAM block. You also may choose
data-segment-only compression. This is important if you want to
flthdr -z flat-executable
creates a fully compressed executable, and
flthdr -d flat-executable
compresses only the data segment.
====
...MaTed

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov <mailto:baker at usgs.gov>

Dear all,
i have a small board with a coldfire mcf5307, 4 MB flash and 16MB sdram.
~ # cat /proc/version
uClinux version 2.6.36.2 (angelo at angel3) (gcc version 4.6.1
(Sourcery CodeBench Lite 2011.09-23) ) #122 Fri Dec 14 23:52:01 CET
2012
I am now trying to upload and run a simple c++ program, with just 3 simple classes,
and a main().
Fist issue,
I tried to use the most recent uclinux.org <http://uclinux.org/>
supplied toolchanin (m68k-uclinux-20101118),
make
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall
-c -o obj/base64.o src/base64.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall
-c -o obj/main.o src/main.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall
-c -o obj/sha256.o src/sha256.cc
/usr/local/bin/m68k-uclinux-g++ obj/base64.o obj/main.o
obj/sha256.o -m5307 -o bin/cfbm -Wl,-Map,bin/cfbm.map
ERROR: text=0x1c100 overlaps data=0x0 ?
collect2: ld returned 1 exit status
make: *** [bin/cfbm] Error 1
Surfing the net, i don't find any good explaination to this, and
the common workaround
suggested is to use the CodeSourcery toolchain.
So as a first thing i was wondering if the uclinux "user" folder
does contain some cpp
projects, how do they compile ?
Then i moved to the CodeSourcery toolchain, that i copied from an
old hard disk, since
seems is not free to download anymore, is it ? Are there any alternative ?
With this toolchain strange things happen, until a certain point,
adding code, everything
works fine, program is correctly compiled on my host and executed on the board. Then,
strangely, as the code increase, the program execution crash
(without errors on console)
and paralize the system. As i remove (comment out) some lines, ini
random places, program
start to work correctly again.
So for now, also the CodeSourcery toolchain solution is not helping me.
I have now the suspect that uClinux itself has not been correctly
configured, or that i am
suffering for my 16MB of ram, even if i see 6,8MB still free before executing.
~ # cat /proc/meminfo
MemTotal: 13684 kB
MemFree: 6984 kB
Buffers: 16 kB
Cached: 144 kB
SwapCached: 0 kB
Active: 64 kB
Inactive: 48 kB
Active(anon): 0 kB
Inactive(anon): 0 kB
Active(file): 64 kB
Inactive(file): 48 kB
Unevictable: 0 kB
Mlocked: 0 kB
MmapCopy: 412 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 40 kB
Writeback: 0 kB
AnonPages: 0 kB
Mapped: 0 kB
Shmem: 0 kB
Slab: 1292 kB
SReclaimable: 64 kB
SUnreclaim: 1228 kB
KernelStack: 108 kB
PageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6840 kB
Committed_AS: 0 kB
VmallocTotal: 0 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
I don't know actually how to move, every help is accepted.
Many thanks,
angelo
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org <mailto:uClinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20140127/1382e994/attachment.html>

Angelo Dureghello

2014-01-27 17:33:58 UTC

Permalink

Dear Brian and all,

thanks for your help,

below the output of "size" on 3 objects of my cpp app,
seems correct since i only have a global object for logging purpose
inside main.o.

#[ obj ] [ 18:26:43 ]
#size main.o
text data bss dec hex filename
13483 8 70 13561 34f9 main.o

#[ obj ] [ 18:26:46 ]
#size base64.o
text data bss dec hex filename
812 0 0 812 32c base64.o

#[ obj ] [ 18:26:58 ]
#size sha256.o
text data bss dec hex filename
2190 0 0 2190 88e sha256.o

I tried as you asked to keep "top" open launching the app,
it also paralize, without any update, as below.

Mem: 7772K used, 5788K free, 0K shrd, 28K buff, 728K cached
CPU: 0% usr 1% sys 0% nice 97% idle 0% io 0% irq 0% softirq
Load average: 0.00 0.00 0.00
PID PPID USER STAT VSZ %MEM %CPU COMMAND
64 62 root R 287 2% 3% top
48 1 root S 292 2% 0% -/bin/sh
45 1 root S 288 2% 0% telnetd -l /bin/sh
62 45 root S 286 2% 0% /bin/sh
1 0 root S 285 2% 0% init
47 1 root S 285 2% 0% inetd
43 1 root S 285 2% 0% ?ttpd -h /home/httpd
50 47 root S 117 1% 0% -l
51 47 root S 117 1% 0% -l
57 2 root SW 0 0% 0% [flush-1:0]
13 2 root SW 0 0% 0% [kworker/0:1]
2 0 root SW 0 0% 0% [kthreadd]
3 2 root SW 0 0% 0% [ksoftirqd/0]
12 2 root SW 0 0% 0% [mtdblock0]
5 2 root SW 0 0% 0% [kworker/u:0]
16 2 root SW 0 0% 0% [mtdblock3]
17 2 root SW< 0 0% 0% [kpsmoused]
6 2 root SW< 0 0% 0% [khelper]
7 2 root SW 0 0% 0% [sync_supers]
8 2 root SW 0 0% 0% [bdi-default]

Best regards
Angelo

/Angelo --/
Run *size* on your executable to see how much BSS storage is
required. From my G++ 2.7.3 days, global C++ objects were actually in
the data segment, even if no initialization was done....
Also, can you get a second console connected, maybe via telnet? If
you run *vmstat* ( or dear, that's UNIX not Linux, sorry I don't know
the equiv ) and have it refresh often. Or put "cat /proc/meminfo" in
a loop of every 3 seconds or so and see how your physical memory is
changing. Also *top* provides similar info.
just some ideas. I'm a VM linux person, not ucLinux.
take care,
*brianW
On Mon, Jan 27, 2014 at 9:06 AM, Angelo Dureghello <angelo70 at gmail.com
Dear Larry and all,
many thanks for your kind reply,
i enabled all the kernel debug / dump support options i found, but
still my application, together with the kernel, locks silently,
blocking the whole system without any message. Once the system is
locked, i don't have any network or console access anymore.
/var/tmp # cat /proc/buddyinfo
Node 0, zone DMA 1 6 16 5 3 5
3 1 0 0 1
/var/tmp #
My application in c++ has now about 500K, shouldn't be a memory
space problem.
/var/tmp # ls
cfbm jffs2
/var/tmp # ls -al
drwxr-xr-x 3 root 0 1024 Jan 14 17:36 .
drwxr-xr-x 6 root 0 1024 Jan 14 17:27 ..
-rwxr-xr-x 1 root 0 580956 Jan 14 17:36 cfbm
drwxr-xr-x 6 root 0 0 Jan 1 1970 jffs2
/var/tmp # cat /proc/meminfo
MemTotal: 13560 kB
MemFree: 5988 kB
Buffers: 28 kB
Cached: 724 kB
SwapCached: 0 kB
Active: 128 kB
/var/tmp # ./cfbm
s 1
s 2
s 3
s 6
After launching the app, i just see some traces i "cout" and then
the whole system stops.
Some time i see "s6" trace, some time "s3"only.
Strangely, i never had any issue with C apps until now, but they
are generally much smaller.
Regards,
Angelo

Post by Larry Baker
Angelo,
My most frustrating experience with uClinux was with the memory
allocator. Linux uses a "buddy" system power-of-2 allocator. It
is VERY easy to fragment memory such that no more can be
allocated. Usually I received an error message, which you say
does not happen for you. Perhaps that is because in my case, the
memory allocation failure occurs during program loading, while
yours occurs during program execution (C++ startup vs. a plain C
program?).
The current memory free list is in . Memory is organized into
blocks by powers-of-2. The first one is the 2^0 * PAGESIZE.
PAGESIZE is 4096 on x86 systems. To find out the PAGESIZE, try
"getconf PAGESIZE" or "getconf PAGE_SIZE" (unless someone on the
list knows what it is for a coldfire mcf5307). Even if there
are, for example, 6 MB free memory and your program only needs 5
MB, you won't be able to run your program, because the next
higher power-of-2 is 8 MB.
Maybe this is what is happening to you. I moved on to using SoC
ARM chips with lots more RAM and MMUs because I was wasting so
much time trying to squeeze a program to fit in an uClinux system.
Larry Baker
US Geological Survey
650-329-5608 <tel:650-329-5608>
baker at usgs.gov <mailto:baker at usgs.gov>

Post by Angelo Dureghello
Dear Larry,
many thanks for the very useful info, unfortunately i have still not solved.
Original stack size in the header was 4096, i set it up growing
until 65535, same result, program block and paralize the uclinux
system without any wanring.
I have some doubt,
1) for example about the fact that i see that ti have compiled
uclinux with CodeSourcery toolchain (i did it some time ago
don't remember exactly the reason now), can this be an issue ?
Anyway, actually i am compiling my c++ program with this same
toolchain (gcc 4.6.1).
2) could i have some uclinux configuration issues ? In
particular i have doubt on general setup and processor
[*] Prompt for development and/or incomplete code/drivers
() Cross-compiler tool prefix
() Local version - append to kernel release
[*] Automatically append version information to the version string
[*] System V IPC
[ ] POSIX Message Queues
[ ] BSD Process Accounting
[ ] Export task/process statistics through netlink (EXPERIMENTAL)
[ ] Auditing support
RCU Subsystem --->
[ ] Kernel .config support
(14) Kernel log buffer size (16 => 64KB, 17 => 128KB)
[ ] enable deprecated sysfs features to support old userspace tools
[ ] Kernel->user space relay support (formerly relayfs)
[ ] Namespaces support
[ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support
[ ] Optimize for size
[*] Configure standard kernel features (for small systems) --->
Kernel Performance Events And Counters --->
[ ] Enable VM event counters for /proc/vmstat
[*] Enable SLUB debugging support
[*] Disable heap randomization
Choose SLAB allocator (SLUB (Unqueued Allocator)) --->
[ ] Allow mmapped anonymous memory to be uninitialized
[ ] Profiling support
GCOV-based kernel profiling --->
CPU (MCF5307) --->
[*] Enable setting the CPU clock frequency
(90000000) Set the core clock frequency
(2) Set the core/bus clock divide ratio
[ ] Old mask 5307 (1H55J) silicon
*** Platform ***
[*] Sysam AMCORE board support
[ ] Arnewsh 5307 board support
[ ] Motorola M5307C3 board support
[ ] SnapGear SecureEdge/MP3 platform support
[ ] Feith CLEOPATRA board support
[ ] SecureEdge/NETtel board support
[*] Support for U-Boot command line parameters
[*] Use 4Kb for kernel stacks instead of 8Kb
*** RAM configuration ***
(0) Address of the base of RAM
(0x1000000) Size of RAM (in bytes), or 0 for automatic
(0x0) Address of the base of system vectors
(0x20000) Address of the base of kernel code
RAM bus width (AUTO) --->
*** ROM configuration ***
[ ] Specify ROM linker regions
Kernel executes from (RAM) --->
Preemption Model (No Forced Preemption (Server)) --->
Memory model (Flat Memory) --->
(1) Turn on mmap() excess space trimming before booting
Do you see something strange here ?
I go on investingating,
Many thanks,
angelo

Post by Larry Baker
Angelo,
This sounds like your application stack size is too small and
you are overflowing the stack. Remember, uClinux has no MMU to
protect for that. Try increasing the stack size. Ted Ma told
me once the application flthdr can manipulate the stack size in

Hi Larry,
flthdr is the utility to manipulate the header
====
The flat format also defines the stack size for an application
as a field in the flat header. To increase the stack allocated
to an application, a simple change of this field is all that
flthdr -s flat-executable
The flat format also allows two compression options. The
entire executable can be compressed, providing maximum ROM
savings. It also offers the often useful side effect that the
application is loaded entirely into a contiguous RAM block.
You also may choose data-segment-only compression. This is
important if you want to save ROM space but still want the
flthdr -z flat-executable
creates a fully compressed executable, and
flthdr -d flat-executable
compresses only the data segment.
====
...MaTed

Larry Baker
US Geological Survey
650-329-5608 <tel:650-329-5608>
baker at usgs.gov <mailto:baker at usgs.gov>

Dear all,
i have a small board with a coldfire mcf5307, 4 MB flash and 16MB sdram.
~ # cat /proc/version
uClinux version 2.6.36.2 (angelo at angel3) (gcc version 4.6.1
(Sourcery CodeBench Lite 2011.09-23) ) #122 Fri Dec 14
23:52:01 CET 2012
I am now trying to upload and run a simple c++ program, with
just 3 simple classes,
and a main().
Fist issue,
I tried to use the most recent uclinux.org
<http://uclinux.org/> supplied toolchanin
(m68k-uclinux-20101118),
make
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude
-Wall -c -o obj/base64.o src/base64.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude
-Wall -c -o obj/main.o src/main.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude
-Wall -c -o obj/sha256.o src/sha256.cc
/usr/local/bin/m68k-uclinux-g++ obj/base64.o obj/main.o
obj/sha256.o -m5307 -o bin/cfbm -Wl,-Map,bin/cfbm.map
ERROR: text=0x1c100 overlaps data=0x0 ?
collect2: ld returned 1 exit status
make: *** [bin/cfbm] Error 1
Surfing the net, i don't find any good explaination to this,
and the common workaround
suggested is to use the CodeSourcery toolchain.
So as a first thing i was wondering if the uclinux "user"
folder does contain some cpp
projects, how do they compile ?
Then i moved to the CodeSourcery toolchain, that i copied from
an old hard disk, since
seems is not free to download anymore, is it ? Are there any alternative ?
With this toolchain strange things happen, until a certain
point, adding code, everything
works fine, program is correctly compiled on my host and
executed on the board. Then,
strangely, as the code increase, the program execution crash
(without errors on console)
and paralize the system. As i remove (comment out) some lines,
ini random places, program
start to work correctly again.
So for now, also the CodeSourcery toolchain solution is not helping me.
I have now the suspect that uClinux itself has not been
correctly configured, or that i am
suffering for my 16MB of ram, even if i see 6,8MB still free
before executing.
~ # cat /proc/meminfo
MemTotal: 13684 kB
MemFree: 6984 kB
Buffers: 16 kB
Cached: 144 kB
SwapCached: 0 kB
Active: 64 kB
Inactive: 48 kB
Active(anon): 0 kB
Inactive(anon): 0 kB
Active(file): 64 kB
Inactive(file): 48 kB
Unevictable: 0 kB
Mlocked: 0 kB
MmapCopy: 412 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 40 kB
Writeback: 0 kB
AnonPages: 0 kB
Mapped: 0 kB
Shmem: 0 kB
Slab: 1292 kB
SReclaimable: 64 kB
SUnreclaim: 1228 kB
KernelStack: 108 kB
PageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6840 kB
Committed_AS: 0 kB
VmallocTotal: 0 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
I don't know actually how to move, every help is accepted.
Many thanks,
angelo
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org <mailto:uClinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
<mailto:uclinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/options/uclinux-dev

_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org <mailto:uClinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
<mailto:uclinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/options/uclinux-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20140127/f018d802/attachment.html>

Larry Baker

2014-01-28 19:38:07 UTC

Permalink

Angelo,

Try leaving off the -Wl-M... option when you use the uClinux toolchain. That assumes you do not need a map. If you do, you might have to manually run ld to generate that.

The last Code Sourcery ColdFire gcc I worked with can be downloaded from https://sourcery.mentor.com/public/gnu_toolchain/m68k-uclinux/freescale-coldfire-2011.09-23-m68k-uclinux-i686-pc-linux-gnu.tar.bz2. I could not see ColdFire listed any longer on the Lite Edition web page, http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition, so that may or may not be the last release.

You may have to use gdb to track down the location of your problem. Here's an article about setting up a remote gdb debugger session: http://luv.asn.au/overheads/embedded/Debugging_uClinux_on_Coldfire.pdf.

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

Post by Larry Baker
Angelo,

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20140128/16d06b69/attachment.html>

Angelo Dureghello

2014-02-13 00:30:28 UTC

Permalink

Dear all,

thanks for all the support,

i could get back working on this, seems the issue was in my code, i was
someway breaking the memory with a bad pointer.

I am now only confused now about the fact that uClinux die (blocks
completely) silently in this case, if this is normal.

Many thanks
Angelo

Post by Larry Baker
Angelo,
Try leaving off the -Wl-M... option when you use the uClinux
toolchain. That assumes you do not need a map. If you do, you might
have to manually run ld to generate that.
The last Code Sourcery ColdFire gcc I worked with can be downloaded
from
https://sourcery.mentor.com/public/gnu_toolchain/m68k-uclinux/freescale-coldfire-2011.09-23-m68k-uclinux-i686-pc-linux-gnu.tar.bz2.
I could not see ColdFire listed any longer on the Lite Edition web
page,
http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition,
so that may or may not be the last release.
You may have to use gdb to track down the location of your problem.
http://luv.asn.au/overheads/embedded/Debugging_uClinux_on_Coldfire.pdf.
Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov <mailto:baker at usgs.gov>

Post by Angelo Dureghello
Dear Larry,
many thanks for the very useful info, unfortunately i have still not solved.
Original stack size in the header was 4096, i set it up growing until
65535, same result, program block and paralize the uclinux system
without any wanring.
I have some doubt,
1) for example about the fact that i see that ti have compiled
uclinux with CodeSourcery toolchain (i did it some time ago don't
remember exactly the reason now), can this be an issue ? Anyway,
actually i am compiling my c++ program with this same toolchain (gcc
4.6.1).
2) could i have some uclinux configuration issues ? In particular i
have doubt on general setup and processor
[*] Prompt for development and/or incomplete code/drivers
() Cross-compiler tool prefix
() Local version - append to kernel release
[*] Automatically append version information to the version string
[*] System V IPC
[ ] POSIX Message Queues
[ ] BSD Process Accounting
[ ] Export task/process statistics through netlink (EXPERIMENTAL)
[ ] Auditing support
RCU Subsystem --->
[ ] Kernel .config support
(14) Kernel log buffer size (16 => 64KB, 17 => 128KB)
[ ] enable deprecated sysfs features to support old userspace tools
[ ] Kernel->user space relay support (formerly relayfs)
[ ] Namespaces support
[ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support
[ ] Optimize for size
[*] Configure standard kernel features (for small systems) --->
Kernel Performance Events And Counters --->
[ ] Enable VM event counters for /proc/vmstat
[*] Enable SLUB debugging support
[*] Disable heap randomization
Choose SLAB allocator (SLUB (Unqueued Allocator)) --->
[ ] Allow mmapped anonymous memory to be uninitialized
[ ] Profiling support
GCOV-based kernel profiling --->
CPU (MCF5307) --->
[*] Enable setting the CPU clock frequency
(90000000) Set the core clock frequency
(2) Set the core/bus clock divide ratio
[ ] Old mask 5307 (1H55J) silicon
*** Platform ***
[*] Sysam AMCORE board support
[ ] Arnewsh 5307 board support
[ ] Motorola M5307C3 board support
[ ] SnapGear SecureEdge/MP3 platform support
[ ] Feith CLEOPATRA board support
[ ] SecureEdge/NETtel board support
[*] Support for U-Boot command line parameters
[*] Use 4Kb for kernel stacks instead of 8Kb
*** RAM configuration ***
(0) Address of the base of RAM
(0x1000000) Size of RAM (in bytes), or 0 for automatic
(0x0) Address of the base of system vectors
(0x20000) Address of the base of kernel code
RAM bus width (AUTO) --->
*** ROM configuration ***
[ ] Specify ROM linker regions
Kernel executes from (RAM) --->
Preemption Model (No Forced Preemption (Server)) --->
Memory model (Flat Memory) --->
(1) Turn on mmap() excess space trimming before booting
Do you see something strange here ?
I go on investingating,
Many thanks,
angelo

Post by Larry Baker
Angelo,
This sounds like your application stack size is too small and you
are overflowing the stack. Remember, uClinux has no MMU to protect
for that. Try increasing the stack size. Ted Ma told me once the
application flthdr can manipulate the stack size in the executable's

Hi Larry,
flthdr is the utility to manipulate the header
====
The flat format also defines the stack size for an application as a
field in the flat header. To increase the stack allocated to an
application, a simple change of this field is all that is required.
flthdr -s flat-executable
The flat format also allows two compression options. The entire
executable can be compressed, providing maximum ROM savings. It
also offers the often useful side effect that the application is
loaded entirely into a contiguous RAM block. You also may choose
data-segment-only compression. This is important if you want to
flthdr -z flat-executable
creates a fully compressed executable, and
flthdr -d flat-executable
compresses only the data segment.
====
...MaTed

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov <mailto:baker at usgs.gov>

Dear all,
i have a small board with a coldfire mcf5307, 4 MB flash and 16MB sdram.
~ # cat /proc/version
uClinux version 2.6.36.2 (angelo at angel3) (gcc version 4.6.1
(Sourcery CodeBench Lite 2011.09-23) ) #122 Fri Dec 14 23:52:01 CET
2012
I am now trying to upload and run a simple c++ program, with just 3 simple classes,
and a main().
Fist issue,
I tried to use the most recent uclinux.org <http://uclinux.org/>
supplied toolchanin (m68k-uclinux-20101118),
make
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall
-c -o obj/base64.o src/base64.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall
-c -o obj/main.o src/main.cc
/usr/local/bin/m68k-uclinux-g++ -O2 --pipe -m5307 -Iinclude -Wall
-c -o obj/sha256.o src/sha256.cc
/usr/local/bin/m68k-uclinux-g++ obj/base64.o obj/main.o
obj/sha256.o -m5307 -o bin/cfbm -Wl,-Map,bin/cfbm.map
ERROR: text=0x1c100 overlaps data=0x0 ?
collect2: ld returned 1 exit status
make: *** [bin/cfbm] Error 1
Surfing the net, i don't find any good explaination to this, and
the common workaround
suggested is to use the CodeSourcery toolchain.
So as a first thing i was wondering if the uclinux "user" folder
does contain some cpp
projects, how do they compile ?
Then i moved to the CodeSourcery toolchain, that i copied from an
old hard disk, since
seems is not free to download anymore, is it ? Are there any alternative ?
With this toolchain strange things happen, until a certain point,
adding code, everything
works fine, program is correctly compiled on my host and executed on the board. Then,
strangely, as the code increase, the program execution crash
(without errors on console)
and paralize the system. As i remove (comment out) some lines, ini
random places, program
start to work correctly again.
So for now, also the CodeSourcery toolchain solution is not helping me.
I have now the suspect that uClinux itself has not been correctly
configured, or that i am
suffering for my 16MB of ram, even if i see 6,8MB still free before executing.
~ # cat /proc/meminfo
MemTotal: 13684 kB
MemFree: 6984 kB
Buffers: 16 kB
Cached: 144 kB
SwapCached: 0 kB
Active: 64 kB
Inactive: 48 kB
Active(anon): 0 kB
Inactive(anon): 0 kB
Active(file): 64 kB
Inactive(file): 48 kB
Unevictable: 0 kB
Mlocked: 0 kB
MmapCopy: 412 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 40 kB
Writeback: 0 kB
AnonPages: 0 kB
Mapped: 0 kB
Shmem: 0 kB
Slab: 1292 kB
SReclaimable: 64 kB
SUnreclaim: 1228 kB
KernelStack: 108 kB
PageTables: 0 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 6840 kB
Committed_AS: 0 kB
VmallocTotal: 0 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
I don't know actually how to move, every help is accepted.
Many thanks,
angelo
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org <mailto:uClinux-dev at uclinux.org>
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20140213/f8995180/attachment.html>

Larry Baker

2014-02-13 01:01:58 UTC

Permalink

Angelo,

I am now only confused now about the fact that uClinux die (blocks completely) silently in this case, if this is normal.

Yes, this is indeed what can happen on a system like uClinux that does not have an MMU (memory management unit). The tiny controller chips that uClinux targets do not protect any part of the memory from being accidentally corrupted. As long as the memory being accessed exists, there is no hardware fence between a user program and the rest of memory. In a system that does have an MMU, accesses out of the bounds of an executing program cause an illegal access violation and the operating system will normally kill the program. Without such protection, any program can clobber the memory of any other program or the operating system, with unpredictable results -- usually a failure of some kind. Languages like C make it particularly easy to do.

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

Dear all,
thanks for all the support,
i could get back working on this, seems the issue was in my code, i was someway breaking the memory with a bad pointer.
I am now only confused now about the fact that uClinux die (blocks completely) silently in this case, if this is normal.
Many thanks
Angelo

Post by Larry Baker
Angelo,
Try leaving off the -Wl-M... option when you use the uClinux toolchain. That assumes you do not need a map. If you do, you might have to manually run ld to generate that.
The last Code Sourcery ColdFire gcc I worked with can be downloaded from https://sourcery.mentor.com/public/gnu_toolchain/m68k-uclinux/freescale-coldfire-2011.09-23-m68k-uclinux-i686-pc-linux-gnu.tar.bz2. I could not see ColdFire listed any longer on the Lite Edition web page, http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition, so that may or may not be the last release.
You may have to use gdb to track down the location of your problem. Here's an article about setting up a remote gdb debugger session: http://luv.asn.au/overheads/embedded/Debugging_uClinux_on_Coldfire.pdf.
Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

Post by Larry Baker
Angelo,

Larry Baker
US Geological Survey
650-329-5608
baker at usgs.gov

_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/options/uclinux-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20140212/768f0b5c/attachment.html>

Gavin Lambert

2014-02-13 02:29:40 UTC

Permalink

Post by Larry Baker
Yes, this is indeed what can happen on a system like uClinux that does
not have an MMU (memory management unit). ?The tiny controller chips
that uClinux targets do not protect any part of the memory from being
accidentally corrupted. ?As long as the memory being accessed exists,
there is no hardware fence between a user program and the rest of memory.

It's especially fun when address 0 is valid memory (which is not uncommon).
Then you don't get crashes from null pointer accesses, which most developers
expect (and some can be lazy about protecting against, thinking that they'll
find it during debugging).

I always try to configure the target device's memory map such that addresses
near 0 remain invalid, whenever possible -- but some targets don't support
that.

Angelo Dureghello

2014-02-13 08:37:12 UTC

Permalink

That was exactly my case, a null pointer, and ram starts from 0x0 in the
map :).
I will keep in mind this thing for the future.

Still thanks.

Regards
Angelo

Post by Gavin Lambert

Post by Larry Baker
Yes, this is indeed what can happen on a system like uClinux that does
not have an MMU (memory management unit). The tiny controller chips
that uClinux targets do not protect any part of the memory from being
accidentally corrupted. As long as the memory being accessed exists,
there is no hardware fence between a user program and the rest of memory.

It's especially fun when address 0 is valid memory (which is not uncommon).
Then you don't get crashes from null pointer accesses, which most developers
expect (and some can be lazy about protecting against, thinking that they'll
find it during debugging).
I always try to configure the target device's memory map such that addresses
near 0 remain invalid, whenever possible -- but some targets don't support
that.

Steve deRosier

2014-02-13 16:41:59 UTC

Permalink

Also there's macros in Linux that return/test for errors via setting
pointers to values < 4096. Because "these addresses are NEVER valid".
;) Not sure how uCLinux deals with this, other than people avoiding
putting valid memory address near 0.

Just another challenge with micros.

That was exactly my case, a null pointer, and ram starts from 0x0 in the map
:).
I will keep in mind this thing for the future.
Still thanks.
Regards
Angelo

Post by Gavin Lambert

It's especially fun when address 0 is valid memory (which is not uncommon).
Then you don't get crashes from null pointer accesses, which most developers
expect (and some can be lazy about protecting against, thinking that they'll
find it during debugging).
I always try to configure the target device's memory map such that addresses
near 0 remain invalid, whenever possible -- but some targets don't support
that.