Alpha Cross compiler

Alpha Cross compiler

[Mahshid Sedghi]

Hi all,

I am using an Alpha cross compiler by gem5 website built using
crosstool, and this is the version:  gcc-4.3.2, glibc-2.6.1
(NPTL,x86/64).
I was able to compile simple codes using it successfully, but when I
try to compile my larger applications, I am getting assembly errors as
below:

/tmp/ccuZ74Tx.s: Assembler messages:
/tmp/ccuZ74Tx.s:38: Error: unknown opcode `movl'
/tmp/ccuZ74Tx.s:39: Error: syntax error

Do you have any idea what the problem is and how it can be fixed?

Thanks.

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Alpha Cross compiler

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]

On Wed, 2013-01-16 19:20:22 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
> Hi all,
> 
> I am using an Alpha cross compiler by gem5 website built using
> crosstool, and this is the version:  gcc-4.3.2, glibc-2.6.1
> (NPTL,x86/64).
> I was able to compile simple codes using it successfully, but when I
> try to compile my larger applications, I am getting assembly errors as
> below:
> 
> /tmp/ccuZ74Tx.s: Assembler messages:
> /tmp/ccuZ74Tx.s:38: Error: unknown opcode `movl'
> /tmp/ccuZ74Tx.s:39: Error: syntax error
> 
> Do you have any idea what the problem is and how it can be fixed?

Please show a longer dump of the make trail, including eg. all the
command line options used. You'd probably add a "-v" to CFLAGS. My
guess is that somewhere, the cross-targeted compiler chooses to run a
i686 assembler or something like that.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:             God put me on earth to accomplish a certain number of
the second  :            things. Right now I am so far behind I will never die.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Alpha Cross compiler

[Mahshid Sedghi]

Thanks for looking into this Jan-Benedict. Below is a more detailed
make trail. My source file is named " thread_pool.cpp". In order to
cross compile for alpha, I replaced CXX in the makefile with new gcc
(as appears in the trail):


/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/alphaev67-unknown-linux-gnu-gcc
-g -v -c thread_pool.cpp -o thread_pool.o -I../include
Using built-in specs.
Target: alphaev67-unknown-linux-gnu
Configured with: /opt/crosstool/targets/src/gcc-4.3.2/configure
--build=x86_64-build_unknown-linux-gnu
--host=x86_64-build_unknown-linux-gnu
--target=alphaev67-unknown-linux-gnu
--prefix=/opt/crosstool/alphaev67-unknown-linux-gnu
--with-sysroot=/opt/crosstool/alphaev67-unknown-linux-gnu/alphaev67-unknown-linux-gnu/sys-root
--enable-languages=c,c++,fortran --disable-multilib --with-cpu=ev67
--with-tune=ev67 --with-gmp=/opt/crosstool/alphaev67-unknown-linux-gnu
--with-mpfr=/opt/crosstool/alphaev67-unknown-linux-gnu
--with-pkgversion=crosstool-NG-1.2.0+svn_trunk@1208
--enable-__cxa_atexit
--with-local-prefix=/opt/crosstool/alphaev67-unknown-linux-gnu/alphaev67-unknown-linux-gnu/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
Thread model: posix
gcc version 4.3.2 (crosstool-NG-1.2.0+svn_trunk@1208)
COLLECT_GCC_OPTIONS='-g' '-v' '-c' '-o' 'thread_pool.o' '-I../include'
'-mcpu=ev67' '-mtune=ev67'
 /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../libexec/gcc/alphaev67-unknown-linux-gnu/4.3.2/cc1plus
