tinycc-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] Regression on ARM


From: Kirill Smelkov
Subject: Re: [Tinycc-devel] Regression on ARM
Date: Sat, 24 Nov 2012 13:02:54 +0400
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Nov 22, 2012 at 11:19:24AM +0100, Thomas Preud'homme wrote:
> On Thu, 22 Nov 2012 13:37:16 +0400, Kirill Smelkov wrote:
> >
> >I don't like that filter-out's. Actually, what I'd like to write here
> >is
> >
> >    ifeq ($(CONFIG_TCC_BCHECK),y)
> >        TESTS += btest
> >    endif
> 
> I agree it fits more my mental model.
> 
> >
> >or even better
> >
> >    TESTS-$(CONFIG_TCC_BCHECK) += btest
> >
> >and that CONFIG_TCC_BCHECK be inferred from cpu, arch, os, etc... by
> >configure to "y" or "n" and only TESTS-y get used.
> >
> >This way that CONFIG_TCC_BCHECK setting logic would be in only one
> >place, contrast to lots if big ifdefs/filter-outs everywhere.
> >
> >This config scheme is used by linux kernel.
> 
> I didn't know about this scheme but I like it. Only it would be nice
> to have things consistent so that if we switch to this model we
> should do it globally (at least in this Makefile).

Yes I agree too. For now I've pushed the version with filter-out, to
keep the style the same.


