ARM-ELF -> PE-COFF with objcopy

ARM-ELF -> PE-COFF with objcopy

[pps]

Hello everybody,
I have source for a voice codec and I want to evaluate performance 
difference if compiled with different compilers. Target device is WinCE 
6.0 HTC smartphone (which is arm11).
I decided to try RVCT which produces elf objects, but for wince I need coff.
So, one of the options I have is to convert elf to coff with objcopy.
I downloaded latest binutils and compiled it with support for all 
targets. Then I did this:
objcopy.exe -I elf32-littlearm -O pe-arm-wince-little test.o test.obj
test.cpp was just extern "C" int add(int a, int b) { return a + b; }
Then I tried to link produced test.obj and it doesn't work.

I use VS2008 and the error is: test.obj : fatal error LNK1136: invalid 
or corrupt file

Then I tried to do it different way. First I converted test.o to 
symbolsrec format and then from symbolsrec I converted to 
pe-arm-wince-little. In this case I was able to link to the test.obj, 
but the executable crashes:
         int X2 = add(X, Y);
00011068  ldr         r1, Y, #0x28
0001106C  ldr         r0, X, #0x2C
00011070  bl          |WinMain + 0xfffff000 ( 10000h )|  <- crash

Other than that I tried to use objcopy from gnuarm, codesourcery and 
cegcc distributions hoping that it would work with other binaries but in 
all cases I couldn't get it working.

I also noticed that after I tried to remove some symbols from 
pe-arm-wince-little with strip VS linker would reject updated object 
file as currupted. SO, I think there is some problem in arm-coff part of 
BFD.

Can anybody comment on that, or suggest what I should try?
Thanks

Re: ARM-ELF -> PE-COFF with objcopy

[Nick Clifton]

Hi pps,

> Can anybody comment on that, or suggest what I should try?

Don't try to convert the object file, instead try converting the fully 
linked executable.

The problem is that object files contain relocations and objcopy is not 
really able to translate these between different file format types.

Cheers
   Nick

Re: ARM-ELF -> PE-COFF with objcopy

[pps]

Nick Clifton wrote:
> Don't try to convert the object file, instead try converting the fully 
> linked executable.
> 
> The problem is that object files contain relocations and objcopy is not 
> really able to translate these between different file format types.
> 

I've seen that objcopy can't do so reliably. In my case the speech codec 
lib has zero dependencies on any libc functions and all it has is a 
bunch of extern "C" functions and const static tables. So, I was 
thinking that this should be the simplest case and I decided to try it.

Since the entire app can't be compiled by RVCT, then I need to compile 
speech codec as a shared library and then convert that shared lib to 
dll, right?

Re: ARM-ELF -> PE-COFF with objcopy

[i-love-spam]

27.04.09, 20:33, "pps" <i-love-spam@yandex.ru>:
> Nick Clifton wrote:
> > Don't try to convert the object file, instead try converting the fully 
> > linked executable.
> > 
> > The problem is that object files contain relocations and objcopy is not 
> > really able to translate these between different file format types.
> > 
> I've seen that objcopy can't do so reliably. In my case the speech codec 
> lib has zero dependencies on any libc functions and all it has is a 
> bunch of extern "C" functions and const static tables. So, I was 
> thinking that this should be the simplest case and I decided to try it.
> Since the entire app can't be compiled by RVCT, then I need to compile 
> speech codec as a shared library and then convert that shared lib to 
> dll, right?


I'm completely lost, seems that objcopy can't do anything related to elf->coff properly.
test.cpp:
__declspec(dllexport) int add(int a, int b){ return a+b; }

then:
armcc --cpu=6 -Otime -O3 --shared --apcs=/fpic test.cpp
and 
objcopy.exe  -I elf32-littlearm -O pei-arm-wince-little __image.axf testi.dll
objcopy.exe  -I elf32-littlearm -O pe-arm-wince-little __image.axf test.dll

Then on wince app I tried to load testi.dll and test.dll and In both cases it fails 
with ERROR_BAD_EXE_FORMAT.

I also tried to open the dlls with dependencywalker and test.dll is completely corrupt, whereas test.dll can be opened, but dependencywalker shows that it doesn't export anything. test.dll doesn't even have regular MZ header. In any case, it appears that elf->conf doesn't work for binaries also.

Did I do something incorrectly?

Re: ARM-ELF -> PE-COFF with objcopy

[Ian Lance Taylor]