-quiet -v -I../include -iprefix
/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/
-isysroot /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../alphaev67-unknown-linux-gnu/sys-root
thread_pool.cpp -quiet -dumpbase thread_pool.cpp -mcpu=ev67
-mtune=ev67 -auxbase-strip thread_pool.o -g -version -o
/tmp/ccwgA8KD.s
ignoring duplicate directory
"/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2"
ignoring duplicate directory
"/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2/alphaev67-unknown-linux-gnu"
ignoring duplicate directory
"/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2/backward"
ignoring nonexistent directory
"/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../alphaev67-unknown-linux-gnu/sys-root/opt/crosstool/alphaev67-unknown-linux-gnu/alphaev67-unknown-linux-gnu/sys-root/include"
ignoring duplicate directory
"/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/include"
ignoring duplicate directory
"/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/include-fixed"
ignoring duplicate directory
"/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 ../include
 /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2
 /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2/alphaev67-unknown-linux-gnu
 /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2/backward
 /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/include
 /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/include-fixed
 /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include
 /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../alphaev67-unknown-linux-gnu/sys-root/usr/include
End of search list.
GNU C++ (crosstool-NG-1.2.0+svn_trunk@1208) version 4.3.2
(alphaev67-unknown-linux-gnu)
        compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3), GMP
version 4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4e35720dcba0a9cbc05e62a531a9d4b9
COLLECT_GCC_OPTIONS='-g' '-v' '-c' '-o' 'thread_pool.o' '-I../include'
'-mcpu=ev67' '-mtune=ev67'
 /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/bin/as
-no-mdebug -o thread_pool.o /tmp/ccwgA8KD.s
/tmp/ccwgA8KD.s: Assembler messages:
/tmp/ccwgA8KD.s:38: Error: unknown opcode `movl'
/tmp/ccwgA8KD.s:39: Error: syntax error
make[1]: *** [thread_pool.o] Error 1


Thanks for the help.
Mahshid



On Thu, Jan 17, 2013 at 3:58 AM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Wed, 2013-01-16 19:20:22 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
>> Hi all,
>>
>> I am using an Alpha cross compiler by gem5 website built using
>> crosstool, and this is the version:  gcc-4.3.2, glibc-2.6.1
>> (NPTL,x86/64).
>> I was able to compile simple codes using it successfully, but when I
>> try to compile my larger applications, I am getting assembly errors as
>> below:
>>
>> /tmp/ccuZ74Tx.s: Assembler messages:
>> /tmp/ccuZ74Tx.s:38: Error: unknown opcode `movl'
>> /tmp/ccuZ74Tx.s:39: Error: syntax error
>>
>> Do you have any idea what the problem is and how it can be fixed?
>
> Please show a longer dump of the make trail, including eg. all the
> command line options used. You'd probably add a "-v" to CFLAGS. My
> guess is that somewhere, the cross-targeted compiler chooses to run a
> i686 assembler or something like that.
>
> MfG, JBG
>
> --
>       Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
> Signature of:             God put me on earth to accomplish a certain number of
> the second  :            things. Right now I am so far behind I will never die.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlD3vR0ACgkQHb1edYOZ4buntwCeL1IAUxrHTF1bp++IV9bZvjYZ
> avMAn1R7JmwKZj5RrtvNmvOpREt+s49x
> =Kj4a
> -----END PGP SIGNATURE-----
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Alpha Cross compiler

[Wang Baisheng]

Check the output, the cross compiler chooses correnct cross as...

I think you can try:

1 Add a "-S" to CFLAGS to produce the assembly code, and double check it.

2 What about writing an hello assembly code including instruction
"movl", using alphaev67-unknown-linux-gnu-as try to compile. And what
will happen ?

Regards,
Jacky

