Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3

[Georg-Johann Lay]

Weddington, Eric schrieb:
> 
>> Subject: Re: [avr-gcc-list] [AVR] RTL prologue/epilogue ver.3
>>
>>> I think this patch severely affects the step in/step out feature of
>>> debugger like AVR Studio (here after referred to as AS). AS depends
>>> on
>>> 'rcall'/'ret' instruction sequences to recognize a function call and
>>> step into. If a matching 'ret' is not found, the debugger gets
>>> confused.
>>> Currently, the problem is worked around but has much lower
>>> performance.
>> The debugger has to cope with that. There are two ways of doing that:
>>
>> 1) Analysing the prologue and knowing what sequences the compiler
>> might generate.
>>
> 
> On further thought about that, it's actually pretty simple to determine
> when an rcall is used in the context of a function prologue; It shows up
> as "rcall 0", which is extremely unlikely that that form will ever be
> used for a real subroutine call. (In fact, I can't think of any
> situation where "rcall 0" could be used as a real subroutine call, but
> maybe somebody has a real counter-example that could be generated by the
> compiler.)

In lingcc.S there is

DEFUN __umulhisi3
    mul     A0, B0
    movw    C0, r0
    mul     A1, B1
    movw    C2, r0
    mul     A0, B1
    rcall   1f
    mul     A1, B0
1:  add     C1, r0
    adc     C2, r1
    clr     __zero_reg__
    adc     C3, __zero_reg__
    ret
ENDF __umulhisi3

This self-call is not a rcall .+0 but close to it because there is just a MUL
in between.  But that's assembler ...

For the compiler, assume:

void __attribute__((noreturn,noinline)) b (void);

void a (void)
{
    b();
}

void b (void)
{
    while (1);
}

avr-gcc ab.c -S -Os -fno-toplevel-reorder

a:
        rcall b

b:
.L3:
        rjmp .L3

But there is symbol information for b despite rcall .+0

BTW: I am just working on a patchlet to print {R|[E]I}JMP for noreturn 
functions.

Johann