"i-love-spam" <i-love-spam@yandex.ru> writes:

> I'm completely lost, seems that objcopy can't do anything related to elf->coff properly.
> test.cpp:
> __declspec(dllexport) int add(int a, int b){ return a+b; }
>
> then:
> armcc --cpu=6 -Otime -O3 --shared --apcs=/fpic test.cpp
> and 
> objcopy.exe  -I elf32-littlearm -O pei-arm-wince-little __image.axf testi.dll
> objcopy.exe  -I elf32-littlearm -O pe-arm-wince-little __image.axf test.dll

objcopy is definitely not going to be able to convert an ELF shared
library into a PE DLL.  I don't think that is programmatically possible,
becuase they use very different models for accessing globally visible
functions and variables.

objcopy might be able to convert a statically linked ELF executable into
PE format.

Ian

Re: ARM-ELF -> PE-COFF with objcopy

[i-love-spam]

> "i-love-spam" <i-love-spam@yandex.ru> writes:
> > I'm completely lost, seems that objcopy can't do anything related to elf->coff properly.
> > test.cpp:
> > __declspec(dllexport) int add(int a, int b){ return a+b; }
> >
> > then:
> > armcc --cpu=6 -Otime -O3 --shared --apcs=/fpic test.cpp
> > and 
> > objcopy.exe  -I elf32-littlearm -O pei-arm-wince-little __image.axf testi.dll
> > objcopy.exe  -I elf32-littlearm -O pe-arm-wince-little __image.axf test.dll
> objcopy is definitely not going to be able to convert an ELF shared
> library into a PE DLL.  I don't think that is programmatically possible,
> becuase they use very different models for accessing globally visible
> functions and variables.
> objcopy might be able to convert a statically linked ELF executable into
> PE format.
> Ian

Well, in case if it's only possible to convert ELF executable how is that could be useful in my case?.. 
I want to test codec performance and for that I need to make millions of function calls in a loop to measure performance. In the ELF binary obviously I can't use anything that's os specific (file access for example). Or can I if I link to dynamic libc? The only possibility in this case is to embedde binary data into executable and process it by the executable. In this case I can't verify the output (unless I embed expected output also)
Maybe there are some other alternatives? Or maybe I could write a tool myself that dumps symbols into symbolsrec and then properly creates windll? I could build my code by VS and then simply replace chunks of machine code in that dll

Re: ARM-ELF -> PE-COFF with objcopy

[Nick Clifton]

Hi

> Well, in case if it's only possible to convert 
> ELF executable how is that could be useful in my case?.. 

It cannot.  In this case you are going to need to recompile your codec 
from the source code using a PE targeted toolchain.

Cheers
   Nick

Re: ARM-ELF -> PE-COFF with objcopy

[i-love-spam]

 > Well, in case if it's only possible to convert 
> > ELF executable how is that could be useful in my case?.. 
> It cannot.  In this case you are going to need to recompile your codec 
> from the source code using a PE targeted toolchain.
> Cheers
>    Nick


Well, I wrote a dummy app, converted it and guess what... it doesn't work like everything else....

Re: ARM-ELF -> PE-COFF with objcopy

[Nick Clifton]

Hi,

>> It cannot.  In this case you are going to need to recompile your codec 
>> from the source code using a PE targeted toolchain.

> Well, I wrote a dummy app, converted it and guess what... it doesn't work like everything else....

Ah, but my point was that you should not be trying to convert it at all. 
  You should be trying to compile a native app for your target system.

Cheers
   Nick

Re: ARM-ELF -> PE-COFF with objcopy

[i-love-spam]

I tried some stuff and I noticed that if I pack and unpack .dll with upx they aren't identical anymore.
if I try to:
arm-mingw32ce-strip.exe -s mydll.dll

and then if I try to use upx I get this error in red color:
upx: mydll.dll: InternalError: FIXME: soxrelocs != assumed_soxrelocs

I downloaded upx src and there is no such code with this error message! Any ideas what could be wrong? Is that strip corrupts the dll?

By the way, strip -s means "Remove all symbol and relocation information", what kind of impact does it have on the final release binary is it ok to do it or better not to?

Thanks

Re: ARM-ELF -> PE-COFF with objcopy

[Dave Korn]

