This is the mail archive of the ecos-devel@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]