2013/1/18 Mahshid Sedghi <mahshid.sedghy@gmail.com>:
> Thanks for looking into this Jan-Benedict. Below is a more detailed
> make trail. My source file is named " thread_pool.cpp". In order to
> cross compile for alpha, I replaced CXX in the makefile with new gcc
> (as appears in the trail):
>
>
> /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/alphaev67-unknown-linux-gnu-gcc
> -g -v -c thread_pool.cpp -o thread_pool.o -I../include
> Using built-in specs.
> Target: alphaev67-unknown-linux-gnu
> Configured with: /opt/crosstool/targets/src/gcc-4.3.2/configure
> --build=x86_64-build_unknown-linux-gnu
> --host=x86_64-build_unknown-linux-gnu
> --target=alphaev67-unknown-linux-gnu
> --prefix=/opt/crosstool/alphaev67-unknown-linux-gnu
> --with-sysroot=/opt/crosstool/alphaev67-unknown-linux-gnu/alphaev67-unknown-linux-gnu/sys-root
> --enable-languages=c,c++,fortran --disable-multilib --with-cpu=ev67
> --with-tune=ev67 --with-gmp=/opt/crosstool/alphaev67-unknown-linux-gnu
> --with-mpfr=/opt/crosstool/alphaev67-unknown-linux-gnu
> --with-pkgversion=crosstool-NG-1.2.0+svn_trunk@1208
> --enable-__cxa_atexit
> --with-local-prefix=/opt/crosstool/alphaev67-unknown-linux-gnu/alphaev67-unknown-linux-gnu/sys-root
> --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
> --enable-long-long --enable-target-optspace
> Thread model: posix
> gcc version 4.3.2 (crosstool-NG-1.2.0+svn_trunk@1208)
> COLLECT_GCC_OPTIONS='-g' '-v' '-c' '-o' 'thread_pool.o' '-I../include'
> '-mcpu=ev67' '-mtune=ev67'
>  /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../libexec/gcc/alphaev67-unknown-linux-gnu/4.3.2/cc1plus
> -quiet -v -I../include -iprefix
> /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/
> -isysroot /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../alphaev67-unknown-linux-gnu/sys-root
> thread_pool.cpp -quiet -dumpbase thread_pool.cpp -mcpu=ev67
> -mtune=ev67 -auxbase-strip thread_pool.o -g -version -o
> /tmp/ccwgA8KD.s
> ignoring duplicate directory
> "/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2"
> ignoring duplicate directory
> "/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2/alphaev67-unknown-linux-gnu"
> ignoring duplicate directory
> "/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2/backward"
> ignoring nonexistent directory
> "/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../alphaev67-unknown-linux-gnu/sys-root/opt/crosstool/alphaev67-unknown-linux-gnu/alphaev67-unknown-linux-gnu/sys-root/include"
> ignoring duplicate directory
> "/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/include"
> ignoring duplicate directory
> "/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/include-fixed"
> ignoring duplicate directory
> "/i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/../../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  ../include
>  /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2
>  /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2/alphaev67-unknown-linux-gnu
>  /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include/c++/4.3.2/backward
>  /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/include
>  /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/include-fixed
>  /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/include
>  /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../alphaev67-unknown-linux-gnu/sys-root/usr/include
> End of search list.
> GNU C++ (crosstool-NG-1.2.0+svn_trunk@1208) version 4.3.2
> (alphaev67-unknown-linux-gnu)
>         compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu3), GMP
> version 4.2.2, MPFR version 2.3.1.
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
> Compiler executable checksum: 4e35720dcba0a9cbc05e62a531a9d4b9
> COLLECT_GCC_OPTIONS='-g' '-v' '-c' '-o' 'thread_pool.o' '-I../include'
> '-mcpu=ev67' '-mtune=ev67'
>  /i3c/hpcl/mis5413/gem5/gem5/alphaev67-unknown-linux-gnu/bin/../lib/gcc/alphaev67-unknown-linux-gnu/4.3.2/../../../../alphaev67-unknown-linux-gnu/bin/as
> -no-mdebug -o thread_pool.o /tmp/ccwgA8KD.s
> /tmp/ccwgA8KD.s: Assembler messages:
> /tmp/ccwgA8KD.s:38: Error: unknown opcode `movl'
> /tmp/ccwgA8KD.s:39: Error: syntax error
> make[1]: *** [thread_pool.o] Error 1
>
>
> Thanks for the help.
> Mahshid
>
>
>
> On Thu, Jan 17, 2013 at 3:58 AM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
>> On Wed, 2013-01-16 19:20:22 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
>>> Hi all,
>>>
>>> I am using an Alpha cross compiler by gem5 website built using
>>> crosstool, and this is the version:  gcc-4.3.2, glibc-2.6.1
>>> (NPTL,x86/64).
>>> I was able to compile simple codes using it successfully, but when I
>>> try to compile my larger applications, I am getting assembly errors as
>>> below:
>>>
>>> /tmp/ccuZ74Tx.s: Assembler messages:
>>> /tmp/ccuZ74Tx.s:38: Error: unknown opcode `movl'
>>> /tmp/ccuZ74Tx.s:39: Error: syntax error
>>>
>>> Do you have any idea what the problem is and how it can be fixed?
>>
>> Please show a longer dump of the make trail, including eg. all the
>> command line options used. You'd probably add a "-v" to CFLAGS. My
>> guess is that somewhere, the cross-targeted compiler chooses to run a
>> i686 assembler or something like that.
>>
>> MfG, JBG
>>
>> --
>>       Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
>> Signature of:             God put me on earth to accomplish a certain number of
>> the second  :            things. Right now I am so far behind I will never die.
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>>
>> iEYEARECAAYFAlD3vR0ACgkQHb1edYOZ4buntwCeL1IAUxrHTF1bp++IV9bZvjYZ
>> avMAn1R7JmwKZj5RrtvNmvOpREt+s49x
>> =Kj4a
>> -----END PGP SIGNATURE-----
>>
>
> --
> For unsubscribe information see http://sourceware.org/lists.html#faq
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Alpha Cross compiler

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]

