Hi,
Is it possible to build DROPS on 64bit HOST OS for 32bit TARGET (architecture there Fiasco will be executed) if corresponding cross-compiler is already available? I tried but it looks like DICE ignores TARGET architecture and generates IPC code for HOST architecture (64 bit). It seems that there are no problems with Fiasco, L4Env and L4Linux.
Best Regards, Alexander Valitov
On Tue Mar 17, 2009 at 09:41:42 -0700, Alexander Valitov wrote:
Is it possible to build DROPS on 64bit HOST OS for 32bit TARGET (architecture there Fiasco will be executed) if corresponding cross-compiler is already available? I tried but it looks like DICE ignores TARGET architecture and generates IPC code for HOST architecture (64 bit). It seems that there are no problems with Fiasco, L4Env and L4Linux.
Actually it should work a bit but I recommend to use a 32bit built dice version to generate 32bit code on 64bit hosts as there are some subtle issues which seem to get some bits wrong.
Adam
Hi,
I use following command to configure DICE: $ ./configure --build=x86_64-linux --host=x86_64-linux --target=i686-linux ,here: 'build' is architecture where DICE is built; 'host' is architecture where DICE will be executed; 'target' is architecture for which DICE is to generate code. I believe these are kind of default options for tools that generate code.
I’m sure there shall be no difference between outputs of DICE built this way: $ ./configure --build=x86_64-linux --host=x86_64-linux --target=i686-linux and this way: $ ./configure --build=x86_64-linux --host= i686-linux --target=i686-linux
But there are differences (it’s not only in headers):
--- 64-bit-dice/pkg/ore/idl/OBJ-x86-l4v2/ore_rxtx-server.h 2009-03-16 18:08:10.687109855 +0300 +++ 32-bit-dice/pkg/ore/idl/OBJ-x86-l4v2/ore_rxtx-server.h 2009-03-16 15:34:52.000000000 +0300 @@ -2,8 +2,8 @@ * THIS FILE IS MACHINE GENERATED! DO NOT EDIT! * * ore_rxtx-server.h - * created on Mon Mar 16 18:08:10 2009 - * with Dice version 3.3.0 (compiled on Mar 13 2009 16:16:51) + * created on Mon Mar 16 12:34:52 2009 + * with Dice version 3.3.0 (compiled on Mar 6 2009 15:22:19) * send bug reports to dice@os.inf.tu-dresden.de */
@@ -34,7 +34,7 @@
#if !defined(__TYPEDEF_ORE_RXTX_MSG_BUFFER_T__) #define __TYPEDEF_ORE_RXTX_MSG_BUFFER_T__ -/* size = 72 bytes == 18 dwords */ +/* size = 40 bytes == 10 dwords */ typedef union ore_rxtx_msg_buffer_t { struct @@ -80,6 +80,7 @@ l4_msgdope_t _dice_size_dope; l4_msgdope_t _dice_send_dope; l4_umword_t _word[2]; + l4_umword_t _dice_pad_strdope_with_mword; l4_strdope_t _strings[1]; } _word; } ore_rxtx_msg_buffer_t;
--- 64-bit-dice/pkg/signal/idl/OBJ-x86-l4v2/signal-server.h 2009-03-16 18:04:58.777109868 +0300 +++ 32-bit-dice/pkg/signal/idl/OBJ-x86-l4v2/signal-server.h 2009-03-16 15:35:24.000000000 +0300 ........snipped...... @@ -100,8 +100,8 @@ l4_msgdope_t _dice_size_dope; l4_msgdope_t _dice_send_dope; l4_umword_t _exception; - siginfo_t _dice_return; l4_threadid_t thread; + siginfo_t _dice_return; } signal_receive_signal_out; struct { @@ -138,7 +138,7 @@ l4_fpage_t _dice_rcv_fpage; l4_msgdope_t _dice_size_dope; l4_msgdope_t _dice_send_dope; - l4_umword_t _word[23]; + l4_umword_t _word[37]; } _word; } signal_signal_msg_buffer_t; #endif /* __TYPEDEF_SIGNAL_SIGNAL_MSG_BUFFER_T__ */
@@ -158,14 +158,14 @@ signal_signal_kill_unmarshal (CORBA_Object _dice_corba_obj, l4_threadid_t *thread /* in */, siginfo_t *signal /* in */, - signal_signal_msg_buffer_t *_dice_msg_buffer_dummy /* in */, + signal_signal_msg_buffer_t + *_dice_msg_buffer /* in */, CORBA_Server_Environment *_dice_corba_env);
void DICE_CV signal_signal_kill_marshal (CORBA_Object _dice_corba_obj, int _dice_return /* out */, l4_msgtag_t *_dice_tag, - signal_signal_msg_buffer_t *_dice_msg_buffer_dummy, + signal_signal_msg_buffer_t + *_dice_msg_buffer, CORBA_Server_Environment *_dice_corba_env);
Options that are passed to DICE in both cases are the same: '-P-DSYSTEM_x86_l4v2', '-P-DARCH_x86', '-P-DCPUTYPE_586', '-P-DL4API_l4v2', '-Bpia32', etc.
Adam Lackorzynski wrote:
I recommend to use a 32bit built dice version to generate 32bit code on 64bit hosts.
Unfortunately it is not general solution as not every amd64 machine has ia32 libraries installed by default and 32 bit native build requires some hacks in the build system, so plain 32-bit dice usage is not that easy. And what if the target will change to amd64 will 32-bit dice work fine or 64-bit version will be needed? What happens if you throw ARM in there? ia32 -> amd64 cross build? So the question is: are there any plans to fix it?
Maybe someone knows to whom shall I apply with the issue? Who maintains the project? MAINTAINER file says that ra3 at os.inf.tu-dresden.de is email of current maintainer. Is it valid?
Best Regards, Alexander Valitov
Hi,
There is a fix for the issue: http://www.nabble.com/Patch-for-DICE-that-fix-issue-with-AMD64-host-td225998...
thanks to Roman I Khimov for the patch
Best Regards, Alexander Valitov
l4-hackers@os.inf.tu-dresden.de