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

>
> 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>

I can confirm that musl builds and works correctly with clang/llvm. We 
are using musl as a libc for our architecture.
It has a much smaller code footprint than newlib or glibc.

Regards,

     Richard


On 3/11/2015 4:24 PM, Chao Yan 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".
>
>
> 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"."
>
>
>
> _______________________________________________
> 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/6b1ee9e8/attachment.html>

On 3/11/15 2:24 PM, Chao Yan 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".
>
>
> 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"."
gdb doesn't know how to run your program because gdb only knows how to 
run programs natively.  You need to run it in qemu, and attach gdb to 
that, then debug as if you were debugging natively.

I do something roughly like this (this is from memory, so the actual 
commands might be slightly different. ymmv):

    $ cat hw.c
    #include <stdio.h>
    int main() { printf("hello world!\n"); }
    $ clang -target arm-none-eabi -march=armv4t hw.c -T generic-hosted.ld
    $ qemu-system-arm -semihosting -M integratorcp -cpu arm1026 -kernel 
a.out -s -S -g 1234 &
    $ arm-none-eabi-gdb
    (gdb) target remote localhost:1234
    (gdb) file a.out
    (gdb) break main
    (gdb) r
    (gdb) c
    hello world!
    (gdb) q
    $


HTH,

Jon

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded

2015-03-11 16:53 GMT-05:00 Jonathan Roelofs <jonathan at
codesourcery.com>:
> gdb doesn't know how to run your program because gdb only knows how to
run
> programs natively.  You need to run it in qemu, and attach gdb to that,
> then debug as if you were debugging natively.
>
> I do something roughly like this (this is from memory, so the actual
> commands might be slightly different. ymmv):
>
>    $ cat hw.c
>    #include <stdio.h>
>    int main() { printf("hello world!\n"); }
>    $ clang -target arm-none-eabi -march=armv4t hw.c -T generic-hosted.ld
>    $ qemu-system-arm -semihosting -M integratorcp -cpu arm1026 -kernel
> a.out -s -S -g 1234 &
>    $ arm-none-eabi-gdb
>    (gdb) target remote localhost:1234
>    (gdb) file a.out
>    (gdb) break main
>    (gdb) r
>    (gdb) c
>    hello world!
>    (gdb) q
>
I learn a lot from this, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150311/e3bcff3a/attachment.html>

2015-03-11 16:22 GMT-05:00 Richard Gorton <
rcgorton at cognitive-electronics.com>:
> I can confirm that musl builds and works correctly with clang/llvm.  We
> are using musl as a libc for our architecture.
> It has a much smaller code footprint than newlib or glibc.
>

I successfully cross-compile the must-libc using clang, with the
configuration:

C=clang CFLAGS=--target=arm-none-linux-gnueabi\
--sysroot=/usr/local/arm-2009q\ -I\
/usr/local/arm-2009q3/arm-none-linux-gnueabi/libc/usr/include/ LIBCC./configure
--target=arm

But how to force clang  to use musl-libc rather than its default one? I
tried

clang --target arm-none-linux-gnueabi -nostdlib -static hello.c
~/research/musl-1.1.6/lib/crt1.o ~/research/musl-1.1.6/lib/crti.o
~/research/musl-1.1.6/lib/crtn.o -I ~/research/musl-1.1.6/include/ -L
~/research/musl-1.1.6/lib/ -L
/usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1/ -lc -lgcc
-lgcc_eh

clang complaint:

/usr/local/arm-2009q3/bin/arm-none-linux-gnueabi-ld: warning: library
search path "/lib/../lib" is unsafe for cross-compilation
/usr/local/arm-2009q3/bin/arm-none-linux-gnueabi-ld: warning: library
search path "/usr/lib/../lib" is unsafe for cross-compilation
/usr/local/arm-2009q3/bin/arm-none-linux-gnueabi-ld: warning: library
search path "/lib" is unsafe for cross-compilation
/usr/local/arm-2009q3/bin/arm-none-linux-gnueabi-ld: warning: library
search path "/usr/lib" is unsafe for cross-compilation
/home/yanchao/research/musl-1.1.6/lib//libc.a(__libc_start_main.o): In
function `__libc_start_main':
src/env/__libc_start_main.c:(.text+0x30): undefined reference to
`__aeabi_memset'
/home/yanchao/research/musl-1.1.6/lib//libc.a(vfprintf.o): In function
`vfprintf':
src/stdio/vfprintf.c:(.text+0x28): undefined reference to `__aeabi_memset'
/usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//libgcc.a(_dvmd_lnx.o):
In function `__aeabi_ldiv0':
(.text+0x8): undefined reference to `raise'
/usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//libgcc_eh.a(unwind-arm.o):
In function `unwind_phase2':
unwind-arm.c:(.text+0xae4): undefined reference to `abort'
/usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//libgcc_eh.a(unwind-arm.o):
In function `__gnu_Unwind_Resume':
unwind-arm.c:(.text+0xbe8): undefined reference to `abort'
unwind-arm.c:(.text+0xc10): undefined reference to `abort'
/usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//libgcc_eh.a(pr-support.o):
In function `_Unwind_GetTextRelBase':
pr-support.c:(.text+0x4): undefined reference to `abort'
/usr/local/arm-2009q3/lib/gcc/arm-none-linux-gnueabi/4.4.1//libgcc_eh.a(pr-support.o):
In function `_Unwind_GetDataRelBase':
pr-support.c:(.text+0xc): undefined reference to `abort'

Regards,
Chao
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150312/270e8420/attachment.html>