llvm dev - Mar 2015 - [LLVMdev] Customize Standard C Library Using LLVM (to support llvm backend optimization)

Purpose:

I implemented a pass on LLVM backend that changes the output format of
*ARM* assembly/binary
(e.g add a jump at the end of each basic block to eliminate fall through).
By calling:

llc -march=arm somefile.bc

it generates expected arm assembly/binary that runs properly on arm gnu
linux (I use qemu-arm and gem5 to simulate it). Now I want to do the same
thing on standard c library, but here are problems.
Problems:

According to:

http://article.gmane.org/gmane.comp.compilers.llvm.devel/77025
https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_14/docs/OpenProjects.html#glibc

compiling glibc using llvm may not be a proper option. On the other hand,
according to:

http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/047088.html

llvm could be able to compile newlib, thus people consider newlib as an
alternative. However, according to:

http://www.embecosm.com/appnotes/ean9/ean9-howto-newlib-1.0.html#id2711887

newlib intends to support binaries for bare metal (no OS) software. It
implements only the hardware independent parts (e.g libc and libm) and
leave a stub for each hardware dependent syscall (e.g everything in
libgloss).

In fact I tried to compile a simple "hello world" c program using
arm-none-eabi-gcc which was configured with "--with-newlib" option,
the
program execution ends up with segmentation faults on both qemu-arm and
gem5.
Questions:

I'm not sure if the newlib is compatible with glibc. I'm wondering if I
could use llvm to cross-compile the machine independent parts (at the same
time change the arm output format) from newlib and use
arm-none-linux-gnueabi-gcc to cross-compile the machine dependent parts
from glibc and put these two parts together to generate my own standard c
library?

There might be mistakes/misunderstandings in my work. Are there any other
possible methods that could add my changes to at least part of the standard
c libraries, and make the program run on qemu-arm or gem5?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150311/b26092c0/attachment.html>

On 3/11/15 10:13 AM, Chao Yan wrote:
>
>   Purpose:
>
> I implemented a pass on LLVM backend that changes the output format of
> /ARM/ assembly/binary (e.g add a jump at the end of each basic block to
> eliminate fall through). By calling:
>
> |llc -march=arm somefile.bc
> |
>
> it generates expected arm assembly/binary that runs properly on arm gnu
> linux (I use qemu-arm and gem5 to simulate it). Now I want to do the
> same thing on standard c library, but here are problems.
>
>
>   Problems:
>
> According to:
>
> |http://article.gmane.org/gmane.comp.compilers.llvm.devel/77025
>
https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_14/docs/OpenProjects.html#glibc
> |
>
> compiling glibc using llvm may not be a proper option. On the other
> hand, according to:
>
> |http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/047088.html
> |
>
> llvm could be able to compile newlib, thus people consider newlib as an
> alternative. However, according to:
FWIW, I build baremetal newlib for arm-eabi using clang, and it works. I 
had to patch a few of the __attribute__((naked)) functions because they 
were using pre-UAL asm syntax, but for the most part it "just works".
>
> |http://www.embecosm.com/appnotes/ean9/ean9-howto-newlib-1.0.html#id2711887
> |
>
> newlib intends to support binaries for bare metal (no OS) software. It
> implements only the hardware independent parts (e.g libc and libm) and
> leave a stub for each hardware dependent syscall (e.g everything in
> libgloss).
Have you considered trying musl? It's supposed to be a full replacement 
for glibc.
>
> In fact I tried to compile a simple "hello world" c program using
> arm-none-eabi-gcc which was configured with "--with-newlib"
option, the
> program execution ends up with segmentation faults on both qemu-arm and
> gem5.
Have you run it in a debugger to figure out *why* it is segfaulting? 
Have you tried building it without your special pass?


Cheers,

Jon
>
>
>   Questions:
>
> I'm not sure if the newlib is compatible with glibc. I'm wondering
if I
> could use llvm to cross-compile the machine independent parts (at the
> same time change the arm output format) from newlib and use
> arm-none-linux-gnueabi-gcc to cross-compile the machine dependent parts
> from glibc and put these two parts together to generate my own standard
> c library?
>
> There might be mistakes/misunderstandings in my work. Are there any
> other possible methods that could add my changes to at least part of the
> standard c libraries, and make the program run on qemu-arm or gem5?
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

On Wed, Mar 11, 2015 at 9:13 AM, Chao Yan <yanchao2012 at gmail.com>
wrote:
> Purpose:
>
> I implemented a pass on LLVM backend that changes the output format of
> *ARM* assembly/binary (e.g add a jump at the end of each basic block to
> eliminate fall through). By calling:
>
> llc -march=arm somefile.bc
>
> it generates expected arm assembly/binary that runs properly on arm gnu
> linux (I use qemu-arm and gem5 to simulate it). Now I want to do the same
> thing on standard c library, but here are problems.
> Problems:
>
> According to:
>
> http://article.gmane.org/gmane.comp.compilers.llvm.devel/77025
https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_14/docs/OpenProjects.html#glibc
>
> compiling glibc using llvm may not be a proper option.
>
Not an option /yet/, but it's a work in progress, by the sounds of it.
Kostya's been working on it recently & it sounds like there's one or
two
things in the source code to tackle, then some build issues?

