Menu
▾
▴
cegcc-devel — Discussion about CeGCC development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(63) |
Sep
(78) |
Oct
(111) |
Nov
(104) |
Dec
(39) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(69) |
Feb
(68) |
Mar
(23) |
Apr
(61) |
May
(56) |
Jun
(122) |
Jul
(82) |
Aug
(44) |
Sep
(63) |
Oct
(73) |
Nov
(77) |
Dec
(102) |
| 2008 |
Jan
(34) |
Feb
(51) |
Mar
(39) |
Apr
(43) |
May
(8) |
Jun
(59) |
Jul
(69) |
Aug
(97) |
Sep
(140) |
Oct
(72) |
Nov
(37) |
Dec
(35) |
| 2009 |
Jan
(70) |
Feb
(104) |
Mar
(42) |
Apr
(121) |
May
(161) |
Jun
(109) |
Jul
(90) |
Aug
(85) |
Sep
(104) |
Oct
(59) |
Nov
(76) |
Dec
(145) |
| 2010 |
Jan
(123) |
Feb
(45) |
Mar
(37) |
Apr
(9) |
May
|
Jun
(5) |
Jul
(22) |
Aug
|
Sep
(4) |
Oct
(5) |
Nov
(2) |
Dec
(83) |
| 2011 |
Jan
(19) |
Feb
(33) |
Mar
(14) |
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(8) |
Dec
(8) |
| 2012 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
|
May
(5) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Vincent T. <vt...@un...> - 2010-06-22 06:53:52
|
Hey, I would like to know the status of this project. I haven't seen any message for months on that ML thank you Vincent Torri |
|
From: InfoMail I. <mi...@gm...> - 2010-04-29 10:14:22
|
I run (in Cygwin 1.7): sh ./src/scripts/build-mingw32ce.sh But after ten minutes i got the following error: ldemul.o: In function 'ldemul_hll': /opt/cegcc-0.55/src/binutils/ld/ldemul.c:41: undefined reference to '_ld_arm_wince_pe_emulation' pe-dll.o: In function 'pe_create_import_fixup': /opt/cegcc-0.55/src/binutils/ld/pe-dll.c:2540: undefined reference to '_pe_data_import_dll' Any help/suggestion? Does someone have compiled mingw32ce 0.55 for Cygwin? Are there ready-to-use packages for such combination? Many thanks in advance! |
|
From: Pavel P. <pa...@su...> - 2010-04-27 16:28:07
|
From: InfoMail InfoMail [mailto:mi...@gm...] Sent: April 27, 2010 10:54 To: ceg...@li... Subject: [Cegcc-devel] Cortex A8 support Hi all, I'm trying to compile my library for Cortex A8, using the last mingw32ce toolchain. I use this compiler options: -mcpu=cortex-a8 -mtune=cortex-a8 -msoft-float -mfloat-abi=softfp -mfpu=neon -Wa,-mcpu=cortex-a8 -Wa,-mfpu=neon -mlittle-endian but i got the following errors: Assembler messages: Error: cannot represent BFD_RELOC_ARM_MOVW relocation in this object file format Error: cannot represent BFD_RELOC_ARM_MOVT relocation in this object file format Is there a *working* way to compile for CortexA8 ? Many thanks in advance! |
|
From: Pavel P. <pa...@su...> - 2010-04-27 16:25:28
|
From: InfoMail InfoMail [mailto:mi...@gm...] Sent: April 27, 2010 10:54 To: ceg...@li... Subject: [Cegcc-devel] Cortex A8 support Hi all, I'm trying to compile my library for Cortex A8, using the last mingw32ce toolchain. I use this compiler options: -mcpu=cortex-a8 -mtune=cortex-a8 -msoft-float -mfloat-abi=softfp -mfpu=neon -Wa,-mcpu=cortex-a8 -Wa,-mfpu=neon -mlittle-endian but i got the following errors: Assembler messages: Error: cannot represent BFD_RELOC_ARM_MOVW relocation in this object file format Error: cannot represent BFD_RELOC_ARM_MOVT relocation in this object file format Is there a *working* way to compile for CortexA8 ? Many thanks in advance! There is no way to compile for cortex a8 for wince. When I needed to do so, I had to modify binutils/gcc in order to be able to create a build that can handle that kind of thing, otherwise for any win API you'll be getting MOWV/MOVT error. The way I fixed it for my build was to make gcc think that movw/movt sequence has the same wait as regular load or mov or something like that so It stopped trying to use movw/movt for all api calls. If you are sure that you need to compile for cortexA8, Id recommend to compile for cortex only those parts of code that you really need to optimize, the rest compile as regular arm build. If you don't really need to optimize and if you don't have some heavily optimized code for cortex then don't waste your time, you won't get any benefit by simply recompiling to cortex. I tried ffmpeg and h264 decoding (and they have a lot of neon optimized code for h264), but the end result was that the difference between all that optimized code and plaing armv4 (not even arm5te!) build was only like 40%. I really expected to have way more performance improvement (especially, because for armv4 there is no optimized code at all!) |
|
From: InfoMail I. <mi...@gm...> - 2010-04-27 14:54:26
|
Hi all, I'm trying to compile my library for Cortex A8, using the last mingw32ce toolchain. I use this compiler options:* -mcpu=cortex-a8 -mtune=cortex-a8 -msoft-float -mfloat-abi=softfp -mfpu=neon -Wa,-mcpu=cortex-a8 -Wa,-mfpu=neon -mlittle-endian* but i got the following errors: *Assembler messages: Error: cannot represent BFD_RELOC_ARM_MOVW relocation in this object file format Error: cannot represent BFD_RELOC_ARM_MOVT relocation in this object file format* Is there a *working* way to compile for CortexA8 ? Many thanks in advance! |
|
From: InfoMail I. <mi...@gm...> - 2010-04-26 14:13:26
|
Hello guys, I've compiled my library using the new Mingw32ce toolchain (gcc
4.4.0 based).
Unlike the old one (gcc 4.1.2 based), now my library depends on
libgcc_s_sjlj-1.dll. Why?
Is there a way (e.g. compiler/link switches) to remove such dependencies?
Here's objdump result:
./lib/wince/arm11/sre/standalone/libAmanithVG.dll: file format
pei-arm-wince-little
Characteristics 0x630e
executable
line numbers stripped
symbols stripped
32 bit words
debugging information removed
DLL
Time/Date Mon Apr 26 16:03:29 2010
Magic 010b (PE32)
MajorLinkerVersion 2
MinorLinkerVersion 56
SizeOfCode 000baa00
SizeOfInitializedData 00009a00
SizeOfUninitializedData 00000200
AddressOfEntryPoint 00001000
BaseOfCode 00001000
BaseOfData 000bc000
ImageBase 00010000
SectionAlignment 00001000
FileAlignment 00000200
MajorOSystemVersion 4
MinorOSystemVersion 0
MajorImageVersion 1
MinorImageVersion 0
MajorSubsystemVersion 3
MinorSubsystemVersion 0
Win32Version 00000000
SizeOfImage 000ca000
SizeOfHeaders 00000400
CheckSum 000c6fcd
Subsystem 00000009 (Wince CUI)
DllCharacteristics 00000000
SizeOfStackReserve 00200000
SizeOfStackCommit 00001000
SizeOfHeapReserve 00100000
SizeOfHeapCommit 00001000
LoaderFlags 00000000
NumberOfRvaAndSizes 00000010
The Data Directory
Entry 0 000c5000 00000b38 Export Directory [.edata (or where ever we found
it)]
Entry 1 000c6000 0000060c Import Directory [parts of .idata]
Entry 2 000c7000 00000434 Resource Directory [.rsrc]
Entry 3 00000000 00000000 Exception Directory [.pdata]
Entry 4 00000000 00000000 Security Directory
Entry 5 000c8000 00001a58 Base Relocation Directory [.reloc]
Entry 6 00000000 00000000 Debug Directory
Entry 7 00000000 00000000 Description Directory
Entry 8 00000000 00000000 Special Directory
Entry 9 00000000 00000000 Thread Storage Directory [.tls]
Entry a 00000000 00000000 Load Configuration Directory
Entry b 00000000 00000000 Bound Import Directory
Entry c 00000000 00000000 Import Address Table Directory
Entry d 00000000 00000000 Delay Import Directory
Entry e 00000000 00000000 CLR Runtime Header
Entry f 00000000 00000000 Reserved
There is an import table in .idata at 0xd6000
The Import Tables (interpreted .idata section contents)
vma: Hint Time Forward DLL First
Table Stamp Chain Name Thunk
000c6000 000c603c 00000000 00000000 000c6578 000c6138
DLL Name: COREDLL.dll
vma: Hint/Ord Member-Name Bound-To
c6234 746 MessageBoxW
c6242 770 OutputDebugStringW
c6258 1125 TerminateProcess
c626c 1166 VirtualProtect
c627e 1167 VirtualQuery
c628e 1274 _fcloseall
c629c 1382 acos
c62a4 1385 atan2
c62ac 1390 ceil
c62b4 1393 cos
c62ba 1397 exp
c62c0 1400 fclose
c62ca 1401 feof
c62d2 1403 fflush
c62dc 1406 fgets
c62e4 1409 floor
c62ec 1413 fopen
c62f4 1420 free
c62fc 1508 malloc
c6306 1509 mbstowcs
c6312 1512 memcpy
c631c 1514 memset
c6326 1550 pow
c632c 1557 realloc
c6336 1561 sin
c633c 1565 sqrt
c6344 1571 strcmp
c634e 1572 strcpy
c6358 1574 strlen
c6362 1577 strncpy
c636c 1642 wcslen
c6376 1657 wsprintfW
000c6014 000c60c0 00000000 00000000 000c65f8 000c61bc
* DLL Name: libgcc_s_sjlj-1.dll
vma: Hint/Ord Member-Name Bound-To
c6384 22 __adddf3
c6390 23 __addsf3
c639c 40 __divdf3
c63a8 41 __divdi3
c63b4 43 __divsf3
c63c0 44 __divsi3
c63cc 48 __eqdf2
c63d8 49 __eqsf2
c63e4 50 __extendsfdf2
c63f4 55 __fixsfdi
c6400 56 __fixsfsi
c640c 60 __fixunssfsi
c641c 63 __floatsidf
c642c 64 __floatsisf
c643c 68 __floatunsisf
c644c 71 __gesf2
c6458 73 __gtsf2
c6464 75 __lesf2
c6470 78 __ltsf2
c647c 80 __modsi3
c6488 82 __muldf3
c6494 85 __mulsf3
c64a0 93 __nesf2
c64ac 106 __subdf3
c64b8 107 __subsf3
c64c4 110 __truncdfsf2
c64d4 112 __udivdi3
c64e0 114 __udivsi3
c64ec 116 __umodsi3*
|
|
From: mobi p. <mo...@mo...> - 2010-04-05 19:33:28
|
> However, when I want to run the executable on my HTC Wizard, the phone tells > me that my executable is not signed. > Yes, I remember now this problem with windows mobile 5. Hello. I am running cegcc generated programs on 6.1, and I think it was running on 6.5 as well (I removed 6.5 after the first day is it was very slow). However first try to accomodate with small C apllications then go for software monsters like QT apps... -- rgrds, mobi phil being mobile, but including technology http://mobiphil.com |
|
From: Zack <fb...@co...> - 2010-04-01 13:04:51
|
Hi all,
I've discovered that the math.h log2() function
is producing erroneous results. Try the following
test and you'll see, log2(8) does not produce 3,
but rather it gives 1.44. The regular log() function
works however, as it gives log(8)=2.08.
-Zack
#include <math.h>
#include <windows.h>
#include <stdio.h>
int
main ()
{
double d = 8.;
d = log2 (d);
wchar_t foo[100];
swprintf (foo, L"%g", d);
MessageBoxW (0, foo, 0,0);
}
|
|
From: Vincent R. <fo...@sm...> - 2010-04-01 11:46:02
|
> Hi, > I'm sorry for being a bit out of the purpose of this group, but I > don't really know any better place to ask for help. > > It's all about a "partially" broken PND running Windows CE 5.0 Core. > > This is a Chinese product, called "SmartGPS SG610". Internally, > however, it runs "malata.exe" and so, searching the Internet, I have > found "Malata PG-74301B", which looks exactly the same as my device. > I'm sure there are more units, which are exact copies of it, sold > under different brand names. > > All I could learn about the hardware / software is: > ---------------------------------------------------------------------- > Type: PORTABLE GPS (Sirf STAR III) > Version: M401I74S2--MAE6S1(Nov 1 2007) > Windows CE 5.0 Core > Processor: Intel ARM920T-PXA27x / PXA270 / 416 MHz > RAM: 64 MB, 100 MHz, 32 Bit, Samsung, Low Power Consumption SDRAM > ROM: 1 GB (NandFlash) > Screen: 4.3", 480x272 (16:9), 16 bit color > Display Type: (pxa27x_lcd.dll) AT043TN01 or/and LTM035A776C > Battery: Lithium Polymerized, 1400 mAh > ---------------------------------------------------------------------- > > At certain point in the past, something happened that partially > screwed the installed Windows CE 5.0 Core (and the builtin > "\Flash_Storage"). > I am still able to use this device, once I force the unit to use an > external version of the "explorer.exe" (seems the default > "\Windows\control.exe" is broken now) and start the navigation program > manually (everything is now kept on the SD card). > > What I am looking for is a "Windows CE 5.0 Core system copy / upgrade > image" for this particular type of device (some PND manufacturers do > provide "Windows CE system image updates", maybe there is something > like this for mine, too - but I did not find it up to now). > In fact, if I switch the unit ON while simultaneously keeping two > available buttons pressed, I get a bootloader menu (in simplified > Chinese) saying "choose download method", and the available options > are "USB transmission", "MMC storage card", "CF storage card" (the > unit has a USB plug and a SD/MMC card slot, no CF card slot). > The displayed hardware/bootloader version is "M401I74S2--MAE6S1(Nov 1 > 2007)". > So, I think, all I need it the "proper" (i.e. hardware specific) system > image. > > Well, the problem is that this unit is out of warranty and the cost > for "re-installing Windows" is high enough that it would really be > more wise to buy another PND. > If I decide to get another unit - what can I do with the existing one? > Can I run another systems (i.e. NON-Windows-CE) on this hardware? > What options are available (of course, I think I would prefer to > "restore" the Windows CE on it)? > Hi, try XDA website, YOur question is more appropriate there I think. They have tools, rom, crazy hackers so you should find some answers. |
|
From: Jacek M. H. <jac...@gm...> - 2010-04-01 10:59:54
|
Hi, I'm sorry for being a bit out of the purpose of this group, but I don't really know any better place to ask for help. It's all about a "partially" broken PND running Windows CE 5.0 Core. This is a Chinese product, called "SmartGPS SG610". Internally, however, it runs "malata.exe" and so, searching the Internet, I have found "Malata PG-74301B", which looks exactly the same as my device. I'm sure there are more units, which are exact copies of it, sold under different brand names. All I could learn about the hardware / software is: ---------------------------------------------------------------------- Type: PORTABLE GPS (Sirf STAR III) Version: M401I74S2--MAE6S1(Nov 1 2007) Windows CE 5.0 Core Processor: Intel ARM920T-PXA27x / PXA270 / 416 MHz RAM: 64 MB, 100 MHz, 32 Bit, Samsung, Low Power Consumption SDRAM ROM: 1 GB (NandFlash) Screen: 4.3", 480x272 (16:9), 16 bit color Display Type: (pxa27x_lcd.dll) AT043TN01 or/and LTM035A776C Battery: Lithium Polymerized, 1400 mAh ---------------------------------------------------------------------- At certain point in the past, something happened that partially screwed the installed Windows CE 5.0 Core (and the builtin "\Flash_Storage"). I am still able to use this device, once I force the unit to use an external version of the "explorer.exe" (seems the default "\Windows\control.exe" is broken now) and start the navigation program manually (everything is now kept on the SD card). What I am looking for is a "Windows CE 5.0 Core system copy / upgrade image" for this particular type of device (some PND manufacturers do provide "Windows CE system image updates", maybe there is something like this for mine, too - but I did not find it up to now). In fact, if I switch the unit ON while simultaneously keeping two available buttons pressed, I get a bootloader menu (in simplified Chinese) saying "choose download method", and the available options are "USB transmission", "MMC storage card", "CF storage card" (the unit has a USB plug and a SD/MMC card slot, no CF card slot). The displayed hardware/bootloader version is "M401I74S2--MAE6S1(Nov 1 2007)". So, I think, all I need it the "proper" (i.e. hardware specific) system image. Well, the problem is that this unit is out of warranty and the cost for "re-installing Windows" is high enough that it would really be more wise to buy another PND. If I decide to get another unit - what can I do with the existing one? Can I run another systems (i.e. NON-Windows-CE) on this hardware? What options are available (of course, I think I would prefer to "restore" the Windows CE on it)? Thanks in advance, Best regards, Jacek. |
|
From: Daniel M. <mon...@gm...> - 2010-03-28 03:59:19
|
Ok folks, here is the blog post about compiling OpenGL ES code with CEGCC: http://batterypoweredgames.blogspot.com/2010/03/compiling-opengl-es-code-with-cegcc.html Daniel Monteiro ======================================== |_|0|_| Linux Registered User #424188 |_|_|0| http://batterypoweredgames.blogspot.com/ |0|0|0| Visit to grab games for your mobile device! ======================================== 2010/2/15 Danny Backx <dan...@sc...> > On Mon, 2010-02-15 at 17:21 -0200, Daniel Monteiro wrote: > > Ok, forget about it. Just got it working. > > I will soon write a little guide to get things working and I will let > > you guys know, in case you're curious. > > Yes, please do. > > Danny > > -- > Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info > > |
|
From: Danny B. <dan...@sc...> - 2010-03-20 15:28:43
|
On Thu, 2010-03-11 at 20:31 +0100, Danny Backx wrote: > On Wed, 2010-03-10 at 22:05 +0100, Sébastien Lorquet wrote: > > If that helps running programs on a pocket pc without going through > > the cycle compile, copy to a windows pc (or a samba share), copy to > > pocket pc through active sync drag drop, tap on the pocket pc to start > > the program, etc then I'm interested :) > > I'm not a magician but it should make some things easier once file > transfer works reliably, see below. > > > At least I can issue debug message to a remote syslog server via > > active sync tcpip. > > Some of the things I don't like about gdbserver in its current state : > - no proper way to start it > either via rsh or via pocketconsole > - it doesn't show in the CE process list > > The version I have now : > - has a simple GUI with which you can specify which program to run, with > which parameters (command line for the program to debug), and on which > port gdbserver should talk > - can start in --multi mode as well as single process mode > - does show in the process list > > I don't seem to get file transfer (remote put/get) to work reliably. Has > anyone played with that yet ? > > Danny I've just uploaded this into tools/gdbserver . Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
|
From: Pavel P. <pa...@su...> - 2010-03-16 02:15:25
|
> 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)
>
By the way, I didn't want to use cegcc 4.4.0 for one other reason also: it produced bigger binary. I wanted to actually check what's going on, it's not some 10% increase, it's more like 200% increase in my case. Stripped avcodec.dll went from 1.8 to 4.5 MB. I checked contents of each of the sections... and guess what, one of the sections is full of zeroes (it has a bit of data at the beginning and the rest is zeroes); the size of that section is 2.4MB. Is that normal with latest gcc version??
|
|
From: Pavel P. <pa...@su...> - 2010-03-15 21:12:18
|
> -----Original Message-----
> From: Pedro Alves [mailto:pe...@co...]
> Sent: March 15, 2010 15:46
> To: ceg...@li...; dan...@sc...
> 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)
|
|
From: Pavel P. <pa...@su...> - 2010-03-15 20:47:58
|
> 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
|
|
From: Vincent T. <vt...@un...> - 2010-03-15 19:50:08
|
On Mon, 15 Mar 2010, Pedro Alves wrote: > On Monday 15 March 2010 19:44:01, Danny Backx wrote: >>> So, is there some fixes that has been pushed in svn about that limits.h >>> problem ? >>> >>> Vincent Torri >> >> My workaround was removed, I've not taken action on this issue since. > > I haven't had time to finish fixing the issue properly. If this > botters you so much, you can use Danny's fix locally. for now, i can hack my code. I prefer waiting for a correct fix before removing my hack. thank you Vincent Torri |
|
From: Pedro A. <pe...@co...> - 2010-03-15 19:47:40
|
On Monday 15 March 2010 19:44:01, Danny Backx wrote: > > So, is there some fixes that has been pushed in svn about that limits.h > > problem ? > > > > Vincent Torri > > My workaround was removed, I've not taken action on this issue since. I haven't had time to finish fixing the issue properly. If this botters you so much, you can use Danny's fix locally. -- Pedro Alves |
|
From: Pedro A. <pe...@co...> - 2010-03-15 19:46:07
|
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. -- Pedro Alves |
|
From: Danny B. <dan...@sc...> - 2010-03-15 19:43:32
|
On Sun, 2010-03-14 at 08:55 +0100, Vincent Torri wrote: > So, is there some fixes that has been pushed in svn about that limits.h > problem ? > > Vincent Torri My workaround was removed, I've not taken action on this issue since. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
|
From: Danny B. <dan...@sc...> - 2010-03-15 19:41:31
|
On Mon, 2010-03-15 at 13:25 +0100, Vincent Richomme wrote: > Ok when reading some post on mingw mailing list,I could read the following > lines : > > "With those conditions, the lack of an -enable-auto-import switch does > not > cause the 0xc0000005 error that ld warns about here: > > It looks like some of the issues you have reported about external symbols. > Maybe it can help ? Thanks for the pointer, yes this may be the same or a similar issue. I'm now looking into the way the imports and exports are handled in my example. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
|
From: Danny B. <dan...@sc...> - 2010-03-15 19:33:13
|
On Mon, 2010-03-15 at 13:09 -0400, Pavel Pavlov wrote:
> > On Sun, 2010-03-14 at 20:15 -0400, Pavel Pavlov wrote:
> > > > On Sun, 2010-03-14 at 04:25 -0400, Pavel Pavlov wrote:
> > > > > Sorry, I should have give more info. Off course default vanilla
> > armv4
> > > > will work,
> > > > > but I need to enable armv7 + neon compilation. Currently, It
> > won't
> > > > compile the
> > > > > code: error, unsupported ins for this arch.
> > > >
> > > > arm-mingw32ce-gcc --target-help mentions a lot of options.
> > >
> > >
> > > That's a standard switch that's mentioned in arm-mingw32ce-gcc --
> > help. It doesn't mention anything on how to get list of supported
> > target CPU's or arch's.
> >
> > Doesn't this bit help ?
> >
> > Danny
> >
> >
> > Known ARM CPUs (for use with the -mcpu= and -mtune= options):
> > cortex-m1, cortex-m3, cortex-r4f, cortex-r4, cortex-a9, cortex-a8,
> > arm1156t2-s, mpcore, mpcorenovfp, arm1176jzf-s, arm1176jz-s,
> > arm1136jf-s,
> > arm1136j-s, arm1026ej-s, arm926ej-s, iwmmxt2, iwmmxt, xscale,
> > arm1022e,
> > arm1020e, arm10e, arm968e-s, arm966e-s, arm946e-s, arm9e, arm1020t,
> > arm10tdmi, ep9312, arm940t, arm922t, arm920t, arm920, arm9tdmi,
> > arm9,
> > arm740t, arm720t, arm710t, arm7tdmi-s, arm7tdmi, strongarm1110,
> > strongarm1100, strongarm110, strongarm, arm810, arm8, arm7dmi,
> > arm7dm,
> > arm7m, arm7500fe, arm7500, arm7100, arm710c, arm720, arm710,
> > arm700i,
> > arm700, arm70, arm7di, arm7d, arm7, arm620, arm610, arm600, arm60,
> > arm6,
> > arm3, arm250, arm2
> >
> > Known ARM architectures (for use with the -march= option):
> > iwmmxt2, iwmmxt, ep9312, armv7-m, armv7-r, armv7-a, armv7, armv6-m,
> > armv6t2,
> > armv6zk, armv6z, armv6k, armv6j, armv6, armv5te, armv5e, armv5t,
> > armv5,
> > armv4t, armv4, armv3m, armv3, armv2a, armv2
> >
>
>
> Strange, I'm not getting this output (I tested with the 4.1.0 build) I was testing with 4.1.0, it was added in 4.4.0.
> 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}
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
|
|
From: Pavel P. <pa...@su...> - 2010-03-15 17:09:20
|
> On Sun, 2010-03-14 at 20:15 -0400, Pavel Pavlov wrote:
> > > On Sun, 2010-03-14 at 04:25 -0400, Pavel Pavlov wrote:
> > > > Sorry, I should have give more info. Off course default vanilla
> armv4
> > > will work,
> > > > but I need to enable armv7 + neon compilation. Currently, It
> won't
> > > compile the
> > > > code: error, unsupported ins for this arch.
> > >
> > > arm-mingw32ce-gcc --target-help mentions a lot of options.
> >
> >
> > That's a standard switch that's mentioned in arm-mingw32ce-gcc --
> help. It doesn't mention anything on how to get list of supported
> target CPU's or arch's.
>
> Doesn't this bit help ?
>
> Danny
>
>
> Known ARM CPUs (for use with the -mcpu= and -mtune= options):
> cortex-m1, cortex-m3, cortex-r4f, cortex-r4, cortex-a9, cortex-a8,
> arm1156t2-s, mpcore, mpcorenovfp, arm1176jzf-s, arm1176jz-s,
> arm1136jf-s,
> arm1136j-s, arm1026ej-s, arm926ej-s, iwmmxt2, iwmmxt, xscale,
> arm1022e,
> arm1020e, arm10e, arm968e-s, arm966e-s, arm946e-s, arm9e, arm1020t,
> arm10tdmi, ep9312, arm940t, arm922t, arm920t, arm920, arm9tdmi,
> arm9,
> arm740t, arm720t, arm710t, arm7tdmi-s, arm7tdmi, strongarm1110,
> strongarm1100, strongarm110, strongarm, arm810, arm8, arm7dmi,
> arm7dm,
> arm7m, arm7500fe, arm7500, arm7100, arm710c, arm720, arm710,
> arm700i,
> arm700, arm70, arm7di, arm7d, arm7, arm620, arm610, arm600, arm60,
> arm6,
> arm3, arm250, arm2
>
> Known ARM architectures (for use with the -march= option):
> iwmmxt2, iwmmxt, ep9312, armv7-m, armv7-r, armv7-a, armv7, armv6-m,
> armv6t2,
> armv6zk, armv6z, armv6k, armv6j, armv6, armv5te, armv5e, armv5t,
> armv5,
> armv4t, armv4, armv3m, armv3, armv2a, armv2
>
Strange, I'm not getting this output (I tested with the 4.1.0 build) I was testing with 4.1.0, it was added in 4.4.0.
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
|
|
From: Danny B. <dan...@sc...> - 2010-03-15 16:31:16
|
On Sun, 2010-03-14 at 20:15 -0400, Pavel Pavlov wrote:
> > On Sun, 2010-03-14 at 04:25 -0400, Pavel Pavlov wrote:
> > > Sorry, I should have give more info. Off course default vanilla armv4
> > will work,
> > > but I need to enable armv7 + neon compilation. Currently, It won't
> > compile the
> > > code: error, unsupported ins for this arch.
> >
> > arm-mingw32ce-gcc --target-help mentions a lot of options.
>
>
> That's a standard switch that's mentioned in arm-mingw32ce-gcc --help. It doesn't mention anything on how to get list of supported target CPU's or arch's.
Doesn't this bit help ?
Danny
Known ARM CPUs (for use with the -mcpu= and -mtune= options):
cortex-m1, cortex-m3, cortex-r4f, cortex-r4, cortex-a9, cortex-a8,
arm1156t2-s, mpcore, mpcorenovfp, arm1176jzf-s, arm1176jz-s,
arm1136jf-s,
arm1136j-s, arm1026ej-s, arm926ej-s, iwmmxt2, iwmmxt, xscale,
arm1022e,
arm1020e, arm10e, arm968e-s, arm966e-s, arm946e-s, arm9e, arm1020t,
arm10tdmi, ep9312, arm940t, arm922t, arm920t, arm920, arm9tdmi,
arm9,
arm740t, arm720t, arm710t, arm7tdmi-s, arm7tdmi, strongarm1110,
strongarm1100, strongarm110, strongarm, arm810, arm8, arm7dmi,
arm7dm,
arm7m, arm7500fe, arm7500, arm7100, arm710c, arm720, arm710,
arm700i,
arm700, arm70, arm7di, arm7d, arm7, arm620, arm610, arm600, arm60,
arm6,
arm3, arm250, arm2
Known ARM architectures (for use with the -march= option):
iwmmxt2, iwmmxt, ep9312, armv7-m, armv7-r, armv7-a, armv7, armv6-m,
armv6t2,
armv6zk, armv6z, armv6k, armv6j, armv6, armv5te, armv5e, armv5t,
armv5,
armv4t, armv4, armv3m, armv3, armv2a, armv2
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
|
|
From: Vincent R. <fo...@sm...> - 2010-03-15 12:25:20
|
On Sat, 13 Mar 2010 09:47:09 +0100, Danny Backx <dan...@dq...> wrote: > On Wed, 2010-03-10 at 21:15 +0100, Danny Backx wrote: >> Meaning, I think, that it does indeed crash in that statement. The >> double "ldr r3, [r3]" seems odd. Even more odd is that the code in >> a/t.dll.objdump is different : it looks exactly the same except only one >> of these "ldr r3, [r3]" instructions. >> >> Trying to figure out which one is correct, and how to debug at the >> assembler level :-( > > It would appear that in this sample program, the crash is legitimate > because - yet again - an invalid pointer is read. The value of 0x16342b8 > which is in r3 is not a valid pointer. > > In the second debugging session below I dug deeper and fixed the value > of r3 which executing, which made the program work well. > > I'll try to find the cause of this now... > Ok when reading some post on mingw mailing list,I could read the following lines : "With those conditions, the lack of an -enable-auto-import switch does not cause the 0xc0000005 error that ld warns about here: "warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing" If you want to make --enable-auto-import the default, which makes sense with Kai's pseudo-reloc fixes, the place to do it is in src/ld/pe.em (not in gcc specs)." It looks like some of the issues you have reported about external symbols. Maybe it can help ? |
|
From: Vincent R. <fo...@sm...> - 2010-03-15 12:14:20
|
On Sun, 14 Mar 2010 20:15:51 -0400, Pavel Pavlov <pa...@su...> wrote: >> On Sun, 2010-03-14 at 04:25 -0400, Pavel Pavlov wrote: >> > Sorry, I should have give more info. Off course default vanilla armv4 >> will work, >> > but I need to enable armv7 + neon compilation. Currently, It won't >> compile the >> > code: error, unsupported ins for this arch. >> >> arm-mingw32ce-gcc --target-help mentions a lot of options. > > > That's a standard switch that's mentioned in arm-mingw32ce-gcc --help. It > doesn't mention anything on how to get list of supported target CPU's or > arch's. > >> >> > By the way, I have a few minor local changes in my copy related to >> coredll.dll vs coredll (see attachement). >> >> I looked in my mailing archive but I can't find info about this - but I >> seem to remember that this has been brought up before. >> >> What exactly is the problem this solves, and why haven't we applied >> this >> fix before ? > > Well, for some reason it was all written as COREDLL instead of > coredll.dll. That means that many binaries are linked to COREDLL (without > .dll suffix). There is no such behavior with ms tools, they always link to > coredll.dll. Moreover, as far as I remember the way loader works is this: > if there is no COREDLL it will try to load coredll.exe then coredll.dll, > which means that if somebody "maliciously" creates a \windows\coredll.exe > then everything that links to coredll will fail to load. I didn't very that > though, still I don't see a reason to link to coredll instead of > coredll.dll (plus in the list of dependencies (depends.exe) I don't see > multiple dependencies on coredll and coredll.dll at the same time. I have already reported that kind of things hundred times with no result even on binutils mailing list... |
15 messages has been excluded from this view by a project administrator.