i-love-spam wrote:
> I tried some stuff and I noticed that if I pack and unpack .dll with upx
> they aren't identical anymore. if I try to: arm-mingw32ce-strip.exe -s
> mydll.dll
> 
> and then if I try to use upx I get this error in red color: upx: mydll.dll:
> InternalError: FIXME: soxrelocs != assumed_soxrelocs
> 
> I downloaded upx src and there is no such code with this error message! Any
> ideas what could be wrong? Is that strip corrupts the dll?

  It could conceivably be a problem related to long section name handlings.
Can you send a copy me the original DLL (off list)?

> By the way, strip -s means "Remove all symbol and relocation information",
> what kind of impact does it have on the final release binary is it ok to do
> it or better not to?

  Well the obvious thing is that your end-users won't be able to debug it; you
might want to leave the choice up to them, or ship both versions.  I imagine
disk/flash space on the final devices is quite limited and you might want to
strip DLLs to conserve space, but do you also work with em/simulators that
have more space where debuggable versions would be an advantage?


    cheers,
      DaveK

Re: ARM-ELF -> PE-COFF with objcopy

[Ian Lance Taylor]

"i-love-spam" <i-love-spam@yandex.ru> writes:

>> objcopy is definitely not going to be able to convert an ELF shared
>> library into a PE DLL.  I don't think that is programmatically possible,
>> becuase they use very different models for accessing globally visible
>> functions and variables.
>> objcopy might be able to convert a statically linked ELF executable into
>> PE format.
>> Ian
>
> Well, in case if it's only possible to convert ELF executable how is that could be useful in my case?.. 
> I want to test codec performance and for that I need to make millions of function calls in a loop to measure performance. In the ELF binary obviously I can't use anything that's os specific (file access for example). Or can I if I link to dynamic libc? The only possibility in this case is to embedde binary data into executable and process it by the executable. In this case I can't verify the output (unless I embed expected output also)
> Maybe there are some other alternatives? Or maybe I could write a tool myself that dumps symbols into symbolsrec and then properly creates windll? I could build my code by VS and then simply replace chunks of machine code in that dll

I don't really understand what you are trying to do or why you are using
ELF at all.  Why not just compile your code into PE format in the first
place?

The only realistic way that you can create a PE DLL is to compile code
with a PE compiler.  Otherwise you aren't going to get the right code
sequences and relocations.  It is theoretically possible to pursue other
paths but they are all going to be complex and difficult.

Ian

Re: ARM-ELF -> PE-COFF with objcopy

[Dave Korn]

Ian Lance Taylor wrote:

> I don't really understand what you are trying to do or why you are using
> ELF at all.  Why not just compile your code into PE format in the first
> place?
> 
> The only realistic way that you can create a PE DLL is to compile code
> with a PE compiler.  Otherwise you aren't going to get the right code
> sequences and relocations.  It is theoretically possible to pursue other
> paths but they are all going to be complex and difficult.

  What about this whole ELF->PE post-linking stuff that symbian arm-eabi
targets apparently do?  Could that be adapted for wince?

    cheers,
      DaveK

Re: ARM-ELF -> PE-COFF with objcopy

[pps]

Dave Korn wrote:
> Ian Lance Taylor wrote:
> 
>> I don't really understand what you are trying to do or why you are using
>> ELF at all.  Why not just compile your code into PE format in the first
>> place?

It's all simple, I wrote an optimized version of a voice codec (amr-nb) 
for arm. In our project performance of the codec is *very* important, 
because on a simple mobile we need to decode and encode realtime 
multiple speech streams simultaneously (project requirement). We 
obtained a commercial product from one of the companies and they charge 
for it around 15-25K for optimized version for arm-wince. I have lots of 
experience working with voice codecs and I was given a task to try to 
optimize it even more. So far, I already beat the comercial version by 
around 20% while my implementation is more conformant to the specs (bit 
exact).
With MS compiler I'm quite limited in ARM instructionset, it even 
rejects some of the asm functions and it doesn't support inline 
assembler in wince. While inspecting produced assembly listing I see 
some room for improvement. So, I decided to try some other compilers and 
see if the results are worse or better. I didn't even try gcc-ce yet, 
because I don't think it would be able to beat ms compiler in 
optimizations; the RVCT from arm.com seems to be a good choice in my 
case - it's ARM only compiler and optimized for arm architecture. I also 
was curious myself which one of them would generate better code. The 
only problem is that it generates ELF binaries and in wince I need 
pe-coff. I wrote my code in a way that it doesn't have any dependencies, 
it's a bunch of static const tables with data and a few functions. It 
doesn't allocate/free any memory dynamically also. So, I was thinking 
that all I need is to somehow extract the binary code and try to run it :)
I also tried to produce assembly listing with RVCT, but ms assembler for 
arm rejects some of the instructions. Maybe I should try gnu assembler 
from cegcc for that?

