> -----Original Message-----
> From: Pedro Alves [mailto:pe...@codesourcery.com]
> Sent: March 15, 2010 15:46
> To: cegcc-devel@lists.sourceforge.net; danny.ba...@scarlet.be
> Cc: Pavel Pavlov
> Subject: Re: [Cegcc-devel] Ws2tcpip.h
> 
> On Monday 15 March 2010 19:33:41, Danny Backx wrote:
> > > 3) with -mcpu=cortex-a8 (Assembler messages: Error: cannot
> represent BFD_RELOC_ARM_MOVW relocation in this object file format)
> > >
> > > Does it mean that there is no proper support for newer cpu's in the
> version of binutils that come with cegcc? Is it easier for me to
> upgrade?
> > >
> > > PS: Cmd line used: arm-mingw32ce-gcc -c /tmp/test.c   -mcpu=cortex-
> a8
> >
> 
> This device is a thumb-2 device.  Those are new relocations for forming
> constants from immediates (usually using the movw/movt instruction
> pair), rather than loading the data from the constant pool.  Although
> these are static relocations, PE/COFF doesn't support
> representing them in the .o files.  The easiest way around this is
> disabling these instructions in gcc.  A better solution would be
> to extend bfd and to have a way to represent these relocations,
> as a GNU extension.  Perhaps a new section, or perhaps extend
> the pseudo-relocs concept to static relocations (if we
> need extra relocations in final images, new pseudo-reloc
> kinds are the obvious choice).  An even better solution
> would be for Microsoft to define and officialize new
> relocations for Thumb2, but, probably not going to happen.
> 
> There are simple hooks for disabling those instructions under
> gcc/config/arm.  That said, which that issue out of the way,
> MSFT's compilers doesn't support thumb2 AFAIK.  So, even if the
> code compiles, you're probably going to run into kernel
> issues running it.
> 

But I'm not building for thumb, on the contrary, that code I'm compiling is 
performance sensitive and I don't want to use thumb at all.
MS compilers are way behind gcc in this regard, the latest what they support is 
armv5e. But it doesn't mean that you can't use instructions supported by the 
CPU, right? How is that I'd have kernel issues then? The same way, I used arm6 
code and it all worked without problems, this time I want to try to compile 
some code for snapdragon cpu (I have a couple devices), but it seems like gcc 
won't compile anything for the new instruction set.
By the way... I don't really understand the details you provided regarding 
relocations. To me, when there is a dllimport function used, then in some 
imports section linker places a pointer to that function. That pointer is set 
by the loader at load time. Overall, the code:

#include <windows.h>
int main(int argc, char **argv){
    return (long) &VirtualAlloc;
}

In my understanding is identical to:

static volatile const void * const __imp_VirtualAlloc;
int main(int argc, char **argv){
    return (long) __imp_VirtualAlloc;
}

Test confirms, that it returns the same error. Can I somehow completely disable 
thumb/thumb2 and only use regular arm 32-bit instructions plus neon/simd 
instructions (the ones that I need to execute)

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel

Reply via email to