> >Only I don't have enough free time, that's why I don't insist. The
> >ifeq($(ARCH),i386) was closer to what I would like it to be -
> >that's why
> >I originally used it.
> >
> >Again, I don't insist.
> 
> I just think it makes things easier to read if everything follow the
> same scheme. Filterout is not my favourite approach though.
> 
> >
> >Studying arm was long on my TODO list.
> >
> >Yesterday evening I've started learning arm instructions. Some more
> >evenings are probably needed to finish assembly studyings. The
> >next step
> >would be to setup cross-compile environment which is again time for
> >probably several evenings. I'm ok with it, but if that's too much
> >time
> >to wait for others, your help is appreciated.
> 
> I'll see what I can do but I won't have time in the next days. Maybe
> next week.
> 
> >>>Also, while I'm studying how to setup arm toolchain, what is
> >>>`objdump -d`
> >>>output on arm for gcc and tcc for the next source?
> >>>
> >>>---- 8< ----
> >>>void *bfa0()
> >>>{
> >>>    return __builtin_frame_address(0);
> >>>}
> >>>
> >>>void *bfa1()
> >>>{
> >>>    return __builtin_frame_address(1);
> >>>}
> >>>
> >>>void *bfa2()
> >>>{
> >>>    return __builtin_frame_address(2);
> >>>}
> >>>---- 8< ----
> >>
> >>*** tcc ***
> >>
> >>00000000 <bfa0>:
> >>   0:   e1a0c00d        mov     ip, sp
> >>   4:   e92d5800        push    {fp, ip, lr}
> >>   8:   e28db00c        add     fp, sp, #12
> >>   c:   e1a00000        nop                     ; (mov r0, r0)
> >>  10:   e28b0000        add     r0, fp, #0
> >>  14:   e1a00000        nop                     ; (mov r0, r0)
> >>  18:   e91ba800        ldmdb   fp, {fp, sp, pc}
> >>
> >>0000001c <bfa1>:
> >>  1c:   e1a0c00d        mov     ip, sp
> >>  20:   e92d5800        push    {fp, ip, lr}
> >>  24:   e28db00c        add     fp, sp, #12
> >>  28:   e1a00000        nop                     ; (mov r0, r0)
> >>  2c:   e59b0000        ldr     r0, [fp]
> >>  30:   e1a00000        nop                     ; (mov r0, r0)
> >>  34:   e91ba800        ldmdb   fp, {fp, sp, pc}
> >>
> >>00000038 <bfa2>:
> >>  38:   e1a0c00d        mov     ip, sp
> >>  3c:   e92d5800        push    {fp, ip, lr}
> >>  40:   e28db00c        add     fp, sp, #12
> >>  44:   e24bd010        sub     sp, fp, #16
> >>  48:   e59b0000        ldr     r0, [fp]
> >>  4c:   e50b0010        str     r0, [fp, #-16]
> >>  50:   e51be010        ldr     lr, [fp, #-16]
> >>  54:   e59e0000        ldr     r0, [lr]
> >>  58:   e1a00000        nop                     ; (mov r0, r0)
> >>  5c:   e91ba800        ldmdb   fp, {fp, sp, pc}
> >>
> >>*** gcc ***
> >>
> >>00000000 <bfa0>:
> >>   0:   b480            push    {r7}
> >>   2:   af00            add     r7, sp, #0
> >>   4:   463b            mov     r3, r7
> >>   6:   4618            mov     r0, r3
> >>   8:   46bd            mov     sp, r7
> >>   a:   bc80            pop     {r7}
> >>   c:   4770            bx      lr
> >>   e:   bf00            nop
> >>
> >>00000010 <bfa1>:
> >>  10:   b480            push    {r7}
> >>  12:   af00            add     r7, sp, #0
> >>  14:   683b            ldr     r3, [r7, #0]
> >>  16:   4618            mov     r0, r3
> >>  18:   46bd            mov     sp, r7
> >>  1a:   bc80            pop     {r7}
> >>  1c:   4770            bx      lr
> >>  1e:   bf00            nop
> >>
> >>00000020 <bfa2>:
> >>  20:   b480            push    {r7}
> >>  22:   af00            add     r7, sp, #0
> >>  24:   683b            ldr     r3, [r7, #0]
> >>  26:   681b            ldr     r3, [r3, #0]
> >>  28:   4618            mov     r0, r3
> >>  2a:   46bd            mov     sp, r7
> >>  2c:   bc80            pop     {r7}
> >>  2e:   4770            bx      lr
> >
> >
> >It looks like gcc generated thumb instructions. Could you please
> >ask it
> >to generate plain arm 4-byte wide assembly, so I can compare tcc &
> >gcc
> >outputs.
> 
> Sure, here you are:
> 
> 00000000 <bfa0>:
>    0:   e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
>    4:   e28db000        add     fp, sp, #0
>    8:   e1a0300b        mov     r3, fp
>    c:   e1a00003        mov     r0, r3
>   10:   e28bd000        add     sp, fp, #0
>   14:   e8bd0800        pop     {fp}
>   18:   e12fff1e        bx      lr
> 
> 0000001c <bfa1>:
>   1c:   e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
>   20:   e28db000        add     fp, sp, #0
>   24:   e59b3000        ldr     r3, [fp]
>   28:   e1a00003        mov     r0, r3
>   2c:   e28bd000        add     sp, fp, #0
>   30:   e8bd0800        pop     {fp}
>   34:   e12fff1e        bx      lr
> 
> 00000038 <bfa2>:
>   38:   e52db004        push    {fp}            ; (str fp, [sp, #-4]!)
>   3c:   e28db000        add     fp, sp, #0
>   40:   e59b3000        ldr     r3, [fp]
>   44:   e5933000        ldr     r3, [r3]
>   48:   e1a00003        mov     r0, r3
>   4c:   e28bd000        add     sp, fp, #0
>   50:   e8bd0800        pop     {fp}
>   54:   e12fff1e        bx      lr
> 
> >
> >Also, what is the output of tests/tcctests.gcc for
> >__builtin_frame_address() test? It should be
> >
> >    str: __builtin_frame_address
> >    bfa1: __builtin_frame_address
> >    bfa2: __builtin_frame_address
> >    bfa3: __builtin_frame_address
> 
> Surprisingly it segfaults as well.

Thanks for the info. The progress on my side is as follows: I've learned
arm assembly and setup arm and armhf cross-toolchains (turned out to be
very easy, thanks to emdebian[1]). Also I can run arm binaries via
qemu-arm and basic hello world works.

The next step is to analyze the __builtin_frame_address problem. I'll
keep you posted.


Thanks,
Kirill

[1] http://emdebian.org/crosstools.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]