arm-aout vs arm-elf

[Quality Quorum]

On Sun, 14 Oct 2001, Philip Blundell wrote:

> In message < Pine.SGI.4.30.0110020948330.1387-100000@world.std.com >, Quality Quo
> rum writes:
> >It seems to me that there are a few problems with arm-aout configuration
> >(I am using gcc-2.95.3).
> >
> >1. gcc/config/arm/elf.h defines TARGET_DEFAULT as apcs-32/soft-float
> >   combination and gcc/config/arm/aout.h does not define TARGET_DEFAULT
> >   at all.
> >
> >2. gcc/config/arm/elf.h defines MULTILIB_DEFAULTS, which include apcs-32,
> >   and gcc/config/arm/aout.h does not define MULLTILIB_DEFAULTS at all.
> >
> >3. No matter what TARGET_DEFAULT settings are and no matter what
> >   TARGET_CPU_DEFAULT settings are, CPP_APCS_PC_DEFAULT is always
> >   apcs-26 and CPP_FLOAT_DEFAULT_SPEC is always hard float.
>
> All the things you list here are true, but I don't really understand why you think they are "problems".

If I do  xxxxx/confiugre --target=arm-elf ...,  I will get apcs-32,
correct settings of cpp defaults and properly configured multilib.

If I do xxxx/configure --target=arm-aout ..., I will get apcs-26,
hardlfoat default for cpp and no multilib, BTW it will happen regardless
of `with-cpu' settings.

I do not think that this is desired outcome.

BTW, I tracked down another arm-specific problem with gcc-2.95.3 (thanks
to Keith Seitz). This version generates debug info with incorrect address
for the first line of the function (below is a result of objdump):

00008040 <_xxx>:
_xxx():
    8040:       e1a0c00d        mov     ip, sp
    8044:       e92dd800        stmdb   sp!, {fp, ip, lr, pc}
    8048:       e24cb004        sub     fp, ip, #4      ; 0x4
    804c:       e24dd014        sub     sp, sp, #20     ; 0x14
/home/aromanov/tst/xxx.c:7
    8050:       e50b0010        str     r0, [fp, -#16]
    8054:       e50b1014        str     r1, [fp, -#20]
    8058:       e50b2018        str     r2, [fp, -#24]
    805c:       e50b301c        str     r3, [fp, -#28]
/home/aromanov/tst/xxx.c:8
    8060:       e51b301c        ldr     r3, [fp, -#28]
    8064:       e58d3000        str     r3, [sp]
    8068:       e3a00001        mov     r0, #1  ; 0x1
    806c:       e51b1010        ldr     r1, [fp, -#16]
    8070:       e51b2014        ldr     r2, [fp, -#20]
    8074:       e51b3018        ldr     r3, [fp, -#24]
    8078:       eb000000        bl      8080 <_yyy>
/home/aromanov/tst/xxx.c:9
    807c:       e91ba800        ldmdb   fp, {fp, sp, pc}


Correct results (again thanks to Keith) is here:


00008140 <xxx>:
xxx():
/home/keiths/tst/xxx.c:7
    8140:       e1a0c00d        mov     ip, sp
    8144:       e92dd800        stmdb   sp!, {fp, ip, lr, pc}
    8148:       e24cb004        sub     fp, ip, #4      ; 0x4
    814c:       e24dd014        sub     sp, sp, #20     ; 0x14
    8150:       e50b0010        str     r0, [fp, -#16]
    8154:       e50b1014        str     r1, [fp, -#20]
    8158:       e50b2018        str     r2, [fp, -#24]
    815c:       e50b301c        str     r3, [fp, -#28]
/home/keiths/tst/xxx.c:8
    8160:       e51b301c        ldr     r3, [fp, -#28]
    8164:       e58d3000        str     r3, [sp]
    8168:       e3a00001        mov     r0, #1  ; 0x1
    816c:       e51b1010        ldr     r1, [fp, -#16]
    8170:       e51b2014        ldr     r2, [fp, -#20]
    8174:       e51b3018        ldr     r3, [fp, -#24]
    8178:       eb000000        bl      8180 <yyy>
/home/keiths/tst/xxx.c:9
    817c:       e91ba800        ldmdb   fp, {fp, sp, pc}


As a result gdb incorrectly calculates breakpoint address for the
function, e.g. `b xxx' will set break point at 0x8050 in the
first case and at 0x8160. So, when break point is would be hit
gdb will print garbadge as passed parameter values.

I have no clue, how to fix, though.

>
> p.
>

Thanks,

Aleksey


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com