Re: [ECOS] Synthetic target on linux x86_64 host

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Nick" == Nick Garnett <nickg@ecoscentric.com> writes:

    <snip>
    Nick> I have also been running the synthetic target on my OpenSuSE
    Nick> 11.0 x86_64 system. I can do this without making any changes
    Nick> to eCos sources at all.

    Nick> I compile using the native "gcc" compiler, adding the -m32
    Nick> flag. The default configuration tries to use
    Nick> i686-pc-linux-gnu-gcc, so I have put a script of that name
    Nick> in my path that simply contains the line "gcc -m32 $*". I
    Nick> have also had to define i686-pc-linux-gnu-ar to "ar $*".
    Nick> Those are the only two tools used during a build, and the
    Nick> standard native "gdb" then works to debug.

Interesting. That suggest something like the following patch should
sort out the target-side:

Index: hal_synth_i386.cdl
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/synth/i386linux/current/cdl/hal_synth_i386.cdl,v
retrieving revision 1.7
diff -u -p -r1.7 hal_synth_i386.cdl
--- hal_synth_i386.cdl2 Feb 2009 17:56:43 -00001.7
+++ hal_synth_i386.cdl7 May 2009 11:32:31 -0000
@@ -104,7 +104,9 @@ cdl_package CYGPKG_HAL_SYNTH_I386 {
             display "Global command prefix"
             flavor  data
             no_define
-    if { ($tcl_platform(os) == "Linux") && [string match "i*86" $tcl_platform(machine)] } {
+    if { ($tcl_platform(os) == "Linux") &&
+             ([string match "i*86" $tcl_platform(machine)] ||
	       +              [string match "x86_64" $tcl_platform(machine)]) } {
default_value { "" }
    } else {
default_value { "i686-pc-linux-gnu" }
@@ -120,7 +122,9 @@ cdl_package CYGPKG_HAL_SYNTH_I386 {
             display "Global compiler flags"
             flavor  data
             no_define
-            default_value { CYGBLD_GLOBAL_WARNFLAGS . " -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions " }
+            default_value { CYGBLD_GLOBAL_WARNFLAGS .
+                ([string match "x86_64" $tcl_platform(machine)] ? " -m32" : "") .
+                " -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions " }
             description   "
                 This option controls the global compiler flags which
                 are used to compile all packages by
@@ -132,7 +136,8 @@ cdl_package CYGPKG_HAL_SYNTH_I386 {
             display "Global linker flags"
             flavor  data
             no_define
-            default_value { "-g -nostdlib -Wl,--gc-sections -Wl,-static" }
+            default_value { ([string match "x86_64" $tcl_platform(machine)] ? "-m32 " : "") .
+                "-g -nostdlib -Wl,--gc-sections -Wl,-static" }
             description   "
                 This option controls the global linker flags. Individual
                 packages may define options which override these global flags."

Possibly the -m32 should be a hard requirement, not just a default
setting.

    Nick> Like Ross, I have the 32 bit compatibility libraries
    Nick> installed, together with the development packages for some.
    Nick> eCos synthetic target executables are not dynamically
    Nick> linked, so it may be necessary to install the static
    Nick> versions of libraries you already have in dynamic form. I
    Nick> simply used trial and error to work out which libraries were
    Nick> needed: try a build, work out which header or library is
    Nick> missing, find out which RPM it comes from, install that and
    Nick> repeat. The exact combination will obviously depend on how a
    Nick> specific distribution divided things up into packages, and
    Nick> what you might already have installed.

This is indeed where things get messy. On 32-bit machines the
synthetic target currently needs static versions of libgcc.a,
libsupc++, and libgcc_eh.a. I suspect the same will be true when
building with a 64-bit gcc and -m32, but there is no easy way of
knowing what strange things the compiler folks may have done. It also
seems unlikely that the various distributions will be consistent about
any of this. Unfortunately all the machines I use regularly are
32-bit, not 64-bit, so I cannot do a lot of experimenting.

That still leaves the host-side, i.e. ecosynth, rawether, ... I
would not expect major 64-bit problems with any of those, and there
should be no sharing of pointers between the host and target sides.
However the current autoconf-based build mechanism for those only
supports 32-bit mode, and updating it for 64-bit builds has not been a
priority to date.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss