This is the mail archive of the
ecos-devel@sources.redhat.com
mailing list for the eCos project.
RE:RE problem with gcc3.2 compiler
- From: Ottawa Guy <ottawaguy81 at yahoo dot com>
- To: Gary Thomas <gary at mlbassoc dot com>, Jonathan Larmour <jifl at eCosCentric dot com>
- Cc: Jani Monoses <jani at iv dot ro>, ecos-devel at sources dot redhat dot com
- Date: Fri, 24 Oct 2003 09:32:19 -0700 (PDT)
- Subject: RE:RE problem with gcc3.2 compiler
Hi,
Looking around in the gcc.gnu.org. It seems some one
from RedHat disabled "-finit-priority" and made this
option default.
Now I am bit puzzled why my simple program doesnt
work. I am using ecos example program "twothreads.c".
This program works fine on gcc3.2, however when I add
"malloc" to my code, my simulator just hangs.
If I compile the same code with gcc2.95 (with malloc),
there is no problem. Since malloc needs constructor
class, I thought "init-priority" is my problem.
I think my problem lies somewhere else. Thanks to
everyone who have responded.
I compile my code with following option. The program
compiles fine and runs fine.
sparc-elf-gcc hello.c -o hello1.out -L./install/lib
-I./install/include -Ttarget.ld -nostdlib -I./
-Wl,--gc-sections
Now I think my problem lies in linking. When I compile
the program without "-Wl,--gc-sections" I get the
following warning and my program fails
sparc-elf-gcc hello.c -o hello1.out -L./install/lib
-I./install/include -Ttarget.ld -nostdlib -I./
/opt/gnutools/bin/../lib/gcc-lib/sparc-elf/3.2.2/../../../../sparc-elf/bin/ld:
warning: no memory region specified for section
`.ram_vectors'
My mlt_sparc_leon_ram.ldi file looks following. I am
only running code from the ram. There is no flash.
MEMORY
{
ram : ORIGIN = 0x40000000, LENGTH = 0x80000
}
SECTIONS
{
SECTIONS_BEGIN
SECTION_rom_vectors (ram, 0x40000000, LMA_EQ_VMA)
SECTION_text (ram, ALIGN (0x1), LMA_EQ_VMA)
SECTION_fini (ram, ALIGN (0x1), LMA_EQ_VMA)
SECTION_rodata (ram, ALIGN (0x1), LMA_EQ_VMA)
SECTION_rodata1 (ram, ALIGN (0x1), LMA_EQ_VMA)
SECTION_fixup (ram, ALIGN (0x1), LMA_EQ_VMA)
SECTION_gcc_except_table (ram, ALIGN (0x1),
LMA_EQ_VMA)
SECTION_data (ram, ALIGN (0x1), LMA_EQ_VMA)
SECTION_bss (ram, ALIGN (0x8), LMA_EQ_VMA)
CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
SECTIONS_END
}
Can someone tell me what I am doing wrong.
Hadi
--- Gary Thomas <gary@mlbassoc.com> wrote:
> On Fri, 2003-10-24 at 08:29, Jonathan Larmour wrote:
> > Gary Thomas wrote:
> > > On Fri, 2003-10-24 at 06:07, Jani Monoses wrote:
> > >
> > >>>That's really too bad - we can't take it out
> globally because that
> > >>>could possibly break things for folks using
> older compilers and we
> > >>>may have troubles using newer ones..
> > >>>
> > >>>The proverbial rock and hard place :-(
> > >>
> > >>Would a cdl option for the compiler version used
> be too ugly?
> > >
> > >
> > > We don't have very good handling of options like
> this. Also, sadly,
> > > the compiler options are somewhat spread around
> rather than being
> > > localized (e.g. in the architecture HAL only).
> Currently there
> > > are 96! occurrences of -finit-priority, so
> making any change in this
> > > area will be non-trivial.
> > >
> > > We recently made some changes in the makefile
> rule template. Perhaps
> > > we could just make a similar one for this case.
> >
> > As Bart was only just recently saying, the only
> real alternative is to
> > have a step that at the beginning of the build
> runs $(COMMAND_PREFIX)gcc
> > --version and parses the output, and adjusts the
> makefile options
> > accordingly. Icky.
> >
> > Something along these lines:
> >
> > I just tested this mini-makefile which works fine:
> >
>
COMMAND_PREFIX=/opt/ecos/gnutools/arm-elf/bin/arm-elf-
> >
> > COMPILERVER := $(shell $(COMMAND_PREFIX)gcc
> --version | head -1 | cut -f3
> > -d " ")
> > COMPILERMAJOR := $(shell echo $(COMPILERVER) | cut
> -f1 -d .)
> > COMPILERMINOR := $(shell echo $(COMPILERVER) | cut
> -f2 -d .)
> > COMPILERPATCHLEVEL := $(shell echo $(COMPILERVER)
> | cut -f3 -d .)
> >
> > all:
> > echo $(COMPILERMAJOR) $(COMPILERMINOR)
> $(COMPILERPATCHLEVEL)
> >
> > If y'all (Hi Bart) is happy that this is the way
> to do it, I'll put the
> > appropriate stuff in pkgconf/rules.mak
> >
>
> My concern with this is that you need to run at
> least 6 additional
> processes for every makefile invocation. Sounds
> like a lot of overhead.
>
> --
> Gary Thomas <gary@mlbassoc.com>
> MLB Associates
>
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com