>> The only realistic way that you can create a PE DLL is to compile code
>> with a PE compiler.  Otherwise you aren't going to get the right code
>> sequences and relocations.  It is theoretically possible to pursue other
>> paths but they are all going to be complex and difficult.
> 
>   What about this whole ELF->PE post-linking stuff that symbian arm-eabi
> targets apparently do?  Could that be adapted for wince?
> 

Maybe that was on older devices, but right now I checked binaries 
produced for symbian and they are elf, not PE (I check it by opening in 
notepad to see ELF at the beginning :))

What surprises me is this: gcc is able to take lots of lots c++ files, 
preprocess them, compile etc... then link produced object files. It 
understands all the formats, so, why not to take produced object code 
from an ELF object and link it... producing a PE-coff executable??

Re: ARM-ELF -> PE-COFF with objcopy

[Dave Korn]

pps wrote:
> Dave Korn wrote:

>>   What about this whole ELF->PE post-linking stuff that symbian arm-eabi
>> targets apparently do?  Could that be adapted for wince?
>>
> 
> Maybe that was on older devices, but right now I checked binaries
> produced for symbian and they are elf, not PE (I check it by opening in
> notepad to see ELF at the beginning :))

  That's what you'd expect to see before the postlinking process, isn't it?
Well, I don't know much about this stuff, but see

    http://sourceware.org/ml/binutils/2009-04/msg00180.html

and the referenced ARM ABI docs for more info.

    cheers,
      DaveK

Re: ARM-ELF -> PE-COFF with objcopy

[Daniel Jacobowitz]

On Tue, Apr 28, 2009 at 05:17:35PM +0100, Dave Korn wrote:
>   That's what you'd expect to see before the postlinking process, isn't it?

Correct.  The post-linker is part of the Symbian SDK, not part of
binutils.  It's not as complicated as a linker, but not simple either.

-- 
Daniel Jacobowitz
CodeSourcery

Re: ARM-ELF -> PE-COFF with objcopy

[Pedro Alves]

On Tuesday 28 April 2009 17:17:35, Dave Korn wrote:
> pps wrote:
> > Dave Korn wrote:
> 
> >>   What about this whole ELF->PE post-linking stuff that symbian arm-eabi
> >> targets apparently do?  Could that be adapted for wince?
> >>

Thanks, but no thanks.  CE runs on more platforms than just ARM.  It
also runs on x86, MIPS and SH.   Why go through the trouble of
writing an extra indirection layer when you can have the tools
output the native format?  What about binary tool and link
compatibility with the native tools?  Symbian avoids this last
issue, because, well, they *are* the native tools.  Are you
planning on making cygwin or i386-mingw use a post-linking
process? ;-)

> > 
> > Maybe that was on older devices, but right now I checked binaries
> > produced for symbian and they are elf, not PE (I check it by opening in
> > notepad to see ELF at the beginning :))
> 
>   That's what you'd expect to see before the postlinking process, isn't it?
> Well, I don't know much about this stuff, but see
> 
>     http://sourceware.org/ml/binutils/2009-04/msg00180.html

-- 
Pedro Alves

Re: ARM-ELF -> PE-COFF with objcopy

[Daniel Jacobowitz]

On Tue, Apr 28, 2009 at 06:28:56PM +0100, Pedro Alves wrote:
> Thanks, but no thanks.  CE runs on more platforms than just ARM.  It
> also runs on x86, MIPS and SH.   Why go through the trouble of
> writing an extra indirection layer when you can have the tools
> output the native format?  What about binary tool and link
> compatibility with the native tools?  Symbian avoids this last
> issue, because, well, they *are* the native tools.  Are you
> planning on making cygwin or i386-mingw use a post-linking
> process? ;-)

FWIW, it's been suggested several times :-)

-- 
Daniel Jacobowitz
CodeSourcery

Re: ARM-ELF -> PE-COFF with objcopy

[Dave Korn]

