gcov in cross-compile: have a patch, seek direction
I am working on the cegcc project (http://cegcc.sourceforge.net), which bundles a bunch of the GNU development tools to produce a cross-development environment for ARM devices running Windows CE. The development hosts supported are Linux and Cygwin. Gcov normally puts the files where it writes profiling information in the source directory. In a cross-development environment, that directory isn't always available. Gcc has support for overriding that directory at runtime. Unfortunately, on Windows CE, that is not always easy. I've patched my copy of gcc to be able to specify a different directory at compile-time (instead of at run time). I can cleanup and submit my patch if there's interest. Prior to that, I have a question : should this support be steered via parameters on the compiler command line, or from environment values ? I've currently implemented a command line arguement -fcoverage-base=xx which can be used like this : arm-wince-cegcc-gcc -g -D_WIN32_IE=0x0400 --coverage -fcoverage-base="\ \storage card\\devel" -o fibo.exe fibo.c Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info signature.asc Description: This is a digitally signed message part
gcc 4.4.0 on ARM/WinCE float problem
[I probably tried the wrong list earlier, got no reply on gcc-help.]
I've been looking into this problem, I don't seem to be able to track it
down. With the addition of gcc-4.4.0 to the cegcc toolset, the ARM
float/double arithmetic appears to be broken.
Environment is cross-development for execution on Windows CE platforms,
for ARM processors.
I'm looking for pointers to understanding this. Fixes would be welcome
too but that might be a bit much to ask ;-)
Consider this test program. I'm not sure how sensible it is, but
it shows at least two current problems.
#include
#include
main(int argc, char *argv[])
{
double d = 12.0;
double dd = d * 3.0;
double ddd = 36.0;
float fd = 36.0;
printf("Foo %d %f %d\n", 34, d, 67);
printf(" 12 * 3 -> %f\n", dd);
printf(" 36 -> %f\n", fd);
printf(" 36 d -> %f\n", ddd);
exit (0);
}
Its output, with the gcc 4.4 build chain on my disk, is :
pavilion: {233} arm-mingw32ce-gcc -o float-n2.exe float.c
-Wstrict-aliasing=2
pavilion: {234} rcp float-n2.exe ipaq:/temp
pavilion: {235} rsh ipaq /temp/float-n2.exe
Foo 34 12.00 67
12 * 3 -> 0.00
36 -> 0.00
36 d -> 36.00
pavilion: {236}
The difference between the last two printf statements points out, I
think, that a problem exists around printf. Might be float to double
conversion.
The difference between the second and fourth printf statements points
out that a problem exists in arithmetic. (dd and ddd should be equal.)
The latter problem is the more urgent one for me.
Thanks for any help at all..
Danny
P.S. All the code (tweaked gcc, binutils, etc) is in the SVN of the
cegcc project at http://sf.net/projects/cegcc .
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Re: gcc 4.4.0 on ARM/WinCE float problem
On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote:
> Are you using soft or hard fp?
Soft. Not all ARM processors have hardware fp.
> I don't think you're going to get anywhere with this until you start looking
> at the generated code to see precisely *what* is wrong with it. You've gone
> as far as you can with prodding it from the outside like a black box.
I've gone slightly further. But I'm still, as you say, outside the black
box. See below. My ARM assembler knowledge is rusty at best though, so
going deeper is not easy.
Kai Ruottu wrote :
> Comparing the output from some earlier working GCC with the gcc-4.4.0
> output would reveal if something was wrong in preparing inputs for
> the soft-float routines... Or maybe something was changed in the
> soft-float routines... What if you try a 'libgcc.a' taken from some
> earlier working GCC ?
Did that, see below. I think this means that the stuff in libgcc.a cause
the issue.
I've further looked at the content of libgcc2.c, which reveals macros
renamed from L_* to L_arm_* (commit r132837 in gcc svn). But the
description of that change seems to imply that this is all avmv6-m
related and should not affect other processors.
pavilion: {16} make clean
rm -f *.o *.exe *.rsc *.S *.od
rm -f float
pavilion: {17} make
arm-mingw32ce-gcc -D_WIN32_WCE=0x0600 -g -o float.exe float.c
arm-mingw32ce-objdump -xd float.exe >float.od
arm-mingw32ce-gcc -D_WIN32_WCE=0x0600 -S -o float.S float.c
/opt/oldgcc/bin/arm-mingw32ce-gcc -D_WIN32_WCE=0x0600 -g -o ofloat.exe
float.c
arm-mingw32ce-objdump -xd ofloat.exe >ofloat.od
/opt/oldgcc/bin/arm-mingw32ce-gcc -D_WIN32_WCE=0x0600 -S -o ofloat.S
float.c
rcp float.exe ipaq:/temp
rsh ipaq /temp/float.exe
Foo 34 12.00 67
12 * 3 -> 0.00
36 -> 0.00
36 d -> 36.00
rcp ofloat.exe ipaq:/temp
rsh ipaq /temp/ofloat.exe
Foo 34 12.00 67
12 * 3 -> 36.00
36 -> 36.00
36 d -> 36.00
/opt/oldgcc/bin/arm-mingw32ce-gcc -D_WIN32_WCE=0x0600 -o tst1.exe
float.c /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/libgcc.a
arm-mingw32ce-objdump -xd tst1.exe >tst1.od
rcp tst1.exe ipaq:/temp
rsh ipaq /temp/tst1.exe
Foo 34 12.00 67
12 * 3 -> 12.04
36 -> 0.00
36 d -> 36.00
arm-mingw32ce-gcc -D_WIN32_WCE=0x0600 -o tst2.exe
float.c /opt/oldgcc/lib/gcc/arm-mingw32ce/4.1.0/libgcc.a
arm-mingw32ce-objdump -xd tst2.exe >tst2.od
rcp tst2.exe ipaq:/temp
rsh ipaq /temp/tst2.exe
Foo 34 12.00 67
12 * 3 -> 36.00
36 -> 36.00
36 d -> 36.00
pavilion: {18} /opt/oldgcc/bin/arm-mingw32ce-gcc -v
Using built-in specs.
Target: arm-mingw32ce
Configured
with: /home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc/configure
--with-gcc --with-gnu-ld --with-gnu-as --build=i686-pc-linux-gnu
--target=arm-mingw32ce --host=i686-pc-linux-gnu --prefix=/opt/oldgcc
--enable-threads=win32 --disable-nls --enable-languages=c,c++
--disable-win32-registry --disable-multilib --disable-interwork
--without-newlib --enable-checking --with-headers
Thread model: win32
gcc version 4.1.0
pavilion: {19} arm-mingw32ce-gcc -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)
pavilion: {20}
BTW I've put all of this directory up at
http://danny.backx.info/download/cegcc/test.tar.gz . (117686 bytes)
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Re: gcc 4.4.0 on ARM/WinCE float problem
On Thu, 2009-07-23 at 15:17 +0300, Kai Ruottu wrote: > Dave Korn wrote: > > Danny Backx wrote: > >> On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote: > > > >> Kai Ruottu wrote : > >>> Comparing the output from some earlier working GCC with the gcc-4.4.0 > >>> output would reveal if something was wrong in preparing inputs for > >>> the soft-float routines... Or maybe something was changed in the > >>> soft-float routines... What if you try a 'libgcc.a' taken from some > >>> earlier working GCC ? > >> Did that, see below. I think this means that the stuff in libgcc.a cause > >> the issue. > > > > Could this be related to old-vs-new EABI? Is the stack aligned to the > > same > > multiple on entry to main in both old and new executables? The assembler > > code > > looked basically the same, except the stack frame size has changed and a lot > > of things that were aligned to an (odd/even) multiple of 8 may now be > > aligned > > to an (even/odd) multiple instead. > > Also the message thread started by : > > http://gcc.gnu.org/ml/gcc-help/2009-03/msg00107.html > > could be checked... Although taking part in it, I don't remember what > was solved or not :( In any case Vincent R. could know something more > now... I think Vincent was wrestling with the issues of the same commit I wrote about earlier : Danny wrote : > I've further looked at the content of libgcc2.c, which reveals macros > renamed from L_* to L_arm_* (commit r132837 in gcc svn). This renamed a lot of those macros. I still don't know whether that commit is related to my problem though. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Re: gcc 4.4.0 on ARM/WinCE float problem
On Thu, 2009-07-23 at 11:52 +0100, Dave Korn wrote:
> Danny Backx wrote:
> > On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote:
>
> > Kai Ruottu wrote :
> >> Comparing the output from some earlier working GCC with the gcc-4.4.0
> >> output would reveal if something was wrong in preparing inputs for
> >> the soft-float routines... Or maybe something was changed in the
> >> soft-float routines... What if you try a 'libgcc.a' taken from some
> >> earlier working GCC ?
> >
> > Did that, see below. I think this means that the stuff in libgcc.a cause
> > the issue.
>
> Could this be related to old-vs-new EABI?
What's old vs new EABI ?
An earlier search on eabi on the mailing list archive indicated that
this was ELF related. Did I draw the wrong conclusion ?
> Is the stack aligned to the same
> multiple on entry to main in both old and new executables? The assembler code
> looked basically the same, except the stack frame size has changed and a lot
> of things that were aligned to an (odd/even) multiple of 8 may now be aligned
> to an (even/odd) multiple instead.
Hmm, not sure why you say that.
Again my ARM assembler knowledge is really too limited for this, but the
difference
between float.S and ofloat.S (see the link in my earlier message) appears to
match
the amount of registers pushed on the stack at the entry of main :
## ofloat.S (gcc 4.1) :
main:
@ args = 0, pretend = 0, frame = 36
@ frame_needed = 1, uses_anonymous_args = 0
mov ip, sp
stmfd sp!, {r4, fp, ip, lr, pc}
sub fp, ip, #4
sub sp, sp, #40
str r0, [fp, #-48]
str r1, [fp, #-52]
bl __gccmain
## float.S (gcc 4.4) :
main:
@ args = 0, pretend = 0, frame = 36
@ frame_needed = 1, uses_anonymous_args = 0
stmfd sp!, {r4, fp, lr}
add fp, sp, #8
sub sp, sp, #40
str r0, [fp, #-40]
str r1, [fp, #-44]
bl __gccmain
Also a change in offsets I see (e.g. just above the bl statement) from -48 to
-40
should not change alignment from multiple of 8 to something that's not a
multiple
of 8. (It might in a general case but it wouldn't explain the failure of this
program.)
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Re: gcc 4.4.0 on ARM/WinCE float problem
On Thu, 2009-07-23 at 15:06 +0200, Danny Backx wrote: > On Thu, 2009-07-23 at 11:52 +0100, Dave Korn wrote: > > Danny Backx wrote: > > > On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote: > > > > > Kai Ruottu wrote : > > >> Comparing the output from some earlier working GCC with the gcc-4.4.0 > > >> output would reveal if something was wrong in preparing inputs for > > >> the soft-float routines... Or maybe something was changed in the > > >> soft-float routines... What if you try a 'libgcc.a' taken from some > > >> earlier working GCC ? > > > > > > Did that, see below. I think this means that the stuff in libgcc.a cause > > > the issue. It turns out that different functions are used : - my 4.4 implementation takes its multiply code from dp-bit.c - the 4.1 implementation takes it from ieee754-df.S I've now tweaked gcc/config/arm/t-wince-pe (to use _arm_muldivf3 instead of _muldivf3 in LIB1ASMFUNCS). Then the gcc build fails (double definitions). Worked around that by tweaking dp-bit.c . Result : Foo 34 12.00 67 12 * 3 -> 36.00 36 -> 0.00 36 d -> 36.00 The 12 * 3 line is different from before : it displays the expected result now. I guess I need to figure out how to make this work with Makefile work, not tweaks to dp-bit.c . Looking further ... Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Re: gcc 4.4.0 on ARM/WinCE float problem
On Fri, 2009-07-24 at 14:51 +0200, Danny Backx wrote: > On Thu, 2009-07-23 at 15:06 +0200, Danny Backx wrote: > > On Thu, 2009-07-23 at 11:52 +0100, Dave Korn wrote: > > > Danny Backx wrote: > > > > On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote: > > > > > > > Kai Ruottu wrote : > > > >> Comparing the output from some earlier working GCC with the gcc-4.4.0 > > > >> output would reveal if something was wrong in preparing inputs for > > > >> the soft-float routines... Or maybe something was changed in the > > > >> soft-float routines... What if you try a 'libgcc.a' taken from some > > > >> earlier working GCC ? > > > > > > > > Did that, see below. I think this means that the stuff in libgcc.a cause > > > > the issue. > > It turns out that different functions are used : > - my 4.4 implementation takes its multiply code from dp-bit.c > - the 4.1 implementation takes it from ieee754-df.S > > I've now tweaked gcc/config/arm/t-wince-pe (to use _arm_muldivf3 instead > of _muldivf3 in LIB1ASMFUNCS). Then the gcc build fails (double > definitions). Worked around that by tweaking dp-bit.c . > > Result : > Foo 34 12.00 67 > 12 * 3 -> 36.00 > 36 -> 0.00 > 36 d -> 36.00 > > The 12 * 3 line is different from before : it displays the expected > result now. > > I guess I need to figure out how to make this work with Makefile work, > not tweaks to dp-bit.c . > > Looking further ... I need advice on how to proceed with this. It looks like the change that introduced _arm prefixes for functions in LIB1ASMFUNCS (in gcc/config/arm/t-wince-pe) broke things. The other place where this type of stuff is used is in libgcc/Makefile.in , and I think the line lib2funcs := $(filter-out $(LIB2FUNCS_EXCLUDE) $(LIB1ASMFUNCS), $(lib2funcs)) is now broken due to the fact that the "encoding" of lib2funcs and LIB1ASMFUNCS is different. Unless I'm still missing something. Or is there a mechanism I haven't found yet to make sure that dp-bit.c and the assembler sources (such as ieee754-df.S) don't collide ? Clues, advice, please ? Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Re: gcc 4.4.0 on ARM/WinCE float problem
On Fri, 2009-07-24 at 15:40 +0200, Danny Backx wrote: > On Fri, 2009-07-24 at 14:51 +0200, Danny Backx wrote: > > On Thu, 2009-07-23 at 15:06 +0200, Danny Backx wrote: > > > On Thu, 2009-07-23 at 11:52 +0100, Dave Korn wrote: > > > > Danny Backx wrote: > > > > > On Thu, 2009-07-23 at 10:07 +0100, Dave Korn wrote: > > > > > > > > > Kai Ruottu wrote : > > > > >> Comparing the output from some earlier working GCC with the gcc-4.4.0 > > > > >> output would reveal if something was wrong in preparing inputs for > > > > >> the soft-float routines... Or maybe something was changed in the > > > > >> soft-float routines... What if you try a 'libgcc.a' taken from some > > > > >> earlier working GCC ? > > > > > > > > > > Did that, see below. I think this means that the stuff in libgcc.a > > > > > cause > > > > > the issue. > > > > It turns out that different functions are used : > > - my 4.4 implementation takes its multiply code from dp-bit.c > > - the 4.1 implementation takes it from ieee754-df.S > > > > I've now tweaked gcc/config/arm/t-wince-pe (to use _arm_muldivf3 instead > > of _muldivf3 in LIB1ASMFUNCS). Then the gcc build fails (double > > definitions). Worked around that by tweaking dp-bit.c . > > > > Result : > > Foo 34 12.00 67 > > 12 * 3 -> 36.00 > > 36 -> 0.00 > > 36 d -> 36.00 > > > > The 12 * 3 line is different from before : it displays the expected > > result now. > > > > I guess I need to figure out how to make this work with Makefile work, > > not tweaks to dp-bit.c . > > > > Looking further ... > > I need advice on how to proceed with this. > > It looks like the change that introduced _arm prefixes for functions in > LIB1ASMFUNCS (in gcc/config/arm/t-wince-pe) broke things. > > The other place where this type of stuff is used is in > libgcc/Makefile.in , and I think the line > > lib2funcs := $(filter-out $(LIB2FUNCS_EXCLUDE) $(LIB1ASMFUNCS), > $(lib2funcs)) > > is now broken due to the fact that the "encoding" of lib2funcs and > LIB1ASMFUNCS is different. > > Unless I'm still missing something. > > Or is there a mechanism I haven't found yet to make sure that dp-bit.c > and the assembler sources (such as ieee754-df.S) don't collide ? > > Clues, advice, please ? > > Danny I saw a statement in the gcc/config/spu directory that could help. Would it be a good idea to add stuff like this DPBIT_FUNCS := $(filter-out _mul_df _div_df, $(DPBIT_FUNCS)) to gcc/config/arm/t-wince-pe ? Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Re: gcc 4.4.0 on ARM/WinCE float problem
On Fri, 2009-07-24 at 15:40 +0200, Danny Backx wrote: > > It turns out that different functions are used : > > - my 4.4 implementation takes its multiply code from dp-bit.c > > - the 4.1 implementation takes it from ieee754-df.S > > > > I've now tweaked gcc/config/arm/t-wince-pe (to use _arm_muldivf3 instead > > of _muldivf3 in LIB1ASMFUNCS). Then the gcc build fails (double > > definitions). Worked around that by tweaking dp-bit.c . > I need advice on how to proceed with this. > > It looks like the change that introduced _arm prefixes for functions in > LIB1ASMFUNCS (in gcc/config/arm/t-wince-pe) broke things. > > The other place where this type of stuff is used is in > libgcc/Makefile.in , and I think the line > > lib2funcs := $(filter-out $(LIB2FUNCS_EXCLUDE) $(LIB1ASMFUNCS), > $(lib2funcs)) > > is now broken due to the fact that the "encoding" of lib2funcs and > LIB1ASMFUNCS is different. FYI this problem appears to be solved by adding a couple of lines to gcc/config/arm/t-wince-pe - see below - that match the stuff in the LIB1ASMFUNCS= statement in that same file. Only one big problem left now before 4.4 works and I can start getting the differences upstream. Thanks for the help, Danny # # Filter out functions from dp-bit.c that are already in lib1funcs.asm # DPBIT_FUNCS := $(filter-out _mul_df _div_df _addsub_df _compare_df \ _eq_df _ne_df _gt_df _ge_df _lt_df _le_df \ _negate_df _unord_df \ _df_to_sf _si_to_df _df_to_si _usi_to_df, $(DPBIT_FUNCS)) FPBIT_FUNCS := $(filter-out _mul_sf _div_sf _addsub_sf _compare_sf \ _eq_sf _ne_sf _gt_sf _ge_sf _lt_sf _le_sf \ _negate_sf _unord_sf \ _sf_to_df _si_to_sf _sf_to_si _usi_to_sf, $(FPBIT_FUNCS)) LIB2FUNCS_EXCLUDE = _floatundisf _floatundidf -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
ARM wmmx instructions from gcc ?
Hi,
Does anyone know how well gcc-4.4 works with ARM and wmmx instructions ?
I'm working on cegcc. It currently says :
pavilion: {86} arm-mingw32ce-gcc -mcpu=iwmmxt t.c
t.c:1: error: iwmmxt requires an AAPCS compatible ABI for proper
operation
pavilion: {87}
It's clear to me where in the source this message is generated.
It is not clear whether this is caused by errors in my port, or whether
gcc has some other problem with this.
Has anyone used this ?
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Re: ARM wmmx instructions from gcc ?
On Sun, 2009-08-30 at 21:39 +0100, Dave Korn wrote:
> Danny Backx wrote:
> > Hi,
> >
> > Does anyone know how well gcc-4.4 works with ARM and wmmx instructions ?
> >
> > I'm working on cegcc. It currently says :
> > pavilion: {86} arm-mingw32ce-gcc -mcpu=iwmmxt t.c
> > t.c:1: error: iwmmxt requires an AAPCS compatible ABI for proper
> > operation
> > pavilion: {87}
> >
> > It's clear to me where in the source this message is generated.
> >
> > It is not clear whether this is caused by errors in my port, or whether
> > gcc has some other problem with this.
>
> You should mention that long double alignment macro that the guy on the
> cegcc list thought it was connected with. ARM_DOUBLEWORD_ALIGN. If I was
> following that discussion correctly, the ABI requires it, and you have it
> #defined to zero to fix the problem you were getting with float double
> function argument passing, but maybe what this means is that it there's some
> more fundamental problem in the ABI-related MD macros, that fixing it this way
> ended up just papering over.
I (naively) kept my message simple, hoping to get a reaction like :
- I use this all the time in gcc-4.4 so the issue must be in your port
or
- nobody's been using that stuff for ages, it's almost certainly broken.
I guess life is not as simple as that :-)
You already extended my message with a great summary, so I'm finding it
hard to add sensible stuff to it.
Here are two references to why ARM_DOUBLEWORD_ALIGN was added there :
- the commit message
http://sourceforge.net/mailarchive/message.php?msg_name=E1Itn8S-0001xI-Nu%40sc8-pr-svn3.sourceforge.net
- the explanation
http://sourceforge.net/mailarchive/message.php?msg_name=473F27A8.1060805%40portugalmail.pt
The end result of all that was this code in gcc/config/arm/wince-pe.h :
#undef DEFAULT_STRUCTURE_SIZE_BOUNDARY
#define DEFAULT_STRUCTURE_SIZE_BOUNDARY 8
#undef ARM_DOUBLEWORD_ALIGN
#define ARM_DOUBLEWORD_ALIGN 0
#undef BIGGEST_ALIGNMENT
#define BIGGEST_ALIGNMENT 64
So, question time again : could this be in my port, or a more
fundamental issue as Dave hints ?
How can I find out ?
BTW the message on the cegcc list that started all this :
http://sourceforge.net/mailarchive/forum.php?thread_name=21121251665810%
40webmail35.yandex.ru&forum_name=cegcc-devel
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Re: ARM wmmx instructions from gcc ?
On Wed, 2009-09-02 at 13:34 +0100, Paul Brook wrote: > > So, question time again : could this be in my port, or a more > > fundamental issue as Dave hints ? > > Both. By my reading the ABI you're trying to implement does not provide the > guarantees required to use iwmmxt instructions. There are ways around this, > but none of them are simple or pretty. The simplest answer is "don't do that". Hi Paul, Thanks for the answer, but I'm not sure what you've told me and why. Could you expand a little ? Don't do what ? Use WMMX instructions in GCC ? or Don't try to use the current implementation with WMMX ? Thanks, Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
cross gcc - working gcc, but cannot compile C++
Hi,
I'm trying to build a cross-development system and I'm 99% successful.
My host is a standard Linux PC, target is a PDA (arm-wince-pe).
Versions of all tools are below.
I can build a cross-gcc as long as I tell it to support only C. When
trying to get C++ compiled as well, I always end up getting the error
message below.
I've tried patching gas because I had the feeling that gcc is producing
an option that gas doesn't support any more, but somehow I couldn't get
that to work.
Is this a gcc bug ?
Danny
gmake \
CFLAGS="-g -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute -fno-common " \
CONFIG_H="config.h
auto-host.h
/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/../include/ansidecl.h"
\
MAKEOVERRIDES= \
-f libgcc.mk all
gmake[1]: Entering directory
`/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/build/i686-pc-linux-gnu/arm-wince-pe/gcc/gcc'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory
`/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/build/i686-pc-linux-gnu/arm-wince-pe/gcc/gcc'
echo timestamp > stmp-multilib
(SHLIB_LINK='' \
SHLIB_MULTILIB=''; \
/tmp/gcc-4/bin/gcc -c -g -DIN_GCC -DCROSS_COMPILE -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I.
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/.
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/../include
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/../libcpp/include
-DSTANDARD_STARTFILE_PREFIX=\"../../../\"
-DSTANDARD_EXEC_PREFIX=\"/usr/ppc/lib/gcc/\"
-DSTANDARD_LIBEXEC_PREFIX=\"/usr/ppc/libexec/gcc/\"
-DDEFAULT_TARGET_VERSION=\"4.1.0\" -DDEFAULT_TARGET_MACHINE=\"arm-wince-pe\"
-DSTANDARD_BINDIR_PREFIX=\"/usr/ppc/bin/\"
-DTOOLDIR_BASE_PREFIX=\"../../../../\" `test "X${SHLIB_LINK}" = "X" || test
"yes" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` `test "X${SHLIB_MULTILIB}" =
"X" || echo "-DNO_SHARED_LIBGCC_MULTILIB"` \
-I. -I.
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/.
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/../include
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/../libcpp/include
/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/cp/g++spec.c)
/usr/ppc/bin/arm-wince-pe-as: unrecognized option `-Qy'
gmake: *** [g++spec.o] Error 1
Versions :
- gcc 4.1.0 from
ftp://ftp.gnu.org/pub/gnu/gcc/gcc-4.1.0
gcc-core-4.1.0.tar.bz2
gcc-g++-4.1.0.tar.bz2
- newlib 1.14.0
ftp://sources.redhat.com/pub/newlib/index.html
ftp://sources.redhat.com/pub/newlib/newlib-1.14.0.tar.gz
- gdb 6.4
ftp://ftp.gnu.org/pub/gnu/gdb/gdb-6.4.tar.bz2
- binutils from cvs, 16 May 2006
We are using this version because there is no recent released
version of
binutils that works for arm-wince-pe target.
cvs -d :pserver:[EMAIL PROTECTED]:/cvs/src ...
- w32api 3.7
http://prdownloads.sourceforge.net/mingw/w32api-3.7-src.tar.gz?download
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
signature.asc
Description: This is a digitally signed message part
RE: cross gcc - working gcc, but cannot compile C++
I've run ./xgcc -dumpspecs but I don't know what to look at. That one
doesn't contain the string "Qy". However, when I do the same with my
native gcc (the one I got from Mandriva), it does contain that :
*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
You might have noted that the failing command (see my previous mail)
runs /tmp/gcc-4/bin/gcc (it basically ran "gcc" before, the /tmp path is
an attempt to see whether getting rid of my Mandriva compiler helped).
So it runs a normal gcc, but that ends up calling arm-wince-pe-as, which
is not something I would expect to happen.
Do I have another cross-binutils in my path ? No, I've taken great care
to remove all of it at the beginning of my build script. For your
reference, I'm including part of my build script as attachment, they
should give you an idea of (1) the order in which I am building things,
look at build.sh, (2) the exact parameters, look at settings.sh and
build-gcc.sh .
Thanks,
Danny
On Mon, 2006-07-24 at 19:33 +0100, Dave Korn wrote:
> On 24 July 2006 18:31, Danny Backx wrote:
>
>
> > I can build a cross-gcc as long as I tell it to support only C. When
> > trying to get C++ compiled as well, I always end up getting the error
> > message below.
> >
> > I've tried patching gas because I had the feeling that gcc is producing
> > an option that gas doesn't support any more, but somehow I couldn't get
> > that to work.
> >
> > Is this a gcc bug ?
>
> Looks like a problem with specs file generation, conceivably some kind of
> old SysV option. Might be informative to run "./xgcc -dumpspecs" in the build
> directory.
>
> > /usr/ppc/bin/arm-wince-pe-as: unrecognized option `-Qy'
> > gmake: *** [g++spec.o] Error 1
>
> Whatever it is, it's been seen before lots!
>
> http://www.google.co.uk/search?q=unrecognized+option+Qy&btnG=Search&hl=en&clie
> nt=firefox-a&rls=org.mozilla%3Aen-GB%3Aofficial
>
> Is it conceivable that you have another version of cross-binutils in your
> path, ahead of the arm-wince-pe binutils, and aimed at a different target?
> What exact configure options did you use when you configured gcc and binutils?
>
>
> cheers,
> DaveK
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
build.sh
Description: application/shellscript
build-gcc.sh
Description: application/shellscript
settings.sh
Description: application/shellscript
signature.asc
Description: This is a digitally signed message part
RE: cross gcc - working gcc, but cannot compile C++
Dave,
I'd used some search engines for the -Qy error but never really found
the solution. Your reply prompted me to do that yet again, and I found
http://www.cygwin.com/ml/cygwin/1997-06/msg00457.html
which basically says
configure creates a softlink in gcc object directory to the new
version of the cross assembler. Problem is that the native compiler
get confused and use the cross assembler instead of the native one.
So I looked inside the build/gcc/gcc directory and found a file
called "as" with the contents
#!/bin/sh
exec /usr/ppc/bin/arm-wince-pe-as "$@"
Renaming that file made the build progress beyond my initial problem.
I think this is a bug in gcc/g++. Right ?
Danny
On Mon, 2006-07-24 at 21:05 +0200, Danny Backx wrote:
> I've run ./xgcc -dumpspecs but I don't know what to look at. That one
> doesn't contain the string "Qy". However, when I do the same with my
> native gcc (the one I got from Mandriva), it does contain that :
>
> *asm:
> %{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
>
> You might have noted that the failing command (see my previous mail)
> runs /tmp/gcc-4/bin/gcc (it basically ran "gcc" before, the /tmp path is
> an attempt to see whether getting rid of my Mandriva compiler helped).
> So it runs a normal gcc, but that ends up calling arm-wince-pe-as, which
> is not something I would expect to happen.
>
> Do I have another cross-binutils in my path ? No, I've taken great care
> to remove all of it at the beginning of my build script. For your
> reference, I'm including part of my build script as attachment, they
> should give you an idea of (1) the order in which I am building things,
> look at build.sh, (2) the exact parameters, look at settings.sh and
> build-gcc.sh .
>
> Thanks,
>
> Danny
>
> On Mon, 2006-07-24 at 19:33 +0100, Dave Korn wrote:
> > On 24 July 2006 18:31, Danny Backx wrote:
> >
> >
> > > I can build a cross-gcc as long as I tell it to support only C. When
> > > trying to get C++ compiled as well, I always end up getting the error
> > > message below.
> > >
> > > I've tried patching gas because I had the feeling that gcc is producing
> > > an option that gas doesn't support any more, but somehow I couldn't get
> > > that to work.
> > >
> > > Is this a gcc bug ?
> >
> > Looks like a problem with specs file generation, conceivably some kind of
> > old SysV option. Might be informative to run "./xgcc -dumpspecs" in the
> > build
> > directory.
> >
> > > /usr/ppc/bin/arm-wince-pe-as: unrecognized option `-Qy'
> > > gmake: *** [g++spec.o] Error 1
> >
> > Whatever it is, it's been seen before lots!
> >
> > http://www.google.co.uk/search?q=unrecognized+option+Qy&btnG=Search&hl=en&clie
> > nt=firefox-a&rls=org.mozilla%3Aen-GB%3Aofficial
> >
> > Is it conceivable that you have another version of cross-binutils in your
> > path, ahead of the arm-wince-pe binutils, and aimed at a different target?
> > What exact configure options did you use when you configured gcc and
> > binutils?
> >
> >
> > cheers,
> > DaveK
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
signature.asc
Description: This is a digitally signed message part
[Fwd: C++ cross-devel from Linux : success]
Dave, After removing the gcc/as file as I wrote yesterday, the build does work and it is possible to cross-compile a working hello-world app. Danny Forwarded Message > From: Danny Backx <[EMAIL PROTECTED]> > To: CeGCC Development List <[EMAIL PROTECTED]> > Subject: C++ cross-devel from Linux : success > Date: Tue, 25 Jul 2006 08:44:19 +0200 > > FYI, > > I've finally managed to get the C++ compiler to get built. It produces a > working hello world application, haven't tested anything else yet. > > This has taken a while because there appears to be a problem in the gcc > configuration that causes the build to break. Removing one file fixes > this :-( > > Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info signature.asc Description: This is a digitally signed message part
Re: gcov in cross-compile: have a patch, seek direction
On Tue, 2007-05-01 at 09:27 +1000, Ben Elliston wrote: > On Mon, 2007-04-23 at 22:16 +0200, Danny Backx wrote: > > > Gcov normally puts the files where it writes profiling information in > > the source directory. In a cross-development environment, that directory > > isn't always available. > > So I discovered when debugging testsuite failures on a remote target :-) > > > Gcc has support for overriding that directory at runtime. > > Unfortunately, on Windows CE, that is not always easy. > > Why, is there no concept of environment variables for Windows CE > processes? What is the real problem? For all I know there's just the registry. > > I've patched my copy of gcc to be able to specify a different directory > > at compile-time (instead of at run time). > > > > I can cleanup and submit my patch if there's interest. > > > > Prior to that, I have a question : should this support be steered via > > parameters on the compiler command line, or from environment values ? > > Don't use environment variables at compile time. It makes reproducing > problems in the field extremely difficult. We need useers to be able to > send source input plus a command line without having to further guess > their environment. Ok, a command line option is what I have. I'll try to clean up my patch shortly, and see if it still applies cleanly in a recent gcc tree. Our current version is based on gcc-4.1.0. Or is a patch against that ok ? Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info signature.asc Description: This is a digitally signed message part
Re: gcov in cross-compile: have a patch, seek direction
On Fri, 2007-05-04 at 09:49 +1000, Ben Elliston wrote:
> On Thu, 2007-05-03 at 19:55 +0200, Danny Backx wrote:
>
> > Ok, a command line option is what I have. I'll try to clean up my
> > patch shortly, and see if it still applies cleanly in a recent gcc
> > tree. Our current version is based on gcc-4.1.0. Or is a patch against
> > that ok ?
>
> This feature would not be accepted into GCC 4.1 or 4.2, so please bring
> your patch up to date with mainline and then submit it. I'd be
> surprised if it's much work to do that.
As you said, it isn't much work.
Attached is a patch with a small amount of documentation but lacking a
ChangeLog entry. I'm sending it now already for you to comment on.
A usage example :
dannypc: {49} make
/home/danny/src/gcc/[EMAIL PROTECTED]/build/gcc/xgcc
-B/home/danny/src/gcc/[EMAIL PROTECTED]/build/gcc --coverage -c t.c
-fcoverage-base=/tmp -o t1.o
/home/danny/src/gcc/[EMAIL PROTECTED]/build/gcc/xgcc
-B/home/danny/src/gcc/[EMAIL PROTECTED]/build/gcc --coverage -c t.c -o
t2.o
strings t1.o >t1.strings
strings t2.o >t2.strings
dannypc: {50} more *.strings
::
t1.strings
::
e304
Hello, world !
/tmp/t1.gcda
::
t2.strings
::
e304
Hello, world !
/home/danny/t/t2.gcda
dannypc: {51}
If I need to change the implementation in some way, please advise.
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
Index: doc/gcov.texi
===
--- doc/gcov.texi (revision 124505)
+++ doc/gcov.texi (working copy)
@@ -543,9 +543,14 @@
absolute directory structure on the target system. The program will try
to create the needed directory structure, if it is not already present.
-To support cross-profiling, a program compiled with @option{-fprofile-arcs}
-can relocate the data files based on two environment variables:
+There are two options to support cross-profiling. A command line argument
+to the compiler (-fcoverage-base) allows you to override the directory
+stored in the object file; this happens at compile time. Alternatively,
+two runtime environment variables allow you to relocate the data files.
+Both options have effect only on programs compiled with @option{-fprofile-arcs}.
+The two environment variables:
+
@itemize @bullet
@item
GCOV_PREFIX contains the prefix to add to the absolute paths
@@ -568,6 +573,12 @@
@samp{GCOV_PREFIX=/target/run} and @samp{GCOV_PREFIX_STRIP=1}. Such a
setting will name the data file @file{/target/run/build/foo.gcda}.
+The build time command line option can be used like this :
+
[EMAIL PROTECTED]
+gcc -fcoverage-base=/target/run -fprofile-arcs -o t.exe t.c
[EMAIL PROTECTED] smallexample
+
You must move the data files to the expected directory tree in order to
use them for profile directed optimizations (@option{--use-profile}), or to
use the @command{gcov} tool.
Index: toplev.h
===
--- toplev.h (revision 124505)
+++ toplev.h (working copy)
@@ -133,6 +133,7 @@
extern int flag_unswitch_loops;
extern int flag_cprop_registers;
extern int time_report;
+extern char *coverage_base;
/* Things to do with target switches. */
extern void print_version (FILE *, const char *);
Index: opts.c
===
--- opts.c (revision 124505)
+++ opts.c (working copy)
@@ -1425,6 +1425,10 @@
fix_register (arg, 0, 0);
break;
+case OPT_fcoverage_base_:
+ coverage_base = xstrdup(arg);
+ break;
+
case OPT_fdiagnostics_show_location_:
if (!strcmp (arg, "once"))
diagnostic_prefixing_rule (global_dc) = DIAGNOSTICS_SHOW_PREFIX_ONCE;
Index: coverage.c
===
--- coverage.c (revision 124505)
+++ coverage.c (working copy)
@@ -89,6 +89,7 @@
static char *bbg_file_name;
static unsigned bbg_file_opened;
static int bbg_function_announced;
+char *coverage_base = NULL;
/* Name of the count data file. */
static char *da_file_name;
@@ -826,12 +827,24 @@
field = build_decl (FIELD_DECL, NULL_TREE, string_type);
TREE_CHAIN (field) = fields;
fields = field;
- filename = getpwd ();
- filename = (filename && da_file_name[0] != '/'
+
+ /* Additional command line argument for cross-development */
+ if (coverage_base)
+{
+ filename = concat (coverage_base, "/", da_file_name, NULL);
+ filename_len = strlen (filename);
+ filename_string = build_string (filename_len + 1, filename);
+}
+ else
+{
+ filename = getpwd ();
+ filename = (filename && da_file_name[0] != '/'
? concat (filename, "/", da_file_name, NULL)
: da_file_name);
- filename_len = strlen (filename);
- filename_string = build_string (filename_len + 1, filen
