[LLVMdev] memcpy and bootstrapping

[Nick Lewycky]

james woodyatt wrote:
> everyone--
> 
> I don't know whether this is a bug or not.

I assume you're using llvm-gcc? Does it still turn memcpy into 
llvm.memcpy if you pass llvm-gcc -ffreestanding? If so, that's certainly 
a bug. Either way, you should be using -ffreestanding!

Nick

> I'm trying to bootstrap an embedded application and using LLVM tools  
> to generate the assembly code, which I then assemble and link with  
> traditional tools.  The bootstrap loader, of course, runs in a very  
> limited environment, and I have to roll my own memcpy() function for  
> it, i.e. there is no kernel, nothing at all, this stuff runs because  
> the hard reset vectors into it.
> 
> Sadly, memcpy() doesn't get linked into my binary.  Why?  Because I  
> wrote it in C, and I'm using the LLVM tools to link everything  
> together before piping it all into llc and generating one big assembly  
> file for the bootstrap loader.  All the bitcode files that expect to  
> be able to call memcpy() have LLVM.memcpy intrinsics in them instead  
> of function calls, and LLVM-LD refuses to link the bitcode file with  
> my hand-rolled function in it because it doesn't actually see any  
> references.  The result: an object file with an undefined reference to  
> memcpy().
> 
> It seems to me like I shouldn't be surprised that LLVM-LD doesn't look  
> for my hand-rolled memcpy().  I'm using -link-as-library with - 
> internalize-public-api-list=_start.  I suppose I'll end up ripping off  
> bcopy.s for ARM from the obvious place, and assembling that for use in  
> the final link.  That should solve my problem.
> 
> I mention it here because it was a little surprising when my memcpy()  
> didn't show up where I expected.
> 
> 
> —
> j h woodyatt <jhw at conjury.org>
> http://jhw.vox.com/
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>