Daniel Jacobowitz wrote:
> On Tue, Apr 28, 2009 at 06:28:56PM +0100, Pedro Alves wrote:
>> Thanks, but no thanks.  CE runs on more platforms than just ARM.  It
>> also runs on x86, MIPS and SH.   Why go through the trouble of
>> writing an extra indirection layer when you can have the tools
>> output the native format?  What about binary tool and link
>> compatibility with the native tools?  Symbian avoids this last
>> issue, because, well, they *are* the native tools.  Are you
>> planning on making cygwin or i386-mingw use a post-linking
>> process? ;-)
> 
> FWIW, it's been suggested several times :-)
> 

  Yeah, but it doesn't make the same sense for Cygwin and MinGW, because we
are *not* the native tools; it has always been one of the GNU toolchain's
goals to support interoperation with the native tools and formats on every
supported platform.  I'm currently faced with the dilemma of how to add
support for new features that the native toolchain just won't understand, but
I'd still like to do it in as minimal a way as possible; e.g., I'd like the
native librarian and dumper tools to still work even if the linker can't
handle the objects.  Building a post-processing chain to try and support
semantics that aren't necessarily commensurable with the native format seems
troublesome to me, and I'd much rather support things in a way that if you
don't use the new features, what you get is a completely compatible object.

    cheers,
      DaveK

Re: ARM-ELF -> PE-COFF with objcopy

[pps]

....

Just a little update.
After trying and failing all possible combinations and ideas I decided 
to abandon my idea of converting elf to coff. Right now I'm working on 
some other project and as part of the project I need to compile some 
code with cegcc. I just found out that no matter what and how I build 
anything with cegcc it won't even load on my phone 
(ERROR_BAD_EXE_FORMAT). Exactly the same binary works on emulator just 
fine, but doesn't work on the device and produces data abort if I try to 
LoadLibrary("dll name"). I tried a simple HelloWorld app - same problem. 
So, it's very possible that while I tried to convert elf->coff I had a 
working coff object, but the binary built at the end would never work 
because I used real device for testing. I'll post to cegcc mailing list 
to see if the problem was resolved.

Thanks

Re: ARM-ELF -> PE-COFF with objcopy

[Vincent R.]

On Thu, 07 May 2009 02:58:16 -0400, pps <i-love-spam@yandex.ru> wrote:
> ....
> 
> Just a little update.
> After trying and failing all possible combinations and ideas I decided 
> to abandon my idea of converting elf to coff. Right now I'm working on 
> some other project and as part of the project I need to compile some 
> code with cegcc. I just found out that no matter what and how I build 
> anything with cegcc it won't even load on my phone 
> (ERROR_BAD_EXE_FORMAT). Exactly the same binary works on emulator just 
> fine, but doesn't work on the device and produces data abort if I try to 
> LoadLibrary("dll name"). I tried a simple HelloWorld app - same problem. 
> So, it's very possible that while I tried to convert elf->coff I had a 
> working coff object, but the binary built at the end would never work 
> because I used real device for testing. I'll post to cegcc mailing list 
> to see if the problem was resolved.
> 
> Thanks

If you are testing on a Windows Mobile 6.1 cegcc binaries are not working
because
PE loader is very strict on this platform.
Please give more information on the platform you are testing.

Thanks

Re: ARM-ELF -> PE-COFF with objcopy

[Dave Korn]

Vincent R. wrote:
> On Thu, 07 May 2009 02:58:16 -0400, pps <i-love-spam@> wrote:

>> some other project and as part of the project I need to compile some 
>> code with cegcc. I just found out that no matter what and how I build 
>> anything with cegcc it won't even load on my phone 
>> (ERROR_BAD_EXE_FORMAT). Exactly the same binary works on emulator just 
>> fine, but doesn't work on the device and produces data abort if I try to 
>> LoadLibrary("dll name"). I tried a simple HelloWorld app - same problem. 

> If you are testing on a Windows Mobile 6.1 cegcc binaries are not working
> because PE loader is very strict on this platform.
> Please give more information on the platform you are testing.

  Vincent, does the loader on this platform permit long section names?

    cheers,
      DaveK

Re: ARM-ELF -> PE-COFF with objcopy

[Vincent R.]

On Thu, 07 May 2009 13:38:52 +0100, Dave Korn
<dave.korn.cygwin@googlemail.com> wrote:
> Vincent R. wrote:
>> On Thu, 07 May 2009 02:58:16 -0400, pps <i-love-spam@> wrote:
> 
>>> some other project and as part of the project I need to compile some 
>>> code with cegcc. I just found out that no matter what and how I build 
>>> anything with cegcc it won't even load on my phone 
>>> (ERROR_BAD_EXE_FORMAT). Exactly the same binary works on emulator just 
>>> fine, but doesn't work on the device and produces data abort if I try
to
>>>
>>> LoadLibrary("dll name"). I tried a simple HelloWorld app - same
problem.
>>>
> 
>> If you are testing on a Windows Mobile 6.1 cegcc binaries are not
working
>> because PE loader is very strict on this platform.
>> Please give more information on the platform you are testing.
> 
>   Vincent, does the loader on this platform permit long section names?
> 
>     cheers,
>       DaveK