Hi!

On Wed, 2013-01-23 13:07:07 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
> Thanks for the help. I used -S to generate the assembly code, and by
> looking at it I realized that one of the header files which are included
> there uses an inline assembly function for x86. Therefore, Alpha cross
> compiler is unable to assemble the code since it has x86 specific
> instructions.
> 
> So, does that mean that I need to translate those parts manually from x86
> assembly code to alpha code?

In short: Yes, it does.  With some luck, the software you try to
compile also ships a generic C version along with the (probably)
optimized inline assembler. Maybe it's just some configury needed?

What are you actually trying to build?

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:                   ...und wenn Du denkst, es geht nicht mehr,
the second  :                          kommt irgendwo ein Lichtlein her.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Alpha Cross compiler

[Mahshid Sedghi]

I'm trying to build alpha binaries for a MapReduce framework for
multi-cores called Phoenix++. Phoenix++ is a multi-threaded
application and supports atomic operations like test_and_set and
fetch_and_inc. In fact, these are the operations that are implemented
as inline assembly code.

Mahshid


On Wed, Jan 23, 2013 at 1:09 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> Hi!
>
> On Wed, 2013-01-23 13:07:07 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
>> Thanks for the help. I used -S to generate the assembly code, and by
>> looking at it I realized that one of the header files which are included
>> there uses an inline assembly function for x86. Therefore, Alpha cross
>> compiler is unable to assemble the code since it has x86 specific
>> instructions.
>>
>> So, does that mean that I need to translate those parts manually from x86
>> assembly code to alpha code?
>
> In short: Yes, it does.  With some luck, the software you try to
> compile also ships a generic C version along with the (probably)
> optimized inline assembler. Maybe it's just some configury needed?
>
> What are you actually trying to build?
>
> MfG, JBG
>
> --
>       Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
> Signature of:                   ...und wenn Du denkst, es geht nicht mehr,
> the second  :                          kommt irgendwo ein Lichtlein her.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlEAJ1MACgkQHb1edYOZ4bu2+ACffMUAk494ZT4gSEnj1rSgx380
> NhYAoIJP2KoPXkdBO6zL6Q0w2QA26/nu
> =KvkC
> -----END PGP SIGNATURE-----
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Alpha Cross compiler

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

Hi!

