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 2Any 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. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/
On Apr 30, 2008, at 23:19, james woodyatt wrote:> > 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 2The 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_0I'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? — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/ -- j h woodyatt <jhw at conjury.org>
On Apr 30, 2008, at 11:19 PM, james woodyatt wrote:>> $TMPFILE:66: Error: internal_relocation (type: OFFSET_IMM) not >> fixed upYou 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.
On May 1, 2008, at 15:20, Mike Stump wrote:> On Apr 30, 2008, at 11:19 PM, james woodyatt wrote: >>> $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> for instructions. > make[2]: *** [libgcc/./_muldc3.o] Error 1 > make[1]: *** [stmp-multilib] Error 2 > make: *** [all-gcc] Error 2I'm pretty sure this is a compiler bug. I'm grinding away on it, but I'm a total newbie here. — j h woodyatt <jhw at conjury.org> http://jhw.vox.com/ -- j h woodyatt <jhw at conjury.org> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080501/a86bf1e9/attachment.html>