I don't know if I have time I will test it. 

Re: ARM-ELF -> PE-COFF with objcopy

[pps]

Vincent R. wrote:
> On Thu, 07 May 2009 02:58:16 -0400, pps <i-love-spam@yandex.ru> wrote:
>> ....
>>
>> Just a little update.
>> After trying and failing all possible combinations and ideas I decided 
>> to abandon my idea of converting elf to coff. Right now I'm working on 
>> some other project and as part of the project I need to compile some 
>> code with cegcc. I just found out that no matter what and how I build 
>> anything with cegcc it won't even load on my phone 
>> (ERROR_BAD_EXE_FORMAT). Exactly the same binary works on emulator just 
>> fine, but doesn't work on the device and produces data abort if I try to 
>> LoadLibrary("dll name"). I tried a simple HelloWorld app - same problem. 
>> So, it's very possible that while I tried to convert elf->coff I had a 
>> working coff object, but the binary built at the end would never work 
>> because I used real device for testing. I'll post to cegcc mailing list 
>> to see if the problem was resolved.
>>
>> Thanks
> 
> If you are testing on a Windows Mobile 6.1 cegcc binaries are not working
> because
> PE loader is very strict on this platform.
> Please give more information on the platform you are testing.
> 
> Thanks
> 
> 

Re: ARM-ELF -> PE-COFF with objcopy

[pps]

Vincent R. wrote:
  > If you are testing on a Windows Mobile 6.1 cegcc binaries are not 
working
 > because
 > PE loader is very strict on this platform.
 > Please give more information on the platform you are testing.
 >

phone I use is TyTn2, Win mobile 6.1 (5.2.19212) StrongARM. The device 
comes with ARM1136J-S cpu.
I searched through cegcc mailing list and it appears that I'm not the 
only one who had this problem, and suggested fix it to use upx :)
That fixed all my problems! :)

Re: ARM-ELF -> PE-COFF with objcopy

[Ian Lance Taylor]

pps <i-love-spam@yandex.ru> writes:

> What surprises me is this: gcc is able to take lots of lots c++ files,
> preprocess them, compile etc... then link produced object files. It
> understands all the formats, so, why not to take produced object code 
> from an ELF object and link it... producing a PE-coff executable??

Because the code required for an ELF shared library to function and the
code required for a PE DLL to function are different.  You need to have
the right compiler.  Trying to do the conversion after the compiler has
already run is too late.

Given your problem description, why are you trying to create a DLL at
all?  Why not just create an archive which can be linked directly into
the executable?

Also, RVCT definitely generates smaller code than current gcc, but I
have not heard that it generates code that runs faster.  Since you
apparently only care about runtime performance, not code size, you
should consider trying arm-pe-gcc on your code to see what the
performance is.  gcc is generally competitive with proprietary compilers
on performance.

Ian

Re: ARM-ELF -> PE-COFF with objcopy

[pps]

Ian Lance Taylor wrote:
> Because the code required for an ELF shared library to function and the
> code required for a PE DLL to function are different.  You need to have
> the right compiler.  Trying to do the conversion after the compiler has
> already run is too late.
> 
> Given your problem description, why are you trying to create a DLL at
> all?  Why not just create an archive which can be linked directly into
> the executable?
> 
> Also, RVCT definitely generates smaller code than current gcc, but I
> have not heard that it generates code that runs faster.  Since you
> apparently only care about runtime performance, not code size, you
> should consider trying arm-pe-gcc on your code to see what the
> performance is.  gcc is generally competitive with proprietary compilers
> on performance.
> 
> Ian
> 


I compiled my test program and with RVCT it's almost twice larger than 
with MS compiler.
Initially, off course I wanted to create an arcive (static lib) and link 
to it, but I was told that it's definetly won't work and I should try 
converting executable. The problem is that archive contains ELF object 
files and I need to convert them to COFF. Objcopy converts them, then I 
can objdump converted files to see the symbols, HOWEVER, ms compiler 
rejects them as corrupted - that's the problem.