On Wed, 2013-01-23 13:34:16 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
> I'm trying to build alpha binaries for a MapReduce framework for
> multi-cores called Phoenix++. Phoenix++ is a multi-threaded
> application and supports atomic operations like test_and_set and
> fetch_and_inc. In fact, these are the operations that are implemented
> as inline assembly code.

A link to the sources would have been helpful. I guess it's this
project:

	http://mapreduce.stanford.edu/

with the sources being

	http://mapreduce.stanford.edu/plus/phoenix++-1.0.tar.gz

?

If that's your input, how did you ever reach the assembler error? If I
read the sources correctly, along with your description, only x86_64
and SparcV9 are supported ISAs wrt. their atomic.h.  That is, anything
else (ie. Alpha) should have run in an #error...  Other than that,
there's the libatomic_ops project which will probably provide you with
readily-useable functions. I guess it's not a lot of work to change
Phoenix++ to use it.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
  Signature of:                           Wenn ich wach bin, träume ich.
  the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Alpha Cross compiler

[Mahshid Sedghi]

Yes, that's exactly the case. Thanks for looking into that. Wow, that
sounds good. I'll try to modify the source code and use libatomic_ops
instead of current implementation of atomic operations.

Really appreciate your help,
Mahshid


On Wed, Jan 23, 2013 at 3:52 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> Hi!
>
> On Wed, 2013-01-23 13:34:16 -0500, Mahshid Sedghi
> <mahshid.sedghy@gmail.com> wrote:
>> I'm trying to build alpha binaries for a MapReduce framework for
>> multi-cores called Phoenix++. Phoenix++ is a multi-threaded
>> application and supports atomic operations like test_and_set and
>> fetch_and_inc. In fact, these are the operations that are implemented
>> as inline assembly code.
>
> A link to the sources would have been helpful. I guess it's this
> project:
>
>         http://mapreduce.stanford.edu/
>
> with the sources being
>
>         http://mapreduce.stanford.edu/plus/phoenix++-1.0.tar.gz
>
> ?
>
> If that's your input, how did you ever reach the assembler error? If I
> read the sources correctly, along with your description, only x86_64
> and SparcV9 are supported ISAs wrt. their atomic.h.  That is, anything
> else (ie. Alpha) should have run in an #error...  Other than that,
> there's the libatomic_ops project which will probably provide you with
> readily-useable functions. I guess it's not a lot of work to change
> Phoenix++ to use it.
>
> MfG, JBG
>
> --
>       Jan-Benedict Glaw      jbglaw@lug-owl.de
> +49-172-7608481
>   Signature of:                           Wenn ich wach bin, träume ich.
>   the second  :
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlEATYYACgkQHb1edYOZ4buffACeK3uoRA+UcfTwWhFME/qFvsn3
> hMYAoJECxK4VfrqA2n9l2PXVqXJWsxWi
> =TSuY
> -----END PGP SIGNATURE-----
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Alpha Cross compiler

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 736 bytes --]

On Wed, 2013-01-23 18:34:52 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
> On Wed, Jan 23, 2013 at 3:52 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de>wrote:
> > On Wed, 2013-01-23 13:34:16 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
[...]

> > If that's your input, how did you ever reach the assembler error? If I

Could you tell us, please? There must be some other bug somewhere,
because you should have never reached that error message you initially
got.

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:                     Eine Freie Meinung in einem Freien Kopf
the second  :                   für einen Freien Staat voll Freier Bürger.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Alpha Cross compiler

[Mahshid Sedghi]

Yes, in the documentation says that  sparc and x86 are supported. In
fact, they define the ISA as a macro which is set based on the target
system ISA. I set it to __x86_64__ in the files where it needed to be
defined, but didn't notice that atomic.h is using inline assembly
functions of either sparc or x86. So, the alpha cross compiler tries
to assemble the generated assembly code to build the object files, but
it fails since there are some x86-specific instructions.

Mahshid


