[OpenAFS-devel] solaris 10 x86 64-bit lwp compile issues

Marcus Watts mdw@umich.edu
Tue, 12 Dec 2006 02:50:57 -0500


omalleys@msu.edu writes:
> From: "Sean O'Malley" <omalleys@msu.edu>
> To: <openafs-devel@openafs.org>
> Subject: [OpenAFS-devel] solaris 10 x86 64-bit lwp compile issues
> Date: Tue, 12 Dec 2006 00:55:34 -0500 (EST)
> 
> In my quest to get our new machines running all 64-bit code. I was trying
> to get aklog linked against the kerberos 64-bit libraries, and of course
> it didnt work because the libraries are all 32-bit and the linker gave me
> all sorts of xmas elf32 errors.  I am using the sun studio 11 compiler.
> 
> I mucked with the configure files and got the 64-bit flags in. It crapped
> out at '(stdin->_cnt > 0)' line like 178 of lwp/waitkey.c (undefined
> structure _cnt error)..
> 
> I changed that to if (getc_unlocked(stdin) > 0)
> which surprisingly compiled (i wont say it works...)
> 
> Now it is hung up in lwp trying to do the inline of assembly code..
> 
> if I use the process.i386.s code it compiles and ar has no problems until
> you get to somewhere way down the line and then i get to
> /opt/dloads/openafs-1.4.2/src/sys
>  where it is creating rmtsysd
> 
> i get:
> Undefined symbols in (first referenced in) liblwp.a
> for savecontext and for returnto. (and if you run nm on them they exist..)
> 
> 
> If I try to use the process.amd64.s code i get totally horked
> + /usr/ccs/lib/cpp -P -D__i386 -D__sun -DIGNORE_STDS_H
> -I/opt/dloads/openafs-1.4.2/include -I. ./process.amd64.s process.ss
> + as -o process.o process.ss
> Assembler: process.s
>         "process.ss", line 129 : Illegal mnemonic
>         Near line: "    pushq   %rbp                    "
>         "process.ss", line 129 : Illegal register: "rbp"
>         "process.ss", line 129 : Syntax error
>         Near line: "    pushq   %rbp                    "
>         "process.ss", line 130 : Illegal register: "rsp"
>         "process.ss", line 130 : Syntax error
>         Near line: "    movq    %rsp,%rbp"
>         "process.ss", line 130 : Illegal register: "rbp"
>         "process.ss", line 131 : Illegal mnemonic
>         Near line: "    subq    $32, %rsp               "
>         "process.ss", line 131 : Illegal register: "rsp"
>         "process.ss", line 131 : Syntax error
>         Near line: "    subq    $32, %rsp               "
>         "process.ss", line 132 : Illegal register: "rdi"
>         "process.ss", line 132 : Syntax error
>         Near line: "    movq    %rdi, f(%rbp)           "
>         "process.ss", line 132 : Illegal register: "rbp"
>         "process.ss", line 133 : Illegal register: "rsi"
>         "process.ss", line 133 : Syntax error
>         Near line: "    movq    %rsi, area1(%rbp)       "
>         "process.ss", line 133 : Illegal register: "rbp"
>         "process.ss", line 134 : Illegal register: "rdx"
>         "process.ss", line 134 : Syntax error
>         Near line: "    movq    %rdx, newsp(%rbp)       "
>         "process.ss", line 134 : Illegal register: "rbp"
>         "process.ss", line 138 : Illegal mnemonic
>         Near line: "    pushq   %rsp                    "
>         "process.ss", line 138 : Illegal register: "rsp"
>         "process.ss", line 138 : Syntax error
>         Near line: "    pushq   %rsp                    "
>         "process.ss", line 139 : Illegal mnemonic
>         Near line: "    pushq   %rax                    "
>         "process.ss", line 139 : Illegal register: "rax"
>         "process.ss", line 139 : Syntax error
>         Near line: "    pushq   %rax                    "
>         "process.ss", line 140 : Illegal mnemonic
>         Near line: "    pushq   %rcx                    "
>         "process.ss", line 140 : Illegal register: "rcx"
>         "process.ss", line 140 : Syntax error
>         Near line: "    pushq   %rcx                    "
>         "process.ss", line 141 : Illegal mnemonic
>         Near line: "    pushq   %rdx                    "
>         "process.ss", line 141 : Illegal register: "rdx"
>         "process.ss", line 141 : Syntax error
>         Near line: "    pushq   %rdx                    "
>         "process.ss", line 142 : Illegal mnemonic
>         Near line: "    pushq   %rbx"
> Too many errors - Goodbye
> 
> and of course process.o never gets made so liblwp.a never gets made..
> 
> Does anyone have any ideas or fixes for this? Without taking a crash
> course in assembly language? :)
> 
> 
> 
> --------------------------------------
>   Sean O'Malley, Information Technologist
>   Michigan State University
> -------------------------------------
> 
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
> 

Judging by
	http://docs.sun.com/app/docs/doc/816-5165/6mbb0m9bi?a=view
you probably need -xarch=amd64 (or maybe -xarch=generic64,
though this might be the same thing).  You may also 
need other options, such as -xmodel=SMALL, -xmodel=KERNEL,
or -K PIC .  The exact options are liable to depend on the
environment that object is going into.

With most C compilers, there is various integrated support
for assembly language.  The most useful options are:
	cc -c foo.s
-- take a .s file and turn it into a .o file.  Ie, run the assembler
with compatible options as the equivalent C code.  To do the
inverse of this,
	cc -S foo.c
take a c file, turn it into assembler code.  With many older
environments, the C compiler always produces assembler source,
so this just breaks out of the compiler at an earlier point in
the compilation.  With newer compilers, this isn't so true,
but usually -S will give you something interesting, ideally,
quite a lot about the syntax that particular assembler expects to
process, and perhaps interesting clues as language calling
conventions.  If you want to run the assembler or linker straight,
these are of interest:
	cc -v ...
(or)
	cc -# ...
-v is V7ish; -# is system Vish.  One of these will tell the compiler
compiler's front end (cc) to print out the various back end steps
as they are executed.  With older compilers, those steps might be
	cpp	c preprocessor
	c0 c1 c2 -- names vary, for different passes of the compiler
	as	assembler
	ld	link editor
for modern compilers: gnu 3.3+ collapses cpp into c0+; ibm xlc
combines c0..+as, &etc.

So in general, some variation on
	touch foo.s
	cc -v -c foo.s
ought to tell you how to run the assembler; add options as you
would for C to vary memory model&etc.

All of this is variable and not always well documented by the people
who publish the compiler, but usually there are man pages that describe
the various commands, plus in the better cases, some set of "white papers"
that describe the compiler & tools in more detail.  Sun is better than
most in this regard - a lot seems to even be available by the web.
Some modern c compilers print a usage summary if you just run
cc with no arguments at all.

				-Marcus Watts