* ARM-ELF -> PE-COFF with objcopy
@ 2009-04-27 9:45 pps
2009-04-27 14:33 ` Nick Clifton
0 siblings, 1 reply; 27+ messages in thread
From: pps @ 2009-04-27 9:45 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-27 9:45 ARM-ELF -> PE-COFF with objcopy pps
@ 2009-04-27 14:33 ` Nick Clifton
2009-04-27 16:26 ` pps
0 siblings, 1 reply; 27+ messages in thread
From: Nick Clifton @ 2009-04-27 14:33 UTC (permalink / raw)
To: pps; +Cc: binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-27 14:33 ` Nick Clifton
@ 2009-04-27 16:26 ` pps
2009-04-27 21:21 ` i-love-spam
0 siblings, 1 reply; 27+ messages in thread
From: pps @ 2009-04-27 16:26 UTC (permalink / raw)
Cc: binutils
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-27 16:26 ` pps
@ 2009-04-27 21:21 ` i-love-spam
2009-04-27 22:49 ` Ian Lance Taylor
0 siblings, 1 reply; 27+ messages in thread
From: i-love-spam @ 2009-04-27 21:21 UTC (permalink / raw)
To: binutils
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?
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-27 21:21 ` i-love-spam
@ 2009-04-27 22:49 ` Ian Lance Taylor
2009-04-28 7:24 ` i-love-spam
0 siblings, 1 reply; 27+ messages in thread
From: Ian Lance Taylor @ 2009-04-27 22:49 UTC (permalink / raw)
To: i-love-spam; +Cc: binutils
"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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-27 22:49 ` Ian Lance Taylor
@ 2009-04-28 7:24 ` i-love-spam
2009-04-28 7:45 ` Nick Clifton
2009-04-28 14:15 ` Ian Lance Taylor
0 siblings, 2 replies; 27+ messages in thread
From: i-love-spam @ 2009-04-28 7:24 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: binutils
> "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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 7:24 ` i-love-spam
@ 2009-04-28 7:45 ` Nick Clifton
2009-04-28 8:31 ` i-love-spam
2009-04-28 14:15 ` Ian Lance Taylor
1 sibling, 1 reply; 27+ messages in thread
From: Nick Clifton @ 2009-04-28 7:45 UTC (permalink / raw)
To: i-love-spam; +Cc: binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 7:45 ` Nick Clifton
@ 2009-04-28 8:31 ` i-love-spam
2009-04-28 10:44 ` Nick Clifton
2009-05-08 20:55 ` i-love-spam
0 siblings, 2 replies; 27+ messages in thread
From: i-love-spam @ 2009-04-28 8:31 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
> 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....
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 8:31 ` i-love-spam
@ 2009-04-28 10:44 ` Nick Clifton
2009-05-08 20:55 ` i-love-spam
1 sibling, 0 replies; 27+ messages in thread
From: Nick Clifton @ 2009-04-28 10:44 UTC (permalink / raw)
To: i-love-spam; +Cc: binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 7:24 ` i-love-spam
2009-04-28 7:45 ` Nick Clifton
@ 2009-04-28 14:15 ` Ian Lance Taylor
2009-04-28 14:25 ` Dave Korn
1 sibling, 1 reply; 27+ messages in thread
From: Ian Lance Taylor @ 2009-04-28 14:15 UTC (permalink / raw)
To: i-love-spam; +Cc: binutils
"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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 14:15 ` Ian Lance Taylor
@ 2009-04-28 14:25 ` Dave Korn
2009-04-28 15:46 ` pps
0 siblings, 1 reply; 27+ messages in thread
From: Dave Korn @ 2009-04-28 14:25 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: i-love-spam, binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 14:25 ` Dave Korn
@ 2009-04-28 15:46 ` pps
2009-04-28 16:07 ` Dave Korn
2009-04-28 16:44 ` Ian Lance Taylor
0 siblings, 2 replies; 27+ messages in thread
From: pps @ 2009-04-28 15:46 UTC (permalink / raw)
To: binutils
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??
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 15:46 ` pps
@ 2009-04-28 16:07 ` Dave Korn
2009-04-28 16:56 ` Daniel Jacobowitz
2009-04-28 17:29 ` Pedro Alves
2009-04-28 16:44 ` Ian Lance Taylor
1 sibling, 2 replies; 27+ messages in thread
From: Dave Korn @ 2009-04-28 16:07 UTC (permalink / raw)
To: pps; +Cc: binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 15:46 ` pps
2009-04-28 16:07 ` Dave Korn
@ 2009-04-28 16:44 ` Ian Lance Taylor
2009-04-28 16:52 ` pps
1 sibling, 1 reply; 27+ messages in thread
From: Ian Lance Taylor @ 2009-04-28 16:44 UTC (permalink / raw)
To: pps; +Cc: binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 16:44 ` Ian Lance Taylor
@ 2009-04-28 16:52 ` pps
0 siblings, 0 replies; 27+ messages in thread
From: pps @ 2009-04-28 16:52 UTC (permalink / raw)
To: binutils
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 16:07 ` Dave Korn
@ 2009-04-28 16:56 ` Daniel Jacobowitz
2009-04-28 17:29 ` Pedro Alves
1 sibling, 0 replies; 27+ messages in thread
From: Daniel Jacobowitz @ 2009-04-28 16:56 UTC (permalink / raw)
To: Dave Korn; +Cc: pps, binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 16:07 ` Dave Korn
2009-04-28 16:56 ` Daniel Jacobowitz
@ 2009-04-28 17:29 ` Pedro Alves
2009-04-28 17:33 ` Daniel Jacobowitz
1 sibling, 1 reply; 27+ messages in thread
From: Pedro Alves @ 2009-04-28 17:29 UTC (permalink / raw)
To: binutils; +Cc: Dave Korn, pps
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 17:29 ` Pedro Alves
@ 2009-04-28 17:33 ` Daniel Jacobowitz
2009-04-28 21:09 ` Dave Korn
0 siblings, 1 reply; 27+ messages in thread
From: Daniel Jacobowitz @ 2009-04-28 17:33 UTC (permalink / raw)
To: Pedro Alves; +Cc: binutils, Dave Korn, pps
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 17:33 ` Daniel Jacobowitz
@ 2009-04-28 21:09 ` Dave Korn
2009-05-07 6:58 ` pps
0 siblings, 1 reply; 27+ messages in thread
From: Dave Korn @ 2009-04-28 21:09 UTC (permalink / raw)
To: Pedro Alves, binutils, Dave Korn, pps
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 21:09 ` Dave Korn
@ 2009-05-07 6:58 ` pps
2009-05-07 9:38 ` Vincent R.
0 siblings, 1 reply; 27+ messages in thread
From: pps @ 2009-05-07 6:58 UTC (permalink / raw)
To: binutils
....
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-05-07 6:58 ` pps
@ 2009-05-07 9:38 ` Vincent R.
2009-05-07 12:27 ` Dave Korn
` (2 more replies)
0 siblings, 3 replies; 27+ messages in thread
From: Vincent R. @ 2009-05-07 9:38 UTC (permalink / raw)
To: pps; +Cc: binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-05-07 9:38 ` Vincent R.
@ 2009-05-07 12:27 ` Dave Korn
2009-05-07 12:34 ` Vincent R.
2009-05-08 8:31 ` pps
2009-05-08 8:32 ` pps
2 siblings, 1 reply; 27+ messages in thread
From: Dave Korn @ 2009-05-07 12:27 UTC (permalink / raw)
To: Vincent R.; +Cc: pps, binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-05-07 12:27 ` Dave Korn
@ 2009-05-07 12:34 ` Vincent R.
0 siblings, 0 replies; 27+ messages in thread
From: Vincent R. @ 2009-05-07 12:34 UTC (permalink / raw)
To: Dave Korn; +Cc: pps, binutils
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.
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-05-07 9:38 ` Vincent R.
2009-05-07 12:27 ` Dave Korn
@ 2009-05-08 8:31 ` pps
2009-05-08 8:32 ` pps
2 siblings, 0 replies; 27+ messages in thread
From: pps @ 2009-05-08 8:31 UTC (permalink / raw)
To: binutils
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
>
>
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-05-07 9:38 ` Vincent R.
2009-05-07 12:27 ` Dave Korn
2009-05-08 8:31 ` pps
@ 2009-05-08 8:32 ` pps
2 siblings, 0 replies; 27+ messages in thread
From: pps @ 2009-05-08 8:32 UTC (permalink / raw)
To: binutils
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! :)
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-04-28 8:31 ` i-love-spam
2009-04-28 10:44 ` Nick Clifton
@ 2009-05-08 20:55 ` i-love-spam
2009-05-09 17:20 ` Dave Korn
1 sibling, 1 reply; 27+ messages in thread
From: i-love-spam @ 2009-05-08 20:55 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: ARM-ELF -> PE-COFF with objcopy
2009-05-08 20:55 ` i-love-spam
@ 2009-05-09 17:20 ` Dave Korn
0 siblings, 0 replies; 27+ messages in thread
From: Dave Korn @ 2009-05-09 17:20 UTC (permalink / raw)
To: i-love-spam; +Cc: binutils
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
^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2009-05-09 17:20 UTC | newest]
Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-04-27 9:45 ARM-ELF -> PE-COFF with objcopy pps
2009-04-27 14:33 ` Nick Clifton
2009-04-27 16:26 ` pps
2009-04-27 21:21 ` i-love-spam
2009-04-27 22:49 ` Ian Lance Taylor
2009-04-28 7:24 ` i-love-spam
2009-04-28 7:45 ` Nick Clifton
2009-04-28 8:31 ` i-love-spam
2009-04-28 10:44 ` Nick Clifton
2009-05-08 20:55 ` i-love-spam
2009-05-09 17:20 ` Dave Korn
2009-04-28 14:15 ` Ian Lance Taylor
2009-04-28 14:25 ` Dave Korn
2009-04-28 15:46 ` pps
2009-04-28 16:07 ` Dave Korn
2009-04-28 16:56 ` Daniel Jacobowitz
2009-04-28 17:29 ` Pedro Alves
2009-04-28 17:33 ` Daniel Jacobowitz
2009-04-28 21:09 ` Dave Korn
2009-05-07 6:58 ` pps
2009-05-07 9:38 ` Vincent R.
2009-05-07 12:27 ` Dave Korn
2009-05-07 12:34 ` Vincent R.
2009-05-08 8:31 ` pps
2009-05-08 8:32 ` pps
2009-04-28 16:44 ` Ian Lance Taylor
2009-04-28 16:52 ` pps
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).