On Thu, Jan 24, 2013 at 3:13 AM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Wed, 2013-01-23 18:34:52 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
>> On Wed, Jan 23, 2013 at 3:52 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de>wrote:
>> > On Wed, 2013-01-23 13:34:16 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
> [...]
>
>> > If that's your input, how did you ever reach the assembler error? If I
>
> Could you tell us, please? There must be some other bug somewhere,
> because you should have never reached that error message you initially
> got.
>
> MfG, JBG
>
> --
>       Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
> Signature of:                     Eine Freie Meinung in einem Freien Kopf
> the second  :                   für einen Freien Staat voll Freier Bürger.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlEA7SgACgkQHb1edYOZ4bvTlwCcDhU+Xw3auWJNET5j2TiWIJMR
> 8qUAn3k9bvJ+04JxSqAm3ffo4HihMnL6
> =oG/T
> -----END PGP SIGNATURE-----
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Alpha Cross compiler

[Mahshid Sedghi]

Hello again,

I actually replaced the inline assembly code with some c++ atomic
operations such as "fetch_and_inc", and now I am able to cross compile
the application for alpha. But when I run the binaries in the guest OS
using an alpha image, I am getting the following errors:

./word_count: /lib/libc.so.6.1: version `GLIBC_2.4' not found
(required by ./word_count)
./word_count: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.10' not
found (required by ./word_count

Even when I use static linking (using -static-libgcc), the problem
still remains. For some reason, it seems that static linking does not
work, and the application is trying to access those shared objects at
runtime, but it is not found in the alpha disk image. Do you have any
solution for this problem?

Thank you,
Mahshid


On Thu, Jan 24, 2013 at 6:05 PM, Mahshid Sedghi
<mahshid.sedghy@gmail.com> wrote:
> Yes, in the documentation says that  sparc and x86 are supported. In
> fact, they define the ISA as a macro which is set based on the target
> system ISA. I set it to __x86_64__ in the files where it needed to be
> defined, but didn't notice that atomic.h is using inline assembly
> functions of either sparc or x86. So, the alpha cross compiler tries
> to assemble the generated assembly code to build the object files, but
> it fails since there are some x86-specific instructions.
>
> Mahshid
>
>
> On Thu, Jan 24, 2013 at 3:13 AM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
>> On Wed, 2013-01-23 18:34:52 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
>>> On Wed, Jan 23, 2013 at 3:52 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de>wrote:
>>> > On Wed, 2013-01-23 13:34:16 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
>> [...]
>>
>>> > If that's your input, how did you ever reach the assembler error? If I
>>
>> Could you tell us, please? There must be some other bug somewhere,
>> because you should have never reached that error message you initially
>> got.
>>
>> MfG, JBG
>>
>> --
>>       Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
>> Signature of:                     Eine Freie Meinung in einem Freien Kopf
>> the second  :                   für einen Freien Staat voll Freier Bürger.
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (GNU/Linux)
>>
>> iEYEARECAAYFAlEA7SgACgkQHb1edYOZ4bvTlwCcDhU+Xw3auWJNET5j2TiWIJMR
>> 8qUAn3k9bvJ+04JxSqAm3ffo4HihMnL6
>> =oG/T
>> -----END PGP SIGNATURE-----
>>

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Alpha Cross compiler

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1665 bytes --]

On Mon, 2013-02-11 14:41:29 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
> Hello again,
> 
> I actually replaced the inline assembly code with some c++ atomic
> operations such as "fetch_and_inc", and now I am able to cross compile
> the application for alpha. But when I run the binaries in the guest OS
> using an alpha image, I am getting the following errors:
> 
> ./word_count: /lib/libc.so.6.1: version `GLIBC_2.4' not found
> (required by ./word_count)
> ./word_count: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.10' not
> found (required by ./word_count
> 
> Even when I use static linking (using -static-libgcc), the problem
> still remains. For some reason, it seems that static linking does not
> work, and the application is trying to access those shared objects at
> runtime, but it is not found in the alpha disk image. Do you have any
> solution for this problem?

Basically, the libc (and its headers) used for compilation needs to be
the same as on the target system, or older. So you should either use
the libc you just built along with the cross-compiler, or use your
target's headers to build with.

For static linking, -static is the most important part. libgcc is
another component handled specifically. To see if a program uses
dynamically linked libs, you can use the `ldd' program to see what's
dynamically linked by the dynamic linker. (Another way is to use
readelf or objdump so peek into the binary.)

MfG, JBG

-- 
      Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
Signature of:          GDB has a 'break' feature; why doesn't it have 'fix' too?
the second  :

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Alpha Cross compiler

[Mahshid Sedghi]

Thanks for your response. My application is a multi-threaded one, and
when I use -static along with -v, it's showing me that on the first
hand it's unable to find pthread library. I can see a lib folder in
the cross compiler directory containing both shared objects and static
versions of the libraries needed. Although I gave the path to to this
folder using -L option, it still cannot find them!



On Wed, Feb 13, 2013 at 3:13 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de> wrote:
> On Mon, 2013-02-11 14:41:29 -0500, Mahshid Sedghi <mahshid.sedghy@gmail.com> wrote:
>> Hello again,
>>
>> I actually replaced the inline assembly code with some c++ atomic
>> operations such as "fetch_and_inc", and now I am able to cross compile
>> the application for alpha. But when I run the binaries in the guest OS
>> using an alpha image, I am getting the following errors:
>>
>> ./word_count: /lib/libc.so.6.1: version `GLIBC_2.4' not found
>> (required by ./word_count)
>> ./word_count: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.10' not
>> found (required by ./word_count
>>
>> Even when I use static linking (using -static-libgcc), the problem
>> still remains. For some reason, it seems that static linking does not
>> work, and the application is trying to access those shared objects at
>> runtime, but it is not found in the alpha disk image. Do you have any
>> solution for this problem?
>
> Basically, the libc (and its headers) used for compilation needs to be
> the same as on the target system, or older. So you should either use
> the libc you just built along with the cross-compiler, or use your
> target's headers to build with.
>
> For static linking, -static is the most important part. libgcc is
> another component handled specifically. To see if a program uses
> dynamically linked libs, you can use the `ldd' program to see what's
> dynamically linked by the dynamic linker. (Another way is to use
> readelf or objdump so peek into the binary.)
>
> MfG, JBG
>
> --
>       Jan-Benedict Glaw      jbglaw@lug-owl.de              +49-172-7608481
> Signature of:          GDB has a 'break' feature; why doesn't it have 'fix' too?
> the second  :
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAlEb8+IACgkQHb1edYOZ4buzzACfQJjl1dzbCc8ZSn5ARkGJ+6G1
> UgEAnRB75KazpCAzTx6mEYy35+dcSfCt
> =AJR7
> -----END PGP SIGNATURE-----
>

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Re: Alpha Cross compiler

[Mahshid Sedghi]

Hello.

I actually have no question for you this time. Instead, I just want to
give an update on the status of the problem I was facing. I finally
could get my cross compiled benchmarks to work on an alpha image. As
you mentioned, I used "-static" option for gcc, and also used "-L"
followed by the path to the static libraries of the cross compiler.
Initially I had problems with glibc and libc versions, although I was
linking statically. So, I tried cross compiling on a machine whose gcc
and glibc was pretty close to the cross compiler's, and then it
worked.

Thanks for your help,
Mahshid


On Thu, Feb 14, 2013 at 12:21 AM, Mahshid Sedghi
<mahshid.sedghy@gmail.com> wrote:
>
> Thanks for your response. My application is a multi-threaded one, and
> when I use -static along with -v, it's showing me that on the first
> hand it's unable to find pthread library. I can see a lib folder in
> the cross compiler directory containing both shared objects and static
> versions of the libraries needed. Although I gave the path to to this
> folder using -L option, it still cannot find them!
>
>
>
> On Wed, Feb 13, 2013 at 3:13 PM, Jan-Benedict Glaw <jbglaw@lug-owl.de>
> wrote:
> > On Mon, 2013-02-11 14:41:29 -0500, Mahshid Sedghi
> > <mahshid.sedghy@gmail.com> wrote:
> >> Hello again,
> >>
> >> I actually replaced the inline assembly code with some c++ atomic
> >> operations such as "fetch_and_inc", and now I am able to cross compile
> >> the application for alpha. But when I run the binaries in the guest OS
> >> using an alpha image, I am getting the following errors:
> >>
> >> ./word_count: /lib/libc.so.6.1: version `GLIBC_2.4' not found
> >> (required by ./word_count)
> >> ./word_count: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.10' not
> >> found (required by ./word_count
> >>
> >> Even when I use static linking (using -static-libgcc), the problem
> >> still remains. For some reason, it seems that static linking does not
> >> work, and the application is trying to access those shared objects at
> >> runtime, but it is not found in the alpha disk image. Do you have any
> >> solution for this problem?
> >
> > Basically, the libc (and its headers) used for compilation needs to be
> > the same as on the target system, or older. So you should either use
> > the libc you just built along with the cross-compiler, or use your
> > target's headers to build with.
> >
> > For static linking, -static is the most important part. libgcc is
> > another component handled specifically. To see if a program uses
> > dynamically linked libs, you can use the `ldd' program to see what's
> > dynamically linked by the dynamic linker. (Another way is to use
> > readelf or objdump so peek into the binary.)
> >
> > MfG, JBG
> >
> > --
> >       Jan-Benedict Glaw      jbglaw@lug-owl.de
> > +49-172-7608481
> > Signature of:          GDB has a 'break' feature; why doesn't it have
> > 'fix' too?
> > the second  :
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.10 (GNU/Linux)
> >
> > iEYEARECAAYFAlEb8+IACgkQHb1edYOZ4buzzACfQJjl1dzbCc8ZSn5ARkGJ+6G1
> > UgEAnRB75KazpCAzTx6mEYy35+dcSfCt
> > =AJR7
> > -----END PGP SIGNATURE-----
> >

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Alpha cross compiler

[Mongkol Ekpanyapong]

I successfuly  installed gcc 3.1 cross compiler for Alpha machine on my
x86 redhat 7.2. However cross compiler only successfully generate ELF
format, but the program that I'm using accept
only ECOFF format.
When I try to generate ECOFF, below is error messages:

/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o: In function `_start':
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x8): relocation
truncated to fit: GPDISP .text+4
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x14): relocation
truncated to fit: ELF_LITERAL main
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x20): undefined
reference to `_init'
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x24): undefined
reference to `_fini'
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x30): undefined
reference to `__libc_start_main'
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x34): undefined
reference to `__libc_start_main'

