[LLVMdev] striping of stdio information in llvm-gcc and clang

[Linlin Cheng]

Hi,

I have the following test code print.c:

#include <stdio.h>

int main(){
	fprintf(stderr, "Error!\n");
	return 0;
}

I did the following on linux to cross-compile it for Sparc architecture:
clang -m32 -c print.c -emit-llvm -o print.bc
(or llvm-gcc -m32 -c print.c -emit-llvm -o print.bc)

llvm-dis < print.bc -o print2.bc

llc -march=sparc -mcpu=v8 print2.bc -o print_s.s

if I compile it on Sparc using gcc 3.4
gcc print_s.s -o print_linux

it gives me the following error:
Undefined                       first referenced
 symbol                             in file
stderr                              /var/tmp//ccGa4Zxh.o
ld: fatal: Symbol referencing errors. No output written to print_linux
collect2: ld returned 1 exit status


I compiled the same code on Sparc directly, the .s file is the
following without 'stderr'

	.file	"print.c"
	.section	".rodata"
	.align 8
.LLC0:
	.asciz	"Error!\n"
	.section	".text"
	.align 4
	.global main
	.type	main, #function
	.proc	04
main:
	!#PROLOGUE# 0
	save	%sp, -112, %sp
	!#PROLOGUE# 1
	sethi	%hi(__iob+32), %g1
	or	%g1, %lo(__iob+32), %o0
	sethi	%hi(.LLC0), %g1
	or	%g1, %lo(.LLC0), %o1
	call	fprintf, 0
	 nop
	mov	0, %g1
	mov	%g1, %i0
	ret
	restore
	.size	main, .-main
	.ident	"GCC: (GNU) 3.4.6"

While the .s file generated by llc gives the following code with
'stderr' as a symbol.

	.file	"print2.bc"
	.text
	.globl	main
	.align	4
	.type	main, at function
main:                                   ! @main
! BB#0:
	save %sp, -104, %sp
	sethi 0, %i0
	sethi %hi(stderr), %l0
	st %i0, [%fp+-4]
	ld [%l0+%lo(stderr)], %o0
	sethi %hi(.L.str), %l0
	add %l0, %lo(.L.str), %o1
	call fprintf
	nop
	restore %g0, %g0, %g0
	retl
	nop
.Ltmp0:
	.size	main, .Ltmp0-main

	.type	.L.str, at object          ! @.str
	.section	.rodata.str1.1,"aMS", at progbits,1
.L.str:
	.asciz	 "Error!\n"
	.size	.L.str, 8

Apparently the 'stderr' is not resolved in the linking stage. I tried
adding '-lstdio' in the gcc link stage but it does not work.

Anyone has any idea about how this problem can be resolved?

Thanks,

Christine