Bug 215037 - head -r309179's Clang 3.9.0 for from-amd64 cross built TARGET_ARCH=powerpc64 buildworld uses ATT or Intel inline assembler parsing on powerpc64's lib32 code
Summary: head -r309179's Clang 3.9.0 for from-amd64 cross built TARGET_ARCH=powerpc64 ...
Status: Closed Not Accepted
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: powerpc Any
: --- Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-04 02:34 UTC by Mark Millard
Modified: 2016-12-08 01:58 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mark Millard 2016-12-04 02:34:47 UTC
[Note: on a powerpc64 head -r309179 self-built buildworld based
on its system clang 3.9.0 I had no trouble with building using
"WITH_LIB32=" ; only cross building WITH_LIB32= seems to have the
issue of the wrong machine's assembler notation being involved
for lib32's build attempt.]

Attempting buildworld for powerpc64 (cross built from an amd64 context) using WITH_LIB32= fails with messages such as:
(among other assembler notation rejections)

/root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils_world-amd64-host-2016-11-27:16:56:44:/usr/src/lib/csu/powerpc/crti.S:35:2: error: invalid instruction mnemonic 'mflr'
/root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils_world-amd64-host-2016-11-27:16:56:44:/usr/src/lib/csu/powerpc/crti.S:38:2: error: invalid instruction mnemonic 'mr'
/root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils_world-amd64-host-2016-11-27:16:56:44:/usr/src/lib/csu/powerpc/crti.S:46:2: error: invalid instruction mnemonic 'mflr'
/root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_clang_altbinutils_world-amd64-host-2016-11-27:16:56:44:/usr/src/lib/csu/powerpc/crti.S:49:2: error: invalid instruction mnemonic 'mr'

I tried to find what produced those messages:

# find /usr/src/contrib/llvm/ -type f -exec grep "invalid instruction mnemonic" {} \; -print | more
      return Error(IDLoc, "invalid instruction mnemonic '" + Base + "'",
    return Error(IDLoc, "invalid instruction mnemonic '" + Mnemonic + "'",
/usr/src/contrib/llvm/lib/Target/X86/AsmParser/X86AsmParser.cpp
    return Error(IDLoc, "invalid instruction mnemonic");
/usr/src/contrib/llvm/lib/Target/Sparc/AsmParser/SparcAsmParser.cpp

(No others.)

X86/AsmParser/X86AsmParser.cpp has:

bool X86AsmParser::MatchAndEmitATTInstruction(SMLoc IDLoc, unsigned &Opcode,
. . .
      return Error(IDLoc, "invalid instruction mnemonic '" + Base + "'",
                   Ranges, MatchingInlineAsm);
. . .
bool X86AsmParser::MatchAndEmitIntelInstruction(SMLoc IDLoc, unsigned &Opcode,
. . .
    return Error(IDLoc, "invalid instruction mnemonic '" + Mnemonic + "'",
                 Ranges, MatchingInlineAsm);
. . .

(The Sparc code message does not match the output text fully.)

I did not find anything else in clang/llvm that would produce
the text of the messages output.


Either an internal powerpc assembler decoding should be used or
an external powerpc assembler should be used during the lib32
build. No ATT or Intel instruction assembly should be involved
despite the amd64 host that is involved in this type of cross
build.

Installing the WITHOUT_LIB32= environment on a powerpc64 and
booting it allowed then building WITH_LIB32= on the powerpc64
itself. And booting with the lib32 build installed allows
lib32 use:

# ldd32 /usr/lib32/libgcc_s.so.1 
/usr/lib32/libgcc_s.so.1:
	libc.so.7 => /usr/lib32/libc.so.7 (0x41841000)
# file `which ldd32`
/usr/bin/ldd32: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 12.0 (1200017), FreeBSD-style, stripped


So it seems that there is a HOST vs. TARGET_ARCH confusion in
what assembler notation ends up being set up for TARGET_ARCH's
lib32 build use when it is not matching the HOST's lib32's
notation.
Comment 1 Mark Millard 2016-12-08 01:58:25 UTC
I discovered that the SRC_CONF_ENV file I was
using had some material from an experiment still
in it and that material forced /usr/bin/clang
and /usr/bin/clang++ to be used (the host compiler
for cross builds).

Removing the material and trying built lib32 just
fine for powerpc64.

So this was just my stupid mistake.