> On the other hand, according to:
>
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/047088.html
>
> llvm could be able to compile newlib, thus people consider newlib as an
> alternative. However, according to:
>
> http://www.embecosm.com/appnotes/ean9/ean9-howto-newlib-1.0.html#id2711887
>
> newlib intends to support binaries for bare metal (no OS) software. It
> implements only the hardware independent parts (e.g libc and libm) and
> leave a stub for each hardware dependent syscall (e.g everything in
> libgloss).
>
> In fact I tried to compile a simple "hello world" c program using
> arm-none-eabi-gcc which was configured with "--with-newlib"
option, the
> program execution ends up with segmentation faults on both qemu-arm and
> gem5.
> Questions:
>
> I'm not sure if the newlib is compatible with glibc. I'm wondering
if I
> could use llvm to cross-compile the machine independent parts (at the same
> time change the arm output format) from newlib and use
> arm-none-linux-gnueabi-gcc to cross-compile the machine dependent parts
> from glibc and put these two parts together to generate my own standard c
> library?
>
> There might be mistakes/misunderstandings in my work. Are there any other
> possible methods that could add my changes to at least part of the standard
> c libraries, and make the program run on qemu-arm or gem5?
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150311/9631317e/attachment.html>

On 11 March 2015 at 16:32, Jonathan Roelofs <jonathan at codesourcery.com>
wrote:
> FWIW, I build baremetal newlib for arm-eabi using clang, and it works. I
had
> to patch a few of the __attribute__((naked)) functions because they were
> using pre-UAL asm syntax, but for the most part it "just works".
Have you sent this patch upstream? This is the kind of thing we have
to get rid for both Clang and GCC sakes.

cheers,
--renato

On Wed, Mar 11, 2015 at 9:55 AM, David Blaikie <dblaikie at gmail.com>
wrote:
>
>
> On Wed, Mar 11, 2015 at 9:13 AM, Chao Yan <yanchao2012 at gmail.com>
wrote:
>
>> Purpose:
>>
>> I implemented a pass on LLVM backend that changes the output format of
>> *ARM* assembly/binary (e.g add a jump at the end of each basic block to
>> eliminate fall through). By calling:
>>
>> llc -march=arm somefile.bc
>>
>> it generates expected arm assembly/binary that runs properly on arm gnu
>> linux (I use qemu-arm and gem5 to simulate it). Now I want to do the
same
>> thing on standard c library, but here are problems.
>> Problems:
>>
>> According to:
>>
>> http://article.gmane.org/gmane.comp.compilers.llvm.devel/77025
https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_14/docs/OpenProjects.html#glibc
>>
>> compiling glibc using llvm may not be a proper option.
>>
> Not an option /yet/, but it's a work in progress, by the sounds of it.
> Kostya's been working on it recently & it sounds like there's
one or two
> things in the source code to tackle, then some build issues?
>
I've been successfully building glibc's libc.so with clang (and asan!)
for
the past two weeks,
but the process is manual and still requires a few patches and ugly hacks.
https://sourceware.org/glibc/wiki/GlibcMeetsClang

>
>
>> On the other hand, according to:
>>
>> http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/047088.html
>>
>> llvm could be able to compile newlib, thus people consider newlib as an
>> alternative. However, according to:
>>
>>
http://www.embecosm.com/appnotes/ean9/ean9-howto-newlib-1.0.html#id2711887
>>
>> newlib intends to support binaries for bare metal (no OS) software. It
>> implements only the hardware independent parts (e.g libc and libm) and
>> leave a stub for each hardware dependent syscall (e.g everything in
>> libgloss).
>>
>> In fact I tried to compile a simple "hello world" c program
using
>> arm-none-eabi-gcc which was configured with "--with-newlib"
option, the
>> program execution ends up with segmentation faults on both qemu-arm and
>> gem5.
>> Questions:
>>
>> I'm not sure if the newlib is compatible with glibc. I'm
wondering if I
>> could use llvm to cross-compile the machine independent parts (at the
same
>> time change the arm output format) from newlib and use
>> arm-none-linux-gnueabi-gcc to cross-compile the machine dependent parts
>> from glibc and put these two parts together to generate my own standard
c
>> library?
>>
>> There might be mistakes/misunderstandings in my work. Are there any
other
>> possible methods that could add my changes to at least part of the
standard
>> c libraries, and make the program run on qemu-arm or gem5?
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150311/7a432095/attachment.html>

>
> FWIW, I build baremetal newlib for arm-eabi using clang, and it works. I
>> had to patch a few of the __attribute__((naked)) functions because they
>> were using pre-UAL asm syntax, but for the most part it "just
works".
>>
>
I build the baremetal newlib using arm-none-eabi-gcc as well, but after
linking with the hello world program, it failed to run on both qemu-arm and
gem5.

>>
>>  Have you considered trying musl? It's supposed to be a full
replacement
> for glibc.

It looks like a nice alternative, I'll certainly look into it right away.



>>  Have you run it in a debugger to figure out *why* it is segfaulting?
> Have you tried building it without your special pass?
>
> Well, I didn't try clang, I use arm-none-eabi-gcc to build the newlib
and
the hello world program. The arm-none-eabi-gdb says "Don't know how to
run.  Try "help target"."
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150311/4159f0f1/attachment.html>