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
>