目的：
ARMアセンブリ/バイナリの出力形式を変更する LLVM バックエンドのパスを実装しました(たとえば、各基本ブロックの最後にジャンプを追加して、フォール スルーを排除します)。次のように呼び出します。
llc -march=arm somefile.bc
arm gnu linuxで適切に動作する、予想されるarmアセンブリ/バイナリを生成します（qemu-armとgem5を使用してシミュレートします）。今度は標準の c ライブラリで同じことをしたいのですが、ここに問題があります。
問題:
によると：
http://article.gmane.org/gmane.comp.compilers.llvm.devel/77025
https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_14/docs/OpenProjects.html#glibc
llvm を使用して glibc をコンパイルすることは、適切なオプションではない可能性があります。一方、次のように述べています。
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/047088.html
llvm は newlib をコンパイルできる可能性があるため、人々は newlib を代替手段と考えています。ただし、次のとおりです。
http://www.embecosm.com/appnotes/ean9/ean9-howto-newlib-1.0.html#id2711887
newlib は、ベア メタル (OS なし) ソフトウェアのバイナリをサポートする予定です。ハードウェアに依存しない部分 (libc や libm など) のみを実装し、ハードウェアに依存するシステムコールごとにスタブを残します (libgloss のすべてなど)。
実際、「--with-newlib」オプションで構成されたarm-none-eabi-gccを使用して単純な「hello world」Cプログラムをコンパイルしようとしましたが、プログラムの実行はqemu-armとgem5の両方でセグメンテーション違反で終了します.
質問:
newlib が glibc と互換性があるかどうかはわかりません。llvm を使用して、newlib からマシンに依存しない部分をクロスコンパイルし (同時にアームの出力形式を変更)、arm-none-linux-gnueabi-gcc を使用してマシンに依存する部分をクロスコンパイルできるかどうか疑問に思っています。 glibc を作成し、これら 2 つの部分を組み合わせて独自の標準 C ライブラリを生成しますか?
私の仕事には間違いや誤解があるかもしれません。私の変更を標準の c ライブラリの少なくとも一部に追加し、プログラムを qemu-arm または gem5 で実行できる他の方法はありますか?