Query

Query

[Bansal, Shashank]

Hi,

I wished to create some large dimensional arrays in a program (6000x1000)
and it fails to upload this memory (stack overflow). As soon as i reduce the
dimension of arrays..it works perfectly.
Could u help me out. I have tried this on different machines.  
Could you also tell if I could create virtual memory or somethign of that
sort for the program.

Thanks a lot
Shashank

Query

[Bansal, Shashank]

Hi,

I wished to create some large dimensional arrays in a program (6000x1000)
and it fails to upload this memory (stack overflow). As soon as i reduce the
dimension of arrays..it works perfectly.
Could u help me out. I have tried this on different machines.  
Could you also tell if I could create virtual memory or somethign of that
sort for the program.

Thanks a lot
Shashank

Re: Query

[Jack Lloyd]

On Thu, 6 Dec 2001, Bansal, Shashank wrote:

> Hi,
>
> I wished to create some large dimensional arrays in a program (6000x1000)
> and it fails to upload this memory (stack overflow). As soon as i reduce the
> dimension of arrays..it works perfectly.

Most likely you have a limit in place that limits the size of your stack.
Assuming you're running on a Unix system, try running the command `ulimit
-s`; that will tell you how much stack space you can allocate. You may be
able to raise this limit.

6000x1000x4 (array of ints), is about 22 megabytes. I suppose it is
possible that some machines and/or operating systems will not let you use
this much stack space ever.

> Could u help me out. I have tried this on different machines.
> Could you also tell if I could create virtual memory or somethign of that
> sort for the program.

The best solution is probably to use the C malloc function or the C++ new
operator to create the memory, or use C++'s vector<> type.

-Jack

Re: Query

[Tim Prince]

----- Original Message -----
From: "Jack Lloyd" <lloyd@acm.jhu.edu>
To: "Bansal, Shashank" <Shashank.Bansal@Dresdner-Bank.com>
Cc: <gcc@gcc.gnu.org>
Sent: Thursday, December 06, 2001 5:15 AM
Subject: Re: Query


> On Thu, 6 Dec 2001, Bansal, Shashank wrote:
>
> > Hi,
> >
> > I wished to create some large dimensional arrays in a program
(6000x1000)
> > and it fails to upload this memory (stack overflow). As soon as i reduce
the
> > dimension of arrays..it works perfectly.
>
> Most likely you have a limit in place that limits the size of your stack.
> Assuming you're running on a Unix system, try running the command `ulimit
> -s`; that will tell you how much stack space you can allocate. You may be
> able to raise this limit.
>
> 6000x1000x4 (array of ints), is about 22 megabytes. I suppose it is
> possible that some machines and/or operating systems will not let you use
> this much stack space ever.
>
> > Could u help me out. I have tried this on different machines.
> > Could you also tell if I could create virtual memory or somethign of
that
> > sort for the program.
>
> The best solution is probably to use the C malloc function or the C++ new
> operator to create the memory, or use C++'s vector<> type.
>
> -Jack
>
Current stock linux distributions have a fixed 8MB stack limit.  Not long
ago it was 1MB.  A scheme to adjust this, including ulimit, as Jack
describes, and a re-configuration parameter, are sorely needed.  In
addition, compilers need a scheme such as the one planned for g95, where
objects above a certain size (threshold set by a compiler option), are
automatically put on the heap. Top quality Unix compilers have such a
scheme.  The current situation, where code has to be modified with explicit
use of malloc() in order to port to linux from Unix or Windows, is
unsatisfactory.

Query

[Andrew Haley]

Vijay Kamath writes:
 > Forgive me, if this is not the right address for this question, atleast 
 > direct me to the right place.
 > I'm having gcc version 3.2 release 7 that comes with Redhat 8.0 . I find 
 > that the option -fcheck-memory-usage is missing. I couldn't find 
 > information about this anywhere on the net. Could you please tell me 
 > what happened to this option?

Quoth Oliva: "Basically, it just didn't work any more, and it was
decided to take it out to not create false expectations.  If anyone
feels like resurrecting this feature, the patch that took the feature
out can always be used as a starting point"

http://gcc.gnu.org/ml/gcc/2002-02/msg00666.html
http://gcc.gnu.org/ml/gcc-patches/2001-12/msg00587.html


Andrew.

Query

[Vijay Kamath]

Forgive me, if this is not the right address for this question, atleast 
direct me to the right place.
I'm having gcc version 3.2 release 7 that comes with Redhat 8.0 . I find 
that the option -fcheck-memory-usage is missing. I couldn't find 
information about this anywhere on the net. Could you please tell me 
what happened to this option?

Thanks.

Regards... Vijay

Re: query

[Andrea 'Fyre Wyzard' Bocci]

At 05.12 02/03/2002 (GMT +0000), sunil suhas petwe wrote:
>hello sir,
>   we are using gcc C compiler with at90s8515, and facing some problems.
>please send me your support address where, I can submit my queries.

GCC is a volounteer-driven project, so there isn't really a "support" address.
You can try asking for help on gcc-help@gcc.gnu.org, and see if sombody 
knows how to help you.

fwyzard

query

[sunil suhas petwe]

hello sir,
   we are using gcc C compiler with at90s8515, and facing some 
problems.
please send me your support address where, I can submit my 
queries.

Re: Query...

[Philip Blundell]

>Can OBJ's, created by older ELF spec., be linked with GCC-linker which
>uses newer ELF spec.?

Yes.  But:

>-------/bin/ld : Error : strlen.o compiled for EABI version 0, whereas
>MN1.out is compiled for version 2.
>File format not recognized : failed to merge target specific data of file
>............./lin/libc.a (strlen.o)

The problem here seems to be that MN1.out (presumably the object you built 
with ADS) is using a *newer* version of the EABI than the linker understands.  
I didn't realise there even was a "version 2"; I don't think the GNU tools 
cope with version 1 properly yet.

p.

Re: Query...

[MNShukla]

Hi Nick,

Nick Clifton wrote:

> Hi Shukla,
>
> > I am generating obj files by using ARM-gcc, gcc-for-PC(intel) and
> > ARM-ADS. I am getting difference in the ELF-header, the values of
> > EI_PAD of e_ident[] is as follows--
> >
> > EI_PAD = 0x61 for ARM-gcc and
> > EI_PAD = 0x00 for ARM-ADS and PC-gcc.
> >
> > Can somebody point me what does it signify?
>
> You are looking at an old version of the ELF spec.  That field
> (e_ident[7]) is now called EI_OSABI, and the EI_PAD field is now two
> bytes further on.
>
> The EI_OSABI field is used to distinguish binaries for the same
> architecture but which target different Operating Systems and/or
> different Application Binary Interfaces.  A value of 0 means "default"
> or "uninitialised".  A value of 0x61 (or 97 in decimal) is defined in
> the spec as:
>
>   #define ELFOSABI_ARM   97     /* ARM */
>
> In the case of GCC this field is being used to distinguish between
> binaries built by old versions of gcc (which set the field to 0)
> and new(er) versions of gcc.  The older versions did not implement the
> ARM ELF ABI correctly, and so the linker has to work around this
> problem, provided that it can detect the old binaries.
>

Can OBJ's, created by older ELF spec., be linked with GCC-linker which
uses newer ELF spec.?
Actually, I want to create OBJ's by using ARM-ADS(v1.1) and link it with
arm-linux-gcc.

>
> > Now, if I want to link obj's generated by ARM-ADS with obj generated
> > by ARM-gcc, it is not able to link and says format different.
>
> What, precisely, is the error message that you are receiving ?
>

The error messages areas---
-------/bin/ld : Error : strlen.o compiled for EABI version 0, whereas
MN1.out is compiled for version 2.
File format not recognized : failed to merge target specific data of file
............./lin/libc.a (strlen.o)

-------/bin/ld : Error : write.o compiled for EABI version 0, whereas
MN1.out is compiled for version 2.
File format not recognized : failed to merge target specific data of file
............./lin/libc.a (write.o)

-------/bin/ld : Error : fflush.o compiled for EABI version 0, whereas
MN1.out is compiled for version 2.
File format not recognized : failed to merge target specific data of file
............./lin/libc.a (fflush.o)

-------/bin/ld : Error : freer.o compiled for EABI version 0, whereas
MN1.out is compiled for version 2.
File format not recognized : failed to merge target specific data of file
............./lin/libc.a (freer.o)

-------/bin/ld : Error : lseeker.o compiled for EABI version 0, whereas
MN1.out is compiled for version 2.
File format not recognized : failed to merge target specific data of file
............./lin/libc.a (lseeker.o)
---------------
---------------
---------------

With Best Regards,

Shukla
(Mahesh Narain Shukla)

Re: Query...

[Toshi Morita]

> Hi,
> 
> I am generating obj files by using ARM-gcc, gcc-for-PC(intel) and
> ARM-ADS. I am getting difference in the ELF-header, the values of EI_PAD
> of e_ident[] is as follows--
> 
> EI_PAD = 0x61 for ARM-gcc and
> EI_PAD = 0x00 for ARM-ADS and PC-gcc.
> 
> Can somebody point me what does it signify?
> Now, if I want to link obj's generated by ARM-ADS with obj generated by
> ARM-gcc, it is not able to link and says format difeerent.

GCC doesn't generate binary file formats. That is the job
of the assembler, which is not a part of the GCC package.

You need to ask this on the binutils mailing list.

Toshi

Re: Query...

[Nick Clifton]

Hi Shukla,

> I am generating obj files by using ARM-gcc, gcc-for-PC(intel) and 
> ARM-ADS. I am getting difference in the ELF-header, the values of
> EI_PAD of e_ident[] is as follows--
> 
> EI_PAD = 0x61 for ARM-gcc and
> EI_PAD = 0x00 for ARM-ADS and PC-gcc.
> 
> Can somebody point me what does it signify?

You are looking at an old version of the ELF spec.  That field
(e_ident[7]) is now called EI_OSABI, and the EI_PAD field is now two
bytes further on.

The EI_OSABI field is used to distinguish binaries for the same
architecture but which target different Operating Systems and/or
different Application Binary Interfaces.  A value of 0 means "default"
or "uninitialised".  A value of 0x61 (or 97 in decimal) is defined in
the spec as:

  #define ELFOSABI_ARM   97	/* ARM */

In the case of GCC this field is being used to distinguish between
binaries built by old versions of gcc (which set the field to 0)
and new(er) versions of gcc.  The older versions did not implement the
ARM ELF ABI correctly, and so the linker has to work around this
problem, provided that it can detect the old binaries.

> Now, if I want to link obj's generated by ARM-ADS with obj generated
> by ARM-gcc, it is not able to link and says format different.

What, precisely, is the error message that you are receiving ?

Cheers
        Nick

Query...

[MNShukla]

Hi,

I am generating obj files by using ARM-gcc, gcc-for-PC(intel) and
ARM-ADS. I am getting difference in the ELF-header, the values of EI_PAD
of e_ident[] is as follows--

EI_PAD = 0x61 for ARM-gcc and
EI_PAD = 0x00 for ARM-ADS and PC-gcc.

Can somebody point me what does it signify?
Now, if I want to link obj's generated by ARM-ADS with obj generated by
ARM-gcc, it is not able to link and says format difeerent.

Can somebody point me about the documents (or explain me) for ELF
standard used in ARM-GCC.

Thanking in Advance.........

Regards,
Shukla
(Mahesh Narain Shukla)

Re: Query

[Philip Blundell]

>I cross compiled Linux and the OS (Linux) is working fine. Now, I am
>cross compiling an Application with  for ARM-SDT compiler and generating
>an image in elf format and when I run it on ARM board (with Linux OS),
>it gives memory violation -- this may be because of non static linking
>(as there is no linker option in ARM-SDT for static linking).

I thought the ARM tools only supported static linking.  Your problem is more 
likely to be that the application base address is wrong, or you are linking 
with the wrong set of libraries and startup files.

>Is there any utility to convert object files in AOF format to ELF
>format??

I don't think so.  I believe the latest version of the SDT can write ELF 
object files - interworking with the GNU tools is not 100%, but for a simple 
static binary it should be OK.

p.

Re: Query

[Richard Earnshaw]

> Hi,
> 
>  I am using gcc for ArmLinux obtained from following site:
> arm-linux-cross.tar.bz2  from
> http://www.lart.tudelft.nl/lartware/compile-tools/ (LARTware Compiler
> tools)
> 
> I cross compiled Linux and the OS (Linux) is working fine. Now, I am
> cross compiling an Application with  for ARM-SDT compiler and generating
> an image in elf format and when I run it on ARM board (with Linux OS),
> it gives memory violation -- this may be because of non static linking
> (as there is no linker option in ARM-SDT for static linking). So I tried
> to cross-compile the applicatin and I wanted to link it by gcc - linker
> but I am not able to do it. This is because ARM-SDT generate object file
> in AOF format.
> 
> Is there any utility to convert object files in AOF format to ELF
> format??

I'm not aware of any.  The latest ARM SDT tools (well, ADS anyway) 
generate ELF images.  There are tools which convert from ELF to AOF, but 
not vice versa.

Query

[MNShukla]

Hi,

 I am using gcc for ArmLinux obtained from following site:
arm-linux-cross.tar.bz2  from
http://www.lart.tudelft.nl/lartware/compile-tools/ (LARTware Compiler
tools)

I cross compiled Linux and the OS (Linux) is working fine. Now, I am
cross compiling an Application with  for ARM-SDT compiler and generating
an image in elf format and when I run it on ARM board (with Linux OS),
it gives memory violation -- this may be because of non static linking
(as there is no linker option in ARM-SDT for static linking). So I tried
to cross-compile the applicatin and I wanted to link it by gcc - linker
but I am not able to do it. This is because ARM-SDT generate object file
in AOF format.

Is there any utility to convert object files in AOF format to ELF
format??

Thanks in advance...

M.N.Shukla