> On Mon, 2010-03-15 at 13:09 -0400, Pavel Pavlov wrote:
> > If you are using 4.4.0, can you test this code:
> >
> > #include <windows.h>
> > int main(int argc, char **argv){
> > return (long) &VirtualAlloc;
> > }
> >
> > 1) with -march=armv5te (works ok)
> > 2) with -march=armv7 (error: target CPU does not support ARM mode
> ?!?)
> > 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
>
> I get the same errors.
>
> I don't think it's binutils : when running these commands with -v, the
> program that gives the errors is the C compiler itself, see below.
>
> Not sure what's going on.
>
> Danny
>
> pavilion: {12} arm-mingw32ce-gcc -march=armv7 -o va-armv7.exe va.c -v
> Using built-in specs.
> Target: arm-mingw32ce
> Configured
> with: /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc-
> 4.4.0/configure --with-gcc --with-gnu-ld --with-gnu-as --build=i686-pc-
> linux-gnu --target=arm-mingw32ce --host=i686-pc-linux-gnu --
> prefix=/opt/mingw32ce --enable-threads=win32 --disable-nls --enable-
> languages=c,c++ --disable-win32-registry --disable-multilib --disable-
> interwork --without-newlib --enable-checking --with-headers --disable-
> __cxa_atexit
> Thread model: win32
> gcc version 4.4.0 (GCC)
> COLLECT_GCC_OPTIONS='-march=armv7' '-o' 'va-armv7.exe' '-v'
> /opt/mingw32ce/libexec/gcc/arm-mingw32ce/4.4.0/cc1 -quiet -v
> -D__COREDLL__ -D__MINGW32__ -D__MINGW32CE__ -D__CEGCC_VERSION__
> -idirafter ../include/w32api -idirafter ../../include/w32api va.c -
> quiet
> -dumpbase va.c -march=armv7 -auxbase va -version -o /tmp/ccCHQwYd.s
> ignoring nonexistent directory
> "/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-
> mingw32ce/sys-include"
> ignoring nonexistent directory "../include/w32api"
> ignoring nonexistent directory "../../include/w32api"
> #include "..." search starts here:
> #include <...> search starts here:
> /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include
> /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed
> /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-
> mingw32ce/include
> End of search list.
> va.c:1: error: target CPU does not support ARM mode
> GNU C (GCC) version 4.4.0 (arm-mingw32ce)
> compiled by GNU C version 4.4.1, GMP version 4.3.2, MPFR
> version
> 2.4.2.
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
> pavilion: {13}
>
In case of -mcpu=cortex-a8 the error comes from "GNU assembler version 2.20.51
(arm-mingw32ce) using BFD version (GNU Binutils) 2.20.51.20091016"
By the way, before complaining on the list I tried to fix the problem myself.
For that, I downloaded latest gcc release (4.4.3), merged all the changes that
were made in cegcc to 4.4.0 and used 4.4.3 instead of 4.4.0. It builds ok, but
the errors I'm getting are the same (in cortex-a8 and armv7/armv7-a). If
anybody interested to try, I can send the diff from 4.4.3
I see there is some debate about some problem related to statics. You remember
the infamous problem when dll compiled with cegcc weren’t loading? This time
it's all opposite: dll compiled with cegcc-4.4.0 works as-is on the device, but
if it's compressed then it crashes. Initially, I didn't even think it had
anything to do with upx itself (I set upx to be part of the build and I forgot
that I use it), but then to make it easier to debug the problem I decided to
debug uncompressed dll and strangely the problem disappeared if dll isn't upx
compressed. Anyways, I decided to trace the problem and it was related to const
static variable used.
I tried to create a simple test dll with the same type of code, but it doesn't
produce unexpected behavior if it's a simple dll compressed by upx.
Basically, the code was like that:
const static AVClass av_codec_context_class = { "AVCodecContext",
context_to_name, options };
Dllexport void test(){
//approximate code, in reality I printed to log, here the code is just
an example and doesn't convert to wide string.
MessageBox(0, av_codec_context_class.class_name, L"", 0); //
av_codec_context_class.class_name is "AVCodecContext"
}
The message box code would crash or show garbage when it tried to access
av_codec_context_class.class_name, but if I removed const static from
av_codec_context_class then the problem would go away.
I had to do some code related to custom loaders and I know in general what upx
does when dll is loaded, knowing that... I really have doubts that it has
anything to do with upx, most likely it just works with uncompressed dlls by
surprise :)
Basically, upx works this way: it keeps the same image size (ram required for
loading of the dll), then inside dllmain (dll entry point) it uncompresses the
image into allocated ram, then it processes imports section and sets imported
function pointers. Overall, it should result in physically the same layout in
the memory after upx finishes running
------------------------------------------------------------------------------
Download Intel® 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
