building cross llvm-gcc for new target

everyone--

I'm trying to build LLVM-GCC as a cross-compiler for a new target.

I've successfully patched binutils, the FSF GCC, LLVM and Clang to build for this new target-- they work fine, but the LLVM-gcc build is failing for me. All my llvm.org sources are tracking the Subversion trunk, but my problem is probably not related to any ongoing churn there. I'm doing something dumb, and I need to figure out what.

I get errors trying to build from crtbegin.o, and they look like this (replacing the long temporary filename with $TMPFILE):

$TMPFILE: Assembler messages:
$TMPFILE:66: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$TMPFILE:71: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$TMPFILE:76: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$TMPFILE:87: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$TMPFILE:91: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$TMPFILE:180: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$TMPFILE:184: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$TMPFILE:185: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$TMPFILE:188: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$TMPFILE:193: Error: internal_relocation (type: OFFSET_IMM) not fixed up
$TMPFILE:200: Error: internal_relocation (type: OFFSET_IMM) not fixed up
make[3]: *** [crtbegin.o] Error 1
make[2]: *** [extra] Error 2
make[1]: *** [stmp-multilib] Error 2
make: *** [all-gcc] Error 2

Any tips that lead to the isolation of this issue will be graciously accepted. If I figure this out, I'll report back here what I'm doing wrong. If I don't, then I will probably bag on compiling libgcc2 for now and come back to it later.

I'm trying to build LLVM-GCC as a cross-compiler for a new target.
[...]
I get errors trying to build from crtbegin.o, and they look like this
(replacing the long temporary filename with crtstuff.s):

crtstuff.s: Assembler messages:
crtstuff.s:66: Error: internal_relocation (type: OFFSET_IMM) not fixed up

[...]

make[3]: *** [crtbegin.o] Error 1
make[2]: *** [extra] Error 2
make[1]: *** [stmp-multilib] Error 2
make: *** [all-gcc] Error 2

The first of these errors above happens on the line in the excerpt below with the ldr instruction.

  .align 2
call___do_global_dtors_aux:
  stmfd sp!, {r4, lr}
  @ InlineAsm Start
    .section .fini
  @ InlineAsm End
  ldr r3, .LCPI2_0

I'm trying not to get distracted by what seems to be the oddness of changing the section in the middle of a function block, because it looks like this is precisely how CRT_CALL_STATIC_FUNCTION is designed to work. Okay, I can roll with that, but I think this is a clue.

# define CRT_CALL_STATIC_FUNCTION(SECTION_OP, FUNC) \
static void __attribute__((__used__)) \
call_ ## FUNC (void) \
{ \
asm (SECTION_OP); \
FUNC (); \
FORCE_CODE_SECTION_ALIGN \
asm (TEXT_SECTION_ASM_OP); \
}

Hmmm. That is one *cryptic* error message the assembler is generating, isn't it?

You need to run the compile with -save-temps and then look at the .s file. If you like it, it is an assembler bug. If you don't like it, it is a bug in the compiler. If you don't know if you like it, as your assembler vendor (binutils) if it is valid.

Off hand I'd say that you had an immediate offset that didn't resolve to something that is valid.

$TMPFILE:66: Error: internal_relocation (type: OFFSET_IMM) not

fixed up

You need to run the compile with -save-temps and then look at the .s
file. If you like it, it is an assembler bug. If you don’t like it,
it is a bug in the compiler. If you don’t know if you like it, as
your assembler vendor (binutils) if it is valid.

Did all that. My previous message shows the relevant excerpts.

p1. It doesn’t look to me like obviously invalid assembly.

p2. Compiling with -O0 makes the problem go away.

p3. I think the recent change to $LLVM_GCC/gcc/llvm-backend.cpp to respect the -fno-inline-functions flag makes the need for the -O0 workaround go away.

I still think there might be something broken in the compiler there somewhere, but whatever…

Now, I’m seeing this…

GNU C version 4.2.1 (Based on Apple Inc. build 5555) (LLVM build)
compiled by GNU C version 4.0.1 (Apple Inc. build 5478).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 20fbcaab58f1b058dae351db930ef9ce
Assertion failed: (0 && “Do not know how to return this many arguments!”), function LowerRET, file /Volumes/Space/p4client/orca/import/llvm.org/llvm/lib/Target/ARM/ARMISelLowering.cpp, line 667.
…/…/…/…/…/…/import/llvm.org/llvm-gcc/gcc/libgcc2.c:1914: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:[http://developer.apple.com/bugreporter](http://developer.apple.com/bugreporter) for instructions.
make[2]: *** [libgcc/./_muldc3.o] Error 1
make[1]: *** [stmp-multilib] Error 2
make: *** [all-gcc] Error 2

I’m pretty sure this is a compiler bug. I’m grinding away on it, but I’m a total newbie here.