Build DROPS on 64bit Host for 32bit Target

[Alexander Valitov]

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 at 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

-- 
View this message in context: http://www.nabble.com/Build-DROPS-on-64bit-Host-for-32bit-Target-tp22563295p22582879.html
Sent from the L4 mailing list archive at Nabble.com.