On Sun, 22 Apr 2007, Jochen Kunz wrote:
> On Fri, 20 Apr 2007 20:52:45 +0000 (UTC)
> Eduardo Horvath <eeh NetBSD.org> wrote:
>
> > If you specify -mcpu=v9 to gcc it will both enable
V9 instructions
> > and switch to a 64-bit memory model, which is
probably not what you
> > want. That will generate ELF64 object files
which cannot be linked
> > with ELF32 binaries, use the full LP64
programming model, as well as
> > a 64-bit stack which will cause alignment errors
if you ever managed
> > to try to execute that code.
> Hmmm. When I run file(1) on a binary generatd by my V9
build, I get the
> same as for a binary generated by a native pkgsrc
build:
> [jkunzKriggle jkunz]$ file /bin/sh /usr/pkg/bin/fvwm2
> /bin/sh: ELF 32-bit MSB executable,
SPARC32PLUS, V8+
> Required, version 1 (SYSV), for NetBSD 4.99.17,
dynamically linked (uses
> shared libs), not stripped
> /usr/pkg/bin/fvwm2: ELF 32-bit MSB executable,
SPARC32PLUS, V8+
> Required, version 1 (SYSV), for NetBSD 4.99.17,
dynamically linked (uses
> shared libs), stripped
> [jkunzKriggle jkunz]$ gcc --version
> gcc (GCC) 4.1.2 20070110 prerelease (NetBSD nb1
20070110)
>
> > -m32 -Wa,-Av8plusa -mcpu=ultrasparc
> I did a build with this settings and it succeeded. But
I haven't run the
> result on actual hardware. file(1) reports the same
executable type for
> binaries of this build as for my V9 build.
>
> Maybe gcc falls back to V8+ if V9 is specified without
-m64?
It's not gcc that generates the object file. gcc only
generates the
assembly code. It's gas that generates the object file.
gas probably
defaults to 32-bit ELF. However, you should be careful
here. The ELF
size specifies the format for segment specifications and
relocations but
has nothing to do with the instructions in the image. It
could be that
gcc generates 64-bit ABI compliant assembly code that gas
assembles into a
32-bit ELF object file. This would allow the object to be
linked with
other 32-bit object files but will crash if routines in it
are ever
invoked.
Eduardo
|