Any suggestion are welcome?
Thanks,

--
Mongkol Ekpanyapong
The School of Electrical and Computer Engineering at Georgia Tech
Atlanta, GA  30332-0250
E-Mail: pop@ece.gatech.edu, gtg726c@prism.gatech.edu


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com

Alpha cross compiler

[Mongkol Ekpanyapong]

I successfuly  installed gcc 3.1 cross compiler for Alpha machine on my
x86 redhat 7.2. However cross compiler only successfully generate ELF
format, but the program that I'm using accept
only ECOFF format.
When I try to generate ECOFF, below is error messages:

/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o: In function `_start':
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x8): relocation
truncated to fit: GPDISP .text+4
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x14): relocation
truncated to fit: ELF_LITERAL main
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x20): undefined
reference to `_init'
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x24): undefined
reference to `_fini'
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x30): undefined
reference to `__libc_start_main'
/home/pop/crossdev/alpha-linuxecoff/lib/crt1.o(.text+0x34): undefined
reference to `__libc_start_main'

Any suggestion are welcome?
Thanks,

--
Mongkol Ekpanyapong
The School of Electrical and Computer Engineering at Georgia Tech
Atlanta, GA  30332-0250
E-Mail: pop@ece.gatech.edu, gtg726c@prism.